`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.
Rename suffix to tag as it ends up not being the filename suffix,
apply that tag to .o and .d files so that changing the build type
does not wipe/reuse files from another build type.
Make .d file hidden files, this does not seem possible for the .o
files as they are targets and posix support inference rules when only
the suffix changes. This is not a big issue as Kakoune ignores those
files by default.
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
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.
Insert repeat will now only record non-synthesized keys, and when played back
execute mappings as well. Constructing some tests, and with the specific goal
of fixing https://github.com/alexherbo2/auto-pairs.kak/issues/38, this appeared to
be the best approach. Other options could be evaluating the maps only when recording,
but this gave other issues (see tests/normal/repeat-insert/repeat-insert-mapped)
At this point, repeat-insert may be essentially just a hardcoded macro, at least I
haven't identified the difference. If this really is the case, it may make sense to
give it a dedicated register, and implement it as a macro.
Fixes#3600
This test fails occasionally[1] because the order of events and the
number of events varies across runs.
We should always call draw_status exactly 3 times:
[*git*][fifo]
[*git*]
Commit subject etc. [*git*]
Let's check it this way.
This seems to work; this time I took the time to run it a couple
hundred times and in Cirrus CI.
[1] https://builds.sr.ht/~mawww/job/1151239
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.
I saw a crash when running
git log --oneline %arg{@}
hook -once buffer NormalIdle .* %{
execute-keys -draft \
%{gk!} \
%{git diff --quiet || echo "Unstaged changes";} \
%{git diff --quiet --cached || echo "Staged changes";} \
<ret>
}
Backtrace (I still have GDB attached):
#4 0x00006502c740b13f in Kakoune::operator- (rhs=..., lhs=...) at /home/johannes/git/kakoune/src/units.hh:33
33 { return RealType(lhs.m_value - rhs.m_value); }
(gdb) up
#5 Kakoune::Buffer::next (coord=..., this=0x6502c90d7ff0) at /home/johannes/git/kakoune/src/buffer.inl.hh:18
18 if (coord.column < m_lines[coord.line].length() - 1)
(gdb) up
#6 FifoWatcher::read_fifo (this=0x6502c90d9e48) at buffer_utils.cc:252
252 m_buffer.erase(pos, m_buffer.next(pos));
This was introduced in 582c3c56b (Do not add trailing newline to
non-scrolling fifo buffers, 2024-01-28).
The problem seems to be that we call "m_buffer.next()" on a position
that is past-end the buffer, so m_lines[coord.line] is out-of-bounds.
Fix it.
For some reason I have not managed to reproduce the crash, not even
with sanitize=address.
There might be another problem: m_had_trailing_newline is intentionally
uninitialized because it is supposed to be read only on the second
read() with a positive return value. Unfortunately I think it's
possible that e.g. a NormalIdle hook inserts some text before the
first positive read(). Then, this line
const bool is_first = pos == BufferCoord{0,0};
if (not m_scroll and (is_first or m_had_trailing_newline))
pos = m_buffer.next(pos);
will read uninitialized "m_had_trailing_newline". Fix that too, to
be on the safe side. Sadly I don't have a test for this one either
so I'm not sure.
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
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*.
