Passing large diff buffers via the environment can quickly result in
the error "execve failed: Argument list too long". Use a pipe like
in format.kak
When running | (or <a-|>), Kakoune does not use %arg{@} to populate
"$@" (missing feature?). Work around this by moving %arg{@} to a
temporary register. Apparently $kak_quoted_reg_a will never be an
empty list, so work around that too.
When diff parsing fails, we take care to run "fail" in the calling
client, unlike :format (probably a bug in format.kak).
(This patch is best viewed while ignoring whitespace changes (diff -w))
Mapping in the filetype hook matches others like grep.kak and man.kak.
Since we map in buffer scope, git diff buffers will override diff-jump
with git-diff-goto-source.
This means that the diff-jump binding applies here:
diff -u "$1" "$2" | kak -e 'set buffer filetype diff'
Reported in: https://github.com/mawww/kakoune/issues/153#issuecomment-1030643854
A recent commit wrapped diff.kak into a module. The module includes the
hook that adds diff highlighting to filetype=diff buffers. This means
that the hook is only loaded after opening the first diff buffer in a
Kakoune session, so it only actually fires for the second diff buffer.
Fix this by moving the hook out of the module.
Fixes#4525
This allows to jump from a mail buffer that contains an inline diff
to the source files (most accurate when the patch has been applied
locally).
This makes the diff module a mandatory dependency; we could relax that.
When reading and writing emails that contain patches (possibly
email-quoted), it can be convenient to the jump to the source file.
Allow this by making diff-jump (bound to <ret> in git-diff
buffers) ignore leading email quotes ("> "). A line that starts with
"> " should not occur in a unified diff, so this won't affect other
use cases.
Observe that diff-jump even works around interleaved replies; they
will not affect the computed line numbers because we ignore lines
that don't match ^(> )*[ +-].
git-diff-goto-source is specific to diffs produced by Git. This patch
generalizes the logic and moves it to a new diff-jump in diff.kak.
The main differences are:
- diff-jump handles plain file diffs (i.e. without the -r option). These
have no "diff" line. This means that it needs to parse +++/--- instead.
- diff-jump can go to the old file, not just the new one.
- diff-jump allows to override the base directory and the number of
directory components to strip.
git-diff-goto-source was implemented with several nested try/catch
blocks. Implementing the extra features would have added more
nesting, redundancy or hidden options. To avoid that, I ported the
parsing logic to Perl (which git.kak already depends on). Maybe
it's possible to do the same in awk.
Potential concerns:
- We could move diff-jump to a new rc/tools/diff.kak but then it's not
obvious where the "diff" module belongs to.
- Should diff "diff-jump -1" be spelled "diff-jump -p1"?
In future, the diff parser could be reused to implement a vimdiff-style
feature: given a diff and the "old" line number, we can compute the
corresponding "new" line number. Perhaps diff-jump should get a -client
argument.
We want to move git-diff-goto-source from rc/tools/git.kak
to rc/filetype/diff.kak (or should we could create
rc/tools/diff.kak?). Either way, create the diff module so we can
formalize this dependency.
Currently this module only provides highlighters, so require it
wherever we reference them.
Keep the diff-select-{file,hunk} commands outside the module because
people might already use them in git buffers.
C has header and source files and you need to often switch between them.
Similarly OCaml has .ml (implementation) and .mli (interface files) and
one often needs to switch between them.
This commit provides a simple functionality that allows you to accomplish this.
The closing ``` in the following example was not detected because the
indented code block highlighter was higher up in the hierarchy than the
fenced code block highlighter:
```
indented
```
The codeblock highlighter used to be inline so that it has an effect
inside listblocks. This commits adds a listblock/codeblock highlighter
as a replacement.
Fixes#4351
- Also insert "end" after "do", "else" and "elseif"
- Do not insert "end" after strings or comments containing keywords
- Only insert "end" if the block is empty
An example of the last item is if we want to add a new line to the start
of an unclosed block that already contains statements. @ is the cursor.
-- before
if a then@
x = 1
y = 2
-- after
if a then
@
end
x = 1
y = 2
In this case, inserting the "end" before the statements is probably not
what the programmer wants. It might make more sense to insert the "end"
after the statements, but that is potentially confusing due to spooky
action at a distance. I think the least confusing thing to do in this
situation is to not insert the "end".
