| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Commit eee362087 (Improve info box clearing behaviour, 2025-03-22)
was merged shortly before
commit 1c50bcd89 (rc git: clarify reason for NormalIdle hook, 2025-03-24).
The first commit broke the second in the sense that "git blame-jump" no
longer displays a message in the status line (with commit date/author/subject).
I haven't had time to debug this yet. Revert the part of this cleanup commit
that was broken.
|
|
<a-|> produces \n line endings, which confuses Git when the tracked file
uses \r\n line endings. Work around that.
|
|
When blame and blame-jump invoke "git show" they set a BufCloseFifo hook to
display a statusline message and center the viewport.
As mentioned in the previous patch (which fixed a copy-paste error), the
statusline message does not need a NormalIdle hook. Move it to prevent
such errors.
|
|
When "git blame" fails, it prints an error message to the status line via
a NormalIdle hook. But the hook is only necessary for "execute-keys vv".
(as a workaround for https://github.com/mawww/kakoune/issues/5082).
Since we run "git blame" in the background, it will not trigger a NormalIdle
hook when finished. This means that the "failed to run git blame" message
will only be shown after the next key press.
This problem can be reproduced by first adding a sleep here:
diff --git a/rc/tools/git.kak b/rc/tools/git.kak
index 05e6ff144..bd899365f 100644
--- a/rc/tools/git.kak
+++ b/rc/tools/git.kak
@@ -301,4 +301,5 @@ define-command -params 1.. \
echo 'echo -markup {Information}Press <ret> to jump to blamed commit'
(
+ sleep .1
trap - INT QUIT
if [ -z "${kak_opt_git_blob}" ]; then
and then running ':git blame' in a file that is not Git-tracked.
Reduce the scope of the hook to show this error message immediately.
|
|
My
kak -e 'hook global WinCreate /.* %{ git blame-jump }; edit README.asciidoc'
hangs until I cancel it with <c-c>.
The error is
error while waiting for shell: 1:1: 'evaluate-commands': 3:21: 'execute-keys': no such client: '-draft'
git blame-jump cannot do anything useful without a client in context, so
fail early and explicitly.
|
|
Some of our git wrappers use the diff utility; if it's not installed we'll
hang because no one is opening the fifo for reading. For example, this
happens when running
chmod -x $(which diff) &&
kak -e "edit README.asciidoc; git apply"
Fail earlier, I guess -- although it's probably fine as-is.
|
|
Running "git blame" in a scratch buffer echoes "Press <ret> to jump
to blamed commit" even though the blaming clearly fails. The failure
is silent because cd_bufdir exits the shell, so we don't even attempt
to run "git blame". cd_bufdir prints a "fail" command stdout but that
goes to /dev/null in this case.
I don't really understand why 891a9f5fe (Merge remote-tracking branch
'lenormf/fix-git-tools', 2019-09-22) moved cd_bufdir inside this
background subshell. I guess it didn't matter as much back then when
we didn't have the "Press <ret> to jump" message. Also the existing
error message printed by cd_bufdir for scratch buffers is confusing.
Fail as early as possible, showing a suitable error. Note that "git blame"
does work in filetype=git-diff and filetype=git-log buffers, so don't attempt
cd_bufdir inside those.
|
|
When $PWD is different from $(git rev-parse --show-toplevel, recursive blaming is broken.
For example (assuming k moves to a delted line):
kak -e 'cd src; edit main.cc; git blame-jump; hook -once g NormalIdle .* %{ exec k; git blame-jump }'
Fix this by
1. computing the correct path from diff-parse (we already require
the git command be run in a git directory).
2. passing absolute paths to the recursive "git blame" invocations
|
|
|
|
The code paths around "Missing commit line, assume it is an uncommitted
change" in both blame and blame-jump code look suspiciously similar.
It's possible that we can extract at least something, but there is
a fundamental difference: blame-jump only jumps to another diff,
while blame jumps from diff to blob, which may be a good reason for
keeping them separate.
More specifically, blame-jump passes « $version = "-" » because it's
only interested in the parent commit/file/line, whereas blame wants
to default to using the child commit/file/line (for added and context
lines) and only uses the parent commit/file/line when run on deleted
lines or on uncommitted changes (where HEAD is assumed to be parent
commit even if there is no child).
Unfortunately the blame path forgot to change to use the parent file
for these; fix that and get rid of some code duplication.
|
|
This branch is always taken since we check $diff_line_text above.
|
|
|
|
Surprisingly, these two commands show different commit times:
git blame README.asciidoc
kak -e 'git blame' README.asciidoc
This is because git shows times as of the original time zone (of the
author/committer). Our blame integration uses the current local time.
- blame-jump displays the date in the status line of a git-show buffer
This date may be inconsistent with the buffer's "Date:" header,
so this seems surprising. Fix that. This fixes a test in some
time zones.
- Unlike "git blame", our ":git blame" does not display time zone
info by default. So, the conversion to localtime might make sense.
I don't really have an opinion on this. Change it too I guess,
since the current behavior might not have been intended.
Fixes #5285
|
|
|
|
|
|
|
|
Commit 888b23ffa (Fix grep arguments being evaluated in toolsclient
context, 2024-11-27) had good intentions but it broke commit ef18d3cbf
(rc make/grep: evaluate makecmd in calling context, use eval semantics
again, 2024-07-31), causing makecmd to be evaluated in toolsclient
again. Fix that by passing makecmd via a register, like grep.kak does.
|
|
Commit ef18d3cbf (rc make/grep: evaluate makecmd in calling context,
use eval semantics again, 2024-07-31) fixed a regression in make.kak
but didn't bother to fix a similar regression in grep.kak:
evaluation of both %opt{grepcmd} and %val{selection} were moved
to the toolsclient context.
Move them back to the calling context.
While at it, get rid of the double evaluation of makecmd, for
consistency with grepcmd, and in case makecmd contains unbalanced
braces.
|
|
|
|
|
|
menu no longer supports the -markup switch since 1f1152983 (rc
tools menu: replace menu builtin with a prompt-based implementation,
2023-11-20). That commit removed all markup that ctags passes to menu
but didn't bother to remove -markup switch (because it's ignored).
Let's remove the switch to avoid the need for escaping "{".
Closes #5244
|
|
Take use of the fact that awk's FS already uses regex for splitting
to eliminate the usage of sub() within the actual awk program.
|
|
This fails because the new logic wrongly assumes the presence of a client:
hook global WinCreate /.* 'git show-diff'
The "diff" process hangs because we never write to ${kak_response_fifo}.
After a "pkill diff", the *debug* buffer shows
error while waiting for shell: 1:1: 'evaluate-commands': 3:13: 'execute-keys': no such client: '-draft'
shell stderr: <<<
The client argument is completely unnecessary since we always want
to use the calling context's buffer anyway. Remove it.
Note that we can probably further simplify this by using "write"
instead of a shell process. I'll send that patch along a few other
error handling improvements later.
Closes #5235
|
|
|
|
I used to use a patch that removes cd_bufdir so I didn't notice this
being broken for *git* buffers.
|
|
Staging/unstaging/reverting (parts of) the current buffer's file can
be a common use case.
Today "git apply" can do that based on a selection within a diff.
When the selection is on uncommitted content, we can probably assume
that the intent is to use the part of the selection that overlaps
with the +-side of "git diff" (or "git diff --cached" for
"git apply --cached").
Make "git apply" treat selections as content if the buffile is
tracked by Git. This differentiator is not perfect but I don't know
why anyone would want to use the existing "git apply" semantics on
a tracked file. Maybe we should pick a different name.
This feature couples well with "git show-diff", which shows all
lines with unstaged changes (in future it should probably show staged
changes as well).
Whereas on diffs, "git apply" stages the entire hunk if the selection
contains no newline, this does not happen when operating on content.
I didn't yet try implementing that. I guess the hunks are not as
explicit here.
Closes #5225
|
|
We pipe the output of the patch program to stderr (to have it show
up in *debug*) and print to stdout the remaining diff (the part of
the diff that was not passed to patch).
The next patch wants to use this script in a different way, so move
these decisions up.
|
|
A following patch wants to use this script without wrapping it in an
"evaluate-commands -save-regs e %{ ... }", so simply print the raw
error message and set the register to the caller.
This interface is a bit weird because the error is printed quoted
but for now that just makes things a bit more convenient.
|
|
If a file has unsaved modifications, then the show-diff flags below
such modifications will be wrong. Fix this by using the current
buffer contents, just like the git blame integration does.
This might make it a bit slower, I haven't tested that.
|
|
We call git blame
a. asynchronously in ":git blame"
b. synchronously in ":git blame-jump"
In both cases we
1. create a fifo
2. buffer the file contents in shell memory
3. print to the fifo
4. run git blame and remove the fifo
For the synchronous case the buffering and custom fifo is not
necessary; use ${kak_response_fifo} instead.
For the asynchronous case we do need a buffer that outlives the
enclosing %sh{} block. Buffering in shell memory can be somewhat slow
for large files. Let's use a temporary file instead.
|
|
If stdout is not a TTY, Git never calls a pager, so this is
unnecessary.
|
|
|
|
I configured :make to use a special makecmd for files called test.cpp.
hook global BufCreate .*/test.cpp %{
set-option buffer makecmd "g++ %val{buffile} && ./a.out"
}
Commit c93cb5c4d (Add a `fifo` helper command and refactor `make`
and `grep` to use it, 2024-06-07) made :make evaluate makecmd in the
toolsclient context instead of the calling context, so my buffer-local
override no longer applies. I'm not sure if this is something we want
to guarantee but it doesn't seem unreasonable, and we can fix it a
no cost I think.
Additionally, it changed
eval "${kak_opt_makecmd}" "$@";
to
$kak_opt_makecmd "$@"
meaning that the "&&" in my makecmd will no longer be evaluated.
Instead it will be passed as argument to g++, effectively
g++ %val{buffile} '&&' ./a.out
which I don't think is a reasonable expectation (unless we change
makecmd to be str-list options). Essentially, the above only applies
word splitting to makecmd; it seems simpler and less surprising to
treat them as raw shell commands.
Expand makecmd in the calling client again, and insert it verbatim
into the shell script.
grep hasn't needed it so far but keep it consistent.
|
|
Erlang comments start with `%`. This is correctly highlighted
but the comment-line/comment-block commands don't work correctly.
|
|
|
|
Avoid the brittle `exit; %arg{@}` trick
|
|
Running arbitrary commands in a fifo is very useful in its own right
and factoring out the common pattern is a nice added cleanup.
|
|
|
|
|
|
|
|
|
|
Fail instead of silently doing nothing, this makes it easier to
toggle highlighters using a try/catch
|
|
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
|
|
|
|
`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.
|
