* Guard the ballooneval settings
* Mark main objectives to do to get nice Hover
* Make tweaks to make the tooltip work - See " XXX: comments
* Guard balloon_show call
* Use return instead of finish for functions
* ale#hover#show : Add optional arguments to specify arbtirary position
This change is requested to be able to call the function with mouse
position to enable hover information in vim's balloon
* ale#ballon#Disable : Remove feature guards
* ale#balloon : Show 'ALEHover' output on balloon if no diagnostic found
* ale#hover#HandleLSPResponse : remove the check for cursor position
This check prevented the 'ALEHover in balloon' feature, since mouse
position is almost never cursor position.
* ale#balloon#MessageForPos : Change the return of balloonexpr
balloonexpr evaluation now works even without balloon_show for basic
diagnostics, leaving the balloon_show call to ale#hover#Show, which can
then feature guard the call to avoid errors
* ale#hover#Response : Feature guard balloon_show calls
* ale#hover : always display 'Hover' information in messages
Also add a small comment to warn readers the different outputs the
ale#hover#Show will write to
* {LSP,TS}Response : use only variables from the Response
It is clearer that we only rely on l:options to get the relevant data to
build the LSP Response string
* hover#ShowDetails : fix an issue where not having focus broke balloons
The issue was caused by not using a buffer-specific version of getline()
to cap the value of the column sent in the message to LSP. Therefore a
cursor on column 10 in an inactive window could send a message with
column=0, if the active window had a buffer with too few lines
* {LSP,TS}Response : Remove redundant checks for balloon_show call
With the upcoming change in ale_set_balloons default value (see Pull
Request w0rp/ale#1565), this check will be useless
* balloonexpr? : Add a flag to separate hover#Show() calls
The goal of this flag is to make `:ALEHover` calls not pop a balloon
under the cursor, since the user has probably no interest in their
cursor while typing the command
The flag is a default argument which is overridden only in ballonexpr
call of ale#hover#Show, and stays set in the hover_map until the
callback for the LSP handles it.
There are no automated tests for this feature right now, and the nature
of the addition (one optional argument in the API) should make it
transparent to existing tests.
Since the differentiation is now possible, the check for moved cursor
has been put back in ale#hover#HandleLSPResponse
* ale#hover#hover_map : Protect accesses to hover_map
Using get() is safer than trying to access directly with ., as the tests
show.
* Raise timeout to try to get Appveyor happy
* Review : Fix comments
* Review : pass the optional argument 'called_from_balloonexpr' in a Dict
This optional dictionary has documentation just before the function
using it, ale#hover#Show, and allows easier extension in the future.
* Update section 5.viii in the README with ALEJobStarted and re-format
the example.
* Add an extra line after documentation update to ensure consistency
with the rest of the doc.
Adding a couple of tests to demonstrate how IsCheckingBuffer behaves
during specific autocommand hooks:
* At ALELintPre, no linters have actually executed yet, hence
IsCheckingBuffer should be returning false.
* ALEJobStarted, fires as early as reasonably possible after a job has
successfully started, and hence hooking into IsCheckingBuffer here
should return true.
This distinction is important when using these two events during things
like statusline refreshes, namely for "linter running" indicators.
The ALELintPre and ALELintPost autocommand events are currently being
used by lightline-ale to refresh the status line and check the linter
status for a current buffer. One of the plugin's checks looks to see if
linters are currently running, via ale#engine#IsCheckingBuffer(). This
currently only works partially in certain situations. In my particular
case, working with Go files, this only seems to function properly when a
file is initially opened. Saving a file does not correctly update the
status.
This seems to be due to the fact that ALELintPre actually runs before
any jobs are carried out, making it plausible that hooking into
ALELintPre for the purpose of checking to see if there are any currently
running linters for a buffer is unreliable as it would be prone to
pretty obvious race conditions.
This adds a new User autocommand, ALEJobStarted, that gets fired at the
start of every new job that is successfully run. This allows a better
point to hook into checking the linter status of a buffer using
ale#engine#IsCheckingBuffer() by ensuring that at least one job has
started by the time IsCheckingBuffer is run.
