I personally mostly use "git blame-jump" so this "git blame" bug has
flown under the radar. When we run git blame in a git-diff buffer,
we want to move one column to the left since the lines in the target
blob don't have the +- prefix. We already subtract one but we add it
back accidentally when using "l" to go to this column. Fix it.
In future we should try to preserve more of the selection(s), not
just the main cursor.
When running git blame in a "git show" buffer, we annotate the youngest
version of the file that has the line referenced by the diff line
at cursor.
In case the cursor is on an added or context line, we simply show
the version from the surrounding commit.
When the cursor is on a deleted line, we show the parent commit,
which still has the deleted line. However there is a bug: we use
the line number in the new version of the file. Fix that.
Commit 53d9b9b67 (Escaping tweak in git.kak, 2024-02-06) broke
blame-jump when the commit subject contains a single quote.
(Also on unbalanced "{" which is a rare edge case but we already have
it in our Git history.)
git.kak assumes that filenames don't contain ' or unbalanced {,
but we can't really make that assumption about people's names or
commit subjects.
Unfortunately the escaping here is very messy. We need to pass
arbitrary text to callbacks; maybe we should have closures that can
capture private temporary registers.
Our "git add" and "git rm" default to the current file. The shell
interprets globs in the filename, which can lead to surprising results,
for example if it's accidentally used on a scratch buffer like *git*.
If I run
git blame
execute-keys 10o<esc>,j
git blame-jump
that'll jump to the wrong commit.
Use a flag-lines option to tell if a line still has blame information
cached.
Closes#5084
Today we can recursively search history with "git blame-jump". However
that command has some drawbacks, mainly that it's blocking. Making
it async without any progress indicator might be confusing. Better
to run plain "git blame"[1] and press Enter.
Also it might be nice to enable recursive searches using only "git
blame" and `<ret>` (since that is bound to "git blame-jump" while
blame annotations are displayed).
Make "git blame" in git-diff/git-log buffers run "git show
$commit:$file" for the commit and file at cursor, and decorate this
blob view with blame annotations. The latter allows to use `<ret>`
and repeat.
Unfortunately this relies on a hidden option "git_blob" to keep the
commit ID and filename. Maybe we can put this metadata somewhere
else like the buffer name or contents, ideally in a way that survives
serialization.
I'd still keep "git blame-jump" because it seems faster for the common
case of tracking down a single line.
[1]: In my testing, "git blame --incremental" is not any slower than
"git blame -L123,123" at finding that line.
Running git blame signals intent to view the blamed commit. Let's make
`<ret>` to go to that commit+line as long as blame info is shown.
In diff buffers we already use `<ret>` for "diff-jump".
Like blame annotations, the blame-jump mapping lives in window scope.
This means it will not collide with "diff-jump" which is mapped in
buffer scope.
Add the mapping synchronously (unlike the rest of the git-blame code)
to perhaps allow the user to override the mapping:
git blame; map window normal <ret> ...
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).
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.
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.
Running an invalid command like "grep -abc" shows no output at all.
Let's give better feedback by showing the error message from grep.
We used to do this until an unrelated change, bd5955c73 (grep: remove
eventual \r, 2013-02-13).
This adds a somewhat discoverable frontend for common uses of the
patch command.
Here are some frequently used commands
# apply selected changes
git apply
# revert selected changes
git apply -R
# stage selected changes
git apply --cached
# unstage selected changes
git apply --cached -R
# apply selected changes and stage them
git apply --index
For everyday use that's a lot of typing so I recommend adding mappings.
One of the features I miss most from Magit/Fugitive/Tig is to
apply/revert/stage/unstage individual hunks or even exactly the
selected line(s). This provides a much more convenient way of
splitting changes than "git add/restore -p".
Implement a "patch" command that applies the selected lines within
a diff by piping them to the "patch" program.
It can also feed other programs like "git apply" (see the next commit).
Original discussion: https://discuss.kakoune.com/t/atomic-commits-in-kakoune/1446
Interestingly, :patch is defined outside the "patch" module. This is
to make it readily available for interactive use.
Putting it into the module does not save any work.
I tentatively added a patch module anyway so we can explicitly declare
this dependency.. although there is the argument that this is not
really needed?
This commit adds `diff_add_char`, `diff_mod_char`, `diff_del_char` and `diff_top_char` as `str` options, with typical
defaults.
This commit also replaces the hard coded +, _, ≃, etc. hardcoded characters in `git update-diff` to use the options from
above.
