This fixes the modification indicator when saving from insert mode with
a config such as
[keys.insert]
C-s = ":write"
Previously the modification indicator would be stuck showing modified
even if the buffer contents matched the disk contents when writing after
some changes in insert mode with this binding. In insert mode we do not
eagerly write undo checkpoints so that all changes made become one
checkpoint as you exit insert mode. When saving, `Document`s `changes`
`ChangeSet` would be non-empty and when there are changes we show the
buffer as modified. Then switching to normal mode would append the
changes to history, bumping the current revision past what it was when
last saved. Since the last saved revision and current revision were then
unsynced, the modification indicator would always show modified.
This matches [Kakoune's behavior]. Kakoune has a different architecture
for writes but a very similar system for history, transactions and undo
checkpoints (what it calls "undo groups"). Upon saving Kakoune creates
an undo checkpoint if there are any uncommitted changes. It does this
after the write has gone through since its writing system is different.
For our writing system it's cleaner to make the undo checkpoint before
performing the save so that the history revision increments before we
send the save event.
[Kakoune's behavior]: 80fcfebca8/src/buffer.cc (L565-L566)
Previously `gf` on `~/.config/helix` for example would error if the
entire path was selected but succeed and open a picker for the directory
contents if the selection was one one-width cursor. We need to expand
tildes for all paths instead of just the auto-detected paths.
This also refactors the `goto_file` blocks a little so that we construct
`paths` once instead of creating the Vec and immediately clearing it
when the selection is one single-width cursor.
* Add changes before insert mode undo
Fixes#11077
* Address edge cases for undo like Kakoune does
---------
Co-authored-by: Kaniel Kirby <pirate7007@runbox.com>
Co-authored-by: Michael Davis <mcarsondavis@gmail.com>
* refactor `starting_request_args` to only `ref` non-`Copy`
* refactor `needs_recompile` to only `ref` non-`Copy`
* refactor `add_workspace_folder` to only `ref` `Some`
---------
Co-authored-by: Rudxain <rudxain@localhost.localdomain>
This fix allows for multiple language servers at once which support
workspace commands. This was previously broken as just the first
language server supporting workspace commands was queried when listing
allowed worspace commands.
The fix is in two parts. Firstly, querying all workspace commands from
all language servers available and using them when actually running the
command in `lsp_workspace_command`. Secondly, doing the same in
`completers::lsp_workspace_command` such that completion still works as
expected.
The fix has one remaining issue, which I am unsure how to handle in the
best way possible, but which I also don't think should happen often:
Multiple language servers may register commands with the same name. This
will lead to that command being listed in the popup menu and in the
completion list multiple times, which can be possibly confusing. One
could disambigue them in the popover menu, but I am not sure the same
can be done for completion. When running `lsp-workspace-command` with
parameters, this behavior is "fixed" by displaying an error in that
case. I am unsure if this is the best fix for this issue in that case,
but could not find a better one.
Without providing the formatting capability, the language server might not advertise its ability to format in return, causing the :format command to be broken.