We do not typically go into lengthy explanation of the code in the
support scripts. This would have a performance impact (as comments
are not trimmed in advance) and feels out of place.
The current python filetype module treats a single empty comment line
(typically created by hitting enter twice while in a block comment) as
the end of a block comment, deleting the empty comment and ending
comment prefix copying. This runs contrary to PEP8, which explicitly
allows for paragraphs in block comments, with an empty comment as the
paragraph separator.
This change implements support for using a single empty comment as a
paragraph separator, with two consecutive empty comments being treated
as the end of the block comment; both empty comment lines are deleted
and comment prefix copying is ended.
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.