Staging/unstaging/reverting (parts of) the current buffer's file can
be a common use case.
Today "git apply" can do that based on a selection within a diff.
When the selection is on uncommitted content, we can probably assume
that the intent is to use the part of the selection that overlaps
with the +-side of "git diff" (or "git diff --cached" for
"git apply --cached").
Make "git apply" treat selections as content if the buffile is
tracked by Git. This differentiator is not perfect but I don't know
why anyone would want to use the existing "git apply" semantics on
a tracked file. Maybe we should pick a different name.
This feature couples well with "git show-diff", which shows all
lines with unstaged changes (in future it should probably show staged
changes as well).
Whereas on diffs, "git apply" stages the entire hunk if the selection
contains no newline, this does not happen when operating on content.
I didn't yet try implementing that. I guess the hunks are not as
explicit here.
Closes#5225
This is especially useful to use the indent guides without the other
parameters, but in general it can be a useful option.
It could be worth considering cleaning up these options to default off instead, but
the default also seems useful, so i consider this ok, as it might be the more advanced
usecase.
Technically we seem to be compiling with `-std=c++2a` which (if I
understand correctly) is "all the features we have from 23 and up.
But 20 is the earliest version that compiles for me (with clang). 14 and 17 didn't work.
When using `eval` a new scope named 'local' gets pushed for the
whole evaluation, this makes it possible to temporarily set
an option/hook/alias...
Local scopes nest so nested evals do work as expected.
Remove the now trivial with-option command
A couple of semi-opinionated choices were made in this implementation:
1. The guide is hidden in the first column.
2. The indent guides are highlighted using a new `WhitespaceIndent` face.
3. Nothing is done to continue the guide through empty lines. I believe this to be the correct approach,
at least as long as it is kept as a part of the show-whitespaces highlighter. However some people's
oppinion may differ, and if so, that could be implemented.
4. The guides default to on, like the other show-whitespace options. Default character is "│".
5. Spaces between the indent guides are currently highlighted as other spaces.
Other reasonable options would be no replacement, -tabpad, or a similar -indentpad.
6. Guides are disabled by passing `-indent ""`.
7. Indent guides are separate from tab highlighting.
Additionally, we could consider adding a separate face for the "current" indent level as many editors do,
but this is a bit harder in kakoune because of multiple selections.
Closes#2323
prompt has fuzzy filtering which is more discoverable than the menu
mode's regex filtering (because that one needs / to trigger it).
There are no important differences left, so replace the menu builtin
with a prompt-based command.
prompt does not support markup in the completion menu, so drop that
feature for now.
Read output from the script as it comes and update the candidate
list progressively.
Disable updating of the list when a completion has been explicitely
selected.
Previously, `:doc mapping` hid everything from the beginning of the "expansions"
link up to the "keys" link in the next section (the next occurring comma). Now
the end of the "Mapping commands" section and the beginning of the "Mapping
keys" section are properly visible inside Kakoune.
Make it possible to move the current session to a daemon one after
the fact, which is useful to ensure the session state survives client
disconnecting, for example when working from ssh.
The current exponential behaviour does not seem that useful, it seems
more predictible that pressing `+` twice would end up with 3 copies
of the original selections instead of 4.
Fixes#4533
This switch makes show-matching fallback to the character preceeding
the cursor if the character under the cursor is not a matching
character, which should make show-matching more useful in insert mode.
Sometimes we get people asking why <c-c> can't be mapped. It should be
mentioned in the `:help mapping` documentation, along with any other
unmappable keys.
