in the past DocumentDidChange and SelectionDidChange events were implemented in
a simplistic manner to get a simple prototype out. However, if you want to use
these events in more complex scenarios with interdependencies between the two
handlers the system fell short.
The `SelectionDidChange` event was dispatched before the DocumentDidChange (and
not at all if the selection wasn't manually set) so any handlers that wants to
track selection was not able to map their ranges yet.
The reason for this was actually the way that apply_impl was structured. The
function was slightly refactored to address these problems and enable moving
other range mappings to event handlers.
* Make dark_plus.toml more accurate to VSCode
* theme(dark_plus): make type.builtin blue
* Refactor dark_plus and add myself as new maintainer
Co-authored-by: NAME <NAME@EXAMPLE.COM>
---------
Co-authored-by: Luca Saccarola <96259932+saccarosium@users.noreply.github.com>
Co-authored-by: Luca Saccarola <github.e41mv@aleeas.com>
Co-authored-by: NAME <NAME@EXAMPLE.COM>
While moving completion resolve to the event system in #9668 we introduced what
is essentially a "DOS attack" on slow LSPs. Completion resolve requests were
made in the render loop and debounced with a timeout. Once the timeout expired
the resolve request was made. The problem is the next frame would immediately
request a new completion resolve request (and mark the old one as obsolete but
because LSP has no notion of cancelation the server would still process it). So
we were in essence sending one completion request to the server every 150ms and
only stopped if the server managed to respond before we rendered a new frame.
This caused overload on slower machines/with slower LS.
In this PR I revamped the resolve handler so that a request is only ever
resolved once. Both by checking if a request is already in-flight and by marking
failed resolve requests as resolved.
Add styling for jump-labels for modus themes. I couldn't find
any official approach here so picking `yello-cooler`. `cooler` is
used for other meta highlights by modus and yellow seems to be
used the least - only warnings, so there's little chance of colliding
with other highlights.
Make the popup positions more consistent.
Improvements:
1. if the signature popup content is bigger than the available space,
then the popup is always shown under the cursor, even if there more
space above the cursor than below
2. There is no mutation anymore inside required_size. Maybe in the future
we can update all widgets to have no mutations and change the trait
Signed-off-by: Ben Fekih, Hichem <hichem.f@live.de>
Currently the editor mode has no effect on the behavior of `search` and
`rsearch`. We can pass in the right movement for the editor mode to make
the behavior or `search` and `rsearch` match `search_next` and
`search_prev` in select mode.
changed the statusline colors for SELECT mode
the previous colours seem to be incorrect and quite ugly (sorry).
I chose the magenta over the cyan that (colors that were already present) as it has
more contrast with the existing INSERT colour.
the statusline colours are now inline with eachother, all having the background be the 'background'
colour, with varying foregrounds.
Co-authored-by: urly3 <u@rl.yyy>
The prior URL invites you to create a new wiki page. I think https://github.com/helix-editor/helix/wiki/Language-Server-Configurations is the correct place to point to now.
There might be more issues related to changes in wiki structure that are not caught by some CI link check because of this (it's a valid URL, just not what you want to direct to lol)
Pascal Kuthe
David Else
woojiq
Yoav Lavi
Krishan
Kirawi
Matouš Dzivjak
Simran Kedia
Triton171
dependabot[bot]
Chris Sergienko
Ben Fekih, Hichem
Michael Davis
Kevin Vigor
RoloEdits
urly3
Nuke
ves
Blaž Hrastnik
Daniel O'Brien
Sean Perry
ath3
Gaëtan Lehmann
Pascal Kuthe
Clara Smyth
Jonathan Lebon