Most diff consumers we've written only care about the "final" state
after parsing through a diff. Let's extract the diff parsing part,
for reuse in several new commands.
In future we should try to use this (or better, a diff-parsing library)
for patch-range.pl. We'd add a callback argument that is invoked once
perl hunk (or line). Unfortunately I haven't found that library for
Perl yet.
Diff buffers created by ":git diff" differ from other filetype=diff
buffers in that they use "git rev-parse --show-toplevel" as root
directory for diff-jump. This makes sense because paths printed by
"git diff" are relative to that directory.
Today we handle the above difference by making ":git" override the
diff-jump mapping. This doesn't work for buffers that were read from
a file. Fix this by introducing a separate filetype, "git-diff",
which allows to move the mapping in the usual place.
This breaks existing filetype=diff hooks[1] which need to be adapted
to match git-diff (also git-log).
Another motivation for the separate filetype is that a following
patch wants to enable Git blame commands in git-diff buffers but
not in plain diff buffers -- those should keep being blamed like any
other file if tracked by Git.
Perhaps git-* buffers are for Git metadata, not files that are tracked
by Git.
The added hooks awkwardly include their hook parameter to work around
hook ordering issues when switching between filetypes. See also [2].
We could also use filetype=git-log instead of git-diff.
Our highlighting for "git log --graph" would have rare false positives.
Closes#5049
[1]: https://github.com/search?utf8=%E2%9C%93&q=filetype%3Ddiff+language%3Akakounescript+-repo%3Amawww%2Fkakoune+-is%3Afork&type=code
[2]: https://lists.sr.ht/~mawww/kakoune/%3C20240201091907.973508-1-aclopte@gmail.com%3E
When a buffer has unsaved deleted/added lines, then any blame
annotations below those lines may be off. Fix this by feeding the
latest buffer contents to Git. Unfortunately there is no easy way
to distinguish between "Unsaved" and "Saved but not committed yet"
so let's keep using the umbrella term.
We double-parse a command definition to figure out the location of
a support script at load time. This feels a bit dangerous and is not
really necessary, so use %val{runtime}/rc/tools/... instead.
Reference: https://lists.sr.ht/~mawww/kakoune/%3CZbOSCK2JjJvo-RTt@gmail.com%3E
Patches as produced by "git format-patch" have a trailing signature
that is separated from the body by a line with "-- " on it. By default
it contains the Git version. We erroneously include this signature
in the diff we pipe to patch, which fails to apply as a result.
Add a targeted fix to suppress these signatures.
Sometimes a patch that fails to apply will apply cleanly after
adding -3. Also sometimes we do want to apply with conflict markers.
So this is another somewhat common option.
Sorry I did not test my earlier patch in production. It passes
blame flags via the environment. On a 5000 line file this results in
"execve failed: Argument list too long" errors.
Use a different way of checking whether blame info is shown.
Since :patch transforms its inputs into context-only lines, we can
easily get into a state where a file diff has only context lines.
git apply does not accept a "diff" without any hunk, so let's skip
that.
It is not an obviously better result than just displaying results
from each tag file, so remove sorting to take advantage of live
completion updates
As discussed in #5081
As of recently, shell script candidate completions are computed in
the background, and displayed incrementally.
Sorting completions means we can't show partial results.
We do this for "ctags-search"; but if there is only one ctags file
there is already a sensible order (which is slightly different than
what GNU sort does). So let's preserve the order in that case.
The number of completions is probably too high for an order to be useful.
Similarly, for "man", sorting is probably not very helpful because
there are so many results.
See https://github.com/mawww/kakoune/pull/5035#discussion_r1413015934
The last update is from 2017, it's pretty outdated. Current
support was combined from existing languages such as Ruby and
Zig and tweaked to fit the Pony language.
Today "with-option foo bar command-that-fails" fails with
Error: 1:1: 'evaluate-commands': 1:1: 'with-option': 2:5: 'evaluate-commands': 4:9: 'evaluate-commands': 1:2: 'no-such-command': no such command
but leaks the option value. Fix this by resetting the option and
rethrowing the error. Unfortunately the original stack trace is lost
(questionable behavior inherited from C++?).
The awk-generated highlighters in scheme.kak need '\\.' to obtain '\.'
in the generated kakscript output. Fix the inf/nan rule (which should
generate '(?:inf|nan)\.0') to read '(?:inf|nan)\\.0' in the awk.
The current handling of preprocessor directives in filetype/c-family.kak
leads to a wall of solid colour for more complicated #if or #define
directives, although #include is already nicely highlighted.
Instead of highlighting an entire directive with the meta face, highlight
just the #define, #if or #elif keyword as meta, treating the rest of the
directive as normal c-family expressions. This significantly improves
the readability of complex macro definitions.
For directives other than #define, #if and #elif, we treat the rest of
the directive as an opaque string in normal face rather than trying to
highlight it, covering cases like #error, #pragma, etc. where the rest
of the line is an error message string or other non-expression content.
This does the right thing for #ifdef and #ifndef too, as we don't highlight
identifiers in c-family text so their arguments should be normal face
anyway.
We already pull in the diff module in mail.kak to enable the nice
:diff-jump behaviour on inline patches. Also enable the shared/diff/
highlighter underneath our shared/mail/ highlighter for inline diffs,
listing it first so mail patterns take precedence over diff patterns.
De-emphasise signatures including the standard '^-- \n' separator in the
same way as quoted text in a reply.
Fixes: https://github.com/mawww/kakoune/issues/4998
When using either of
set-option g completers option=my_option
prompt -shell-script-candidates ...
While the search text is empty, the completions will be sorted
alphabetically.
This is bad because it means the most important entries are not listed
first, making them harder to select or even spot.
Let's apply input order before resorting to sorting alphabetically.
In theory there is a more elegant solution: sort candidates (except
if they're user input) before passing them to RankedMatch, and then
always use stable sort. However that doesn't work because we use a
heap which doesn't support stable sort.
Closes#1709, #4813
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.
