From the issue:
> It often happens to me that I carefully craft a selection with multiple
> cursors, ready to make changes elegantly, only to completely mess it
> up by pressing a wrong key (by merging the cursors for example). Being
> able to undo the last selection change (even if only until the previous
> buffer change) would make this much less painful.
Fix this by recording selection changes and allowing simple linear
undo/redo of selection changes.
The preliminary key bindings are <c-h> and <c-k>.
Here are some other vacant normal mode keys I considered
X Y
<backspace> <minus>
# ^ =
<plus> '
unfortunately none of them is super convenient to type. Maybe we
can kick out some other normal mode command?
---
This feature has some overlap with the jump list (<c-o>/<c-i>) and
with undo (u) but each of the three features have their moment.
Currently there's no special integration with either peer feature;
the three histories are completely independent. In future we might
want to synchronize them so we can implement Sublime Text's "Soft
undo" feature.
Note that it is possible to restore selections that predate a buffer
modification. Depending on the buffer modification, the selections
might look different of course. (When trying to apply an old buffer's
selection to the new buffer, Kakoune computes a diff of the buffers
and updates the selection accordingly. This works quite well for
many practical examples.)
This makes us record the full history of all selections for each
client. This seems wasteful, we could set a limit. I don't expect
excessive memory usage in practice (we also keep the full history of
buffer changes) but I could be wrong.
Closes#898
Add a UserInterface::is_ok method and return false on
SIGHUP/stdin closing/socket dropping
This should be cleaner and more robust than the previous SIGHUP
handling code.
Fixes#1594
Handle next event should never block if we have already accumulated
input that we want to process. As we can accumulate new input in
lots of places (everytime we run a shell process for example, we
might end up reading input keys. That can be triggered during the
mode line generation which takes place during display of the window)
Fixes#1804
This round trip through an input callback expected to call
is_key_available and get_key was overcomplicated, just send the
keys as they arrive, the client is already buffering due to urgent
event mode.
If a shell commands takes more than 1s to execute, a message will appear
on the status line notifying the user, along with the time Kakoune has
been waiting for.
Add a ColumnCount type and use it in place of CharCount whenever
more appropriate, take column size of codepoints into account for
vertical movements and docstring wrapping.
Fixes#811
We cannot assume Client::m_window is always non-null, as when
changing current buffer its temporarily null, at the point
where WinCreate hook might get called.
Fixes#382
We can have SelectionList in flights on the buffer, so mark
it for deletion by moving it in a buffer trash, and effectively
delete it later, at a point where there should not be any further
access to it.
At connection, a remote client sends all its environement to the
server, which then provides access to client env through
kak_client_env_VAR_NAME variables in the shell.
