Our ":git blame" annotates each line with the most recent commit.
However often a line has been modified by several commits.
Introduce ":git blame-jump" which shows the commit that added the
line at cursor. Crucially, it works also in Git diff buffers, so it
can be used recursively to find the full history of a line.
To do the recursive blame from a diff, I need to navigate to the
old (deleted) version of a line. Since old and new line are usually
neighbors. Speed up the common scenario of finding the old version
by making ":git blame-jump" jump to the new version. This means the
initial diff view might not include the commit message etc. Compensate
this by showing the commit's date+author+subject in the status line.
Here are some test cases.
- run blame-jump after "git blame"
- create an uncommitted or unsaved line, run "git blame" and
"blame-jump" on the uncommitted line
- run blame-jump without running "git blame"
- run blame-jump in "git show"
- run blame-jump in "git diff HEAD"
- run blame-jump in "git diff --cached"
- run blame-jump in "git diff" (YMMV if there are cached changes,
could fix that)
Naming: there are some similar commands in the wild [1];
they are usually called "show-blamed" or similar, but they
don't jump to the corresponding line. Also our list of git
commands is getting a bit messy (especially the undocumented
show-diff/hide-diff/next-hunk/prev-hunk; subject first naming seems
better).
[1]: f6e78ec4c0/kakrc (L423)
Future work: to go back to the previously-blamed commit we need to
have had the foresight to use "rename-buffer". Perhaps we want to
add some kind of buffer stack (like Magit does for example).
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.
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.
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
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.
