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
In a noninteractive shell, asynchronous commands ignore SIGINT and
SIGQUIT. We typically use such shells to feed fifo buffers which we
do want to cancel them on Control-C. Make it so.
Same for SIGQUIT; that one is not typically used but I expect that
along the Kakoune server it kills any child processes that (haven't
been daemonized).
Note that for unknown reasons, Bash already doesn't ignore SIGINT in
async processes that use "eval".
Note that Dash has a bug that prevents this from working;
proposed fix is at
https://lore.kernel.org/dash/20240329153905.154792-2-aclopte@gmail.com/
(While at it balance out some parens, to help the m command)
Commit e43c7d6ab (Use complete-command for the :doc command,
2022-10-19) forgot to carry over the "-menu" flag, which means that
:doc completions are no longer auto-selected, even though they are
the only valid inputs.
Fix that.
Closes#4790
The tmux-terminal commands typically run
tmux split-window kak -c ${kak_session} </dev/null >/dev/null 2>&1 &
The tmux process runs in the background with output silenced. This is
not necessary because "tmux split-window" is a thin client that
merely forwards its arguments to the tmux server. All our wrappers
for other terminal-servers (kitty, iterm, screen, wezterm, zellij)
simply run in the foreground, not silencing any errors.
The tmux backgrounding was added in 208b91627 (Move client.kak as
x11.kak and change tmux.kak to be its peer, 2015-11-17), probably for
consistency with x11.kak. That one is different however because it
potentially spawns a full terminal, not just a client that briefly
talks to a terminal server - that's why x11-terminal needs to use
"setsid," to avoid killing said terminal when we signal our process
group.
Remove the backgrounding from tmux.kak for consistency and to reduce
surprise.
`grep-next-match` works only on the `*grep*` buffer so it can't be used
on buffers that were preserved by renaming or on other grep-flavored
buffers created by 3rd party plugins kakoune-find and kakoune-lsp,
like `*find*` and `*references*`.
Let's generalize `grep-next-match` with a `jump-next` command that
takes a buffer argument.
This renames some options but I think they're not commonly used.
kakoune-lsp is an exception that uses grep_current_line but it's no big
deal, things will fail loud and early if options are missing.
Since grep.kak and friends now depend on jump.kak, move the jumpclient
declaration there as well.
Since the default make error pattern spans until the end of the
line, make-jump select the whole line, moving the cursor to the end.
This is especially bad when the error message is very long and hence
the cursor movement scrolls the viewport so the file:line:col is no
longer visible.
Stop moving the cursor in `*make*` and `*grep*` buffers.
We already have highlighting to indicate the current line.
Given
make[1]: Entering directory '/home/johannes/git/kakoune/src'
main.cc:66:9: error: expected ‘}’ before ‘asdf’
If I select the whole second line, including the newline, make-jump
fails with an enigmatic "no such file or directory main.cc". This is
because `gl` does not move the cursor away from the newline. Fix it.
This appears to have regressed in 80d661e6a (rc/: More consistent
uses of regex syntax, 2017-09-29).
If a user modifies a grep buffer, we can end up in weird situations
where we try match a filename over multiple lines.
Let's rule out newlines in filenames here. There is an argument
this is a case of GIGO but we already do this for the corresponding
highlighters.
We also do it in make.kak, see ca225ad4d (Cleanup make.kak and optimize
the make-next/make-prev regexes, 2016-12-09). There is one case left
where a filename would theoretically span multiple lines. Fix and
optimize this too.
grep-jump and make-jump[*] support Windows-style paths like C:\path.
However grep-next-match and make-next-error don't, which suggests
that no one uses this feature. IIRC Cygwin mounts Windows drives in
proper Unix paths like /mnt/drive_c.
Let's remove it for simplicity and consistency.
This reverts commit 6c47b204e (Support windows style path in grep
output, 2014-11-11).
[*]: Though make-jump recently regressed in 8e5ca3f21 (rc/make.kak
introduce a new option to be back compatible, 2023-10-27) by failing
to capture the "C:" prefix.
Commit 36efbf4cb (rc filetype diff: extract diff parsing from
diff-jump, 2024-02-03) moved the "set-register |" command but failed
to move the "-save-regs |". This surfaces as register leakage in
"git blame-jump". Fix that.
Similar to the previous patch, when git blame fails it usually means
that the blamed file is not tracked by Git. I don't know of other
common failure scenarios.
Since git blame runs in detached process, failure handling is a bit
more involved. Let's forward stderr to the debug buffer and escalate
the error. I'm not sure how to get the exit code from git blame in
"git blame | perl" - we can't use $PIPESTATUS.
As a workaround, interpret empty output as failure.
In case of failure, also hide blame; this makes the UI more consistent
I think.
git blame typically fails when the buffile is not tracked by Git.
Let's escalate the failure early instead of continuing witout blame
data, only to eventually hit the generic
"git blame-jump: missing blame info" error.
I frequently run ":git diff" followed by ":git blame-jump" to find
the commit that added the lines I deleted. I wasn't sure whether
":git blame" should allow this use case too. I think it should,
I don't think this is too confusing.
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).
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
