After buffer modification - in particular after deletion - adjacent
selection history entries may correspond to the same effective
selection when applied to the current buffer. This means that we
sometimes need to press <c-h> multiple times to make one visible
change. This is not what the user expects, so let's keep walking the
selection history until we hit an actual change.
Alternatively, we could minimize the selection history after buffer
changes but I think that would make the it worse after content
undo+redo.
Each selection undo operation is surrounded by pair of
begin_edition()/end_edition() calls.
The original reason for adding these was that in one of my preliminary
versions, a WinDisplay hook could break an undo chain, even if the
hook did not affect selections at all. This has since been fixed.
By surrounding the undo with begin_edition()/end_edition(), try to
ensure that any selection modification that happens in a WinDisplay
hook would not break the undo chain. Essentially this means that,
after using <c-h> to undo a buffer change, this was meant to
make sure that <c-k> could redo that buffer change.
However, it turns out this actually doesn't work. The attached test
case triggers an assertion. As described in the first paragraph,
the only real-world motivation for this is gone, so let's simplify
the behavior.
The assertion fix means that we can test the next commit better.
It turns out that neither <a-f> or <a-t> make sense when run at the
beginning of the buffer. When I first created the check, I thought
that <a-f> made sense if the character under the cursor was the
character being searched for. I was wrong, <a-f> should always go
at least one character backwards.
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
This commit fixes a bug in Buffer::advance where it would first access
m_lines[-1], and then check whether or not that access would have
segfaulted. This commit moves the check to before the segfault would
occur.
is run as
> ./kak -f '2oK.k<c-n><ret><c-n>' /dev/null
The crash occurs because when <c-n> is pressed for the second time,
it attempts to use m_completions from the first press of <c-n>.
This only happens when kakoune is run with -f, because when this is done
interactively, there is a client, which means that m_completions gets
reset. This removes the check that causes that difference.
I am not *completely* sure that this is the best way to solve the
problem, since I am not completely sure why that check was put there
in the first place.
Using BufferIterator adds overhead, but we know that DisplayAtoms
cannot span multiple buffer lines and hence we can directly iterate
using char pointers.
Each draft context gets its own private copy of the selections.
Any selection changes will be thrown away when the draft context
is disposed. Since selection-undo is only supported as top-level
command, it can never be used inside a draft context, so let's stop
recording it.
No functional change.
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
Calculating the length of an atom means we need to decode every
codepoint and compute its column width. This can prove quite expensive
in trim_from as we can have full buffer lines, so on buffer with long
lines we might have to go through megabytes of undisplayed data.
Pass the first buffer on the the command line explicitely to client
creation. This ensure the buffer list matches the command line, which
makes buffer-next/buffer-previous a bit more useful.
Fixes#2705
With overlapping selections, pasting after breaks assumption of
SelectionList::for_each as our changes are no longer happening in
increasing locations.
We hence cannot rely on the ForwardChangeTracker in that case and
have to rely on the more general (and more costly) ranges update logic.
This interacts poorly with paste linewise pastes and we try to preserve
the current behaviour by tracking the last paste position.
Overall, this change really begs for overlapping selections to be
removed, but we will fix them like that for now.
Fixes#4779
Before, sed would add quotes to every line of the single multiline argument,
causing the final quoted argument to "split ... command" or screen to contain
unquoted newlines such as this (from kakoune-cr):
tell application "iTerm"
tell current session of current window
tell (split vertically with same profile command "env PATH='...' 'sh' '-c' ''
' export KAKOUNE_SESSION=$1'
' export KAKOUNE_CLIENT=$2'
' shift 3'
''
' [ $# = 0 ] && set \"$SHELL\"'
''
' \"sh\"'
' ' '--' '51909' 'client0' 'terminal' ") to select
end tell
end tell
Instead of using sed to do this which operates on single lines at a time, simply
use printf to insert ' quotes before and after the entire argument.
At the moment, inserting a new line while being in a comment result in a
"//<indentation>" instead of "<indentation>//".
To fix this, we just paste the comment and indent after the newline
initial indentation.
Comparing iterators between buffers should never happen, and the
only place we did was with default constructed BufferIterator which
we replace by casting the iterator to bool.
This should improve performance on iterator heavy code.
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
When the file system runs out of space, "write -force" will fail but
doesn't print "No space left on device".
Let's fix this by including such an underlying error. Untested.
Backstory: I alias "w" to a command that runs "write -force %arg{@}".
so I can overwrite files that already exist outside the editor (I
should probably get used to the new behavior).
Just like the parent commit but for tmux-repl-* commands.
Note that tmux-repl-set-pane without arguments is kind of broken; it
increments the current pane ID, which only works in the most basic
scenarios. We should probably replace it with something better,
with menu completions etc.
The tmux-terminal-window command always spawns windows in the tmux
session where the Kakoune session was started - even if the calling
Kakoune client lives in a different tmux session.
Fix this by always creating the window in the tmux
session of the calling client. We already do the same for
tmux-terminal-{horizontal,vertical}.
I call tmux-terminal-impl with "new-window -a" (instead of
"new-window"), so make sure the fix works for my use case.
I considered retrieving the tmux session ID from the $TMUX environment
variable but the tmux manpage only specifies that $TMUX contains
"some internal data".
A pane's ID is immutable for the lifetime of the tmux server.
Same with window/session IDs.
When creating a new tmux repl, we record all three IDs to later use
them to send text to the repl.
The window/session IDs can be invalidating when a pane is moved to
a different window/session (via "tmux move-pane", "tmux move-window"
etc). This will cause repl-send-text to fail.
Fix this by dropping the redundant and potentially incorrect
window/session IDs. The immutable pane ID is enough.
tmux-send-text would silently fail when the repl is no more. Let's
instead print an error, pointing the user to the *debug* buffer which
has tmux' stderr.
Commit 69053d962 (Use menu behavior when completing change-directory,
2022-07-19) made ":cd dir/" actually run ":cd dir/first-subdir",
which can be surprising.
This is usually irrelevant because you rarely type the trailing slash.
However it does happen after correcting an error with `<backspace>`
and friends. For for example,
:cd d<tab>/f<backspace>
results in
:cd dir/
We should probably fix user expectations here. Do this by adding "dir/"
as valid completion. This requires us to allow empty candidates in
"RankedMatch" but there's no harm in that. This means we need to
filter out empty completions from shell-script-candidates elsewhere.
Alternative fix: we could revert 69053d962. This would remove the
convenient menu behavior but that wouldn't be a huge deal.
Fixes#4775
