Given a completer option with two applicable completions
text|select-cmd1|menu-text1
text|select-cmd2|menu-text2
Kakoune will only show one of them, because they will insert the
same text.
Some language servers send completions like this, for example if
two different importable modules provide the same name. This can be
reproduced using intelephense in this PHP file (cursor is %())
<?php
namespace namespace1;
class sometype {}
?>
<?php
namespace namespace2;
class sometype {}
?>
<?php
namespace test;
some%()
?>
Both completions insert "sometype". The import statement will be
added in an InsertCompletionHide hook by kak-lsp (it uses select-cmd
to determine which completion was selected).
To support this use case, refine the duplicate detection to not filter
out completions with different select-cmd values.
Parsing a (non-valid) font with a comma in the name of the base colour
makes Kakoune crash. It is not a valid face, but Kakoune should just
return an error message instead.
Reproducer:
:set-face global foo ,red@,blue
Note the comma "," after the "@". This is not a valid base name, and it
leads to a crash. Let's see what happens.
At the beginning of parse_face(), we have the following code:
auto bg_it = find(facedesc, ',');
auto underline_it = bg_it == facedesc.end() ? bg_it : std::find(bg_it+1, facedesc.end(), ',');
auto attr_it = find(facedesc, '+');
auto base_it = find(facedesc, '@');
[...]
auto colors_end = std::min(attr_it, base_it);
After this:
- bg_it points to ",red@,blue"
- bg_it != facedesc.end(), so we have underline_it pointing to the first
comma after bg_it. This means that underline_it points to ",blue"
- base_it points to "@,blue"
- attr_it points to the end of facedesc (no "+" marker), so colors_end
points to base_it, "@,blue"
Later in the code, just after parsing the foreground and background
colours, we have:
if (underline_it != facedesc.end())
face.underline = parse_color({underline_it+1, colors_end});
When passing {underline_it+1, colors_end} to parse_color(), we pass in
fact iterators pointing to {",blue", "@,blue"}. Because the second one
starts _before_ the first one in the string, this means that the
resulting string is considered to have a _negative_ length.
parse_color() passes the string to str_to_color(), who fails to turn up
the colour, and attempts to throw:
throw runtime_error(format("unable to parse color: '{}'", color));
The variable "color" still has this negative length, and this goes all
the way down to an assert in src/units.hh where we expect that string to
be >= 0, and we crash on the assertion failure.
For similar reasons, we also get a crash if the comma comes after the
marker for the face attributes:
:set-face global foo ,red+,a
To fix both cases, let's add a check to make sure that the underline_it,
marked with a comma, never gets detected as present and pointing after
colors_end, be it "@" or "+".
As pointed out in [1], when insert mode autocomplete is disabled,
<c-n> could be used to activate insert mode completions temporarily
[2]. This regressed in 6f7c5aed (Do not show custom completions when
autocomplete is off, 2022-01-03). Fix this by enabling completions
on <c-n>/<c-p>. This allows us to remove a special case for explicit
completers.
Alternative behavior (future?): make <c-n> toggle completion like
<c-o>. This can be done today, as suggested by Screwtape on IRC:
map global insert <c-n> %{<c-o><c-n><a-;>:toggle-ctrl-n<ret>}
define-command toggle-ctrl-n %{
hook global InsertCompletionShow .* %{ map window insert <c-n> <c-n> }
hook global InsertCompletionHide .* %{ unmap window insert <c-n> <c-n> }
}
[1] https://github.com/mawww/kakoune/pull/4493#issuecomment-1031189823
[2] <c-n> completion only lives for the lifetime of the completion
menu, whereas <c-o> lasts until you exit insert mode. This means
that autocompletion is much more convenient than <c-n> or <c-x>f,
because those require an explicit completion request for each
path component.
The ThreadedRegexVM implementation does not execute split opcodes as
expected: on split the pending thread is pushed on top of the thread
stack, which means that when multiple splits are executed in a row
(such as with a disjunction with 3 or more branches) the last split
target gets on top of the thread stack and gets executed next (when the
thread from the first split target would be the expected one)
Fixing this in the ThreadedRegexVM would have a performance impact as
we would not be able to use a plain stack for current threads, so the
best solution at the moment is to reverse the order of splits generated
by a disjunction.
Fixes#4519
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
The wrapper for "git blame" creates flags for each line of the buffer.
It parses the output from git and would send a flag (or a series of
flags) each time the commit to blame for a line differs from the
previous one. For files that were touched by a large number of commits,
this results in a high number of kakoune processes being launched, and
may take some time. This is visible in the session through the flags for
the different commits appearing on the lines one by one, possibly during
several seconds.
To speed up the process, batch flags before passing them to the kak
session. One solution could be to send all flags at once, but this might
delay the appearance of commit info for too long if "git blame" really
takes a long time. The alternative solution retained for this commit
consists in grouping as many flags as we can during one second
(roughly), to pass them to kakoune, and then to move on to the next
flags. This way, a new batch of commit information flags appears every
second or so in the client, until all information is added. This should
be much faster than lauching a kakoune process for each commit
reported by "git blame": tests have shown that blaming a large file in
the Linux repository goes 4.5 times faster when batching flags.
Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
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.
This will unfortunately break some use case which will require
using wrapper scripts to add the necessary newline. It is however
harder to do the contrary, and it makes a lot of other use case
possible, such as checksuming.
Fixes#3669
After a while it seems clear changing this is much more ergonomic
and restoring it with pure config is impractical as we need to map
all lower case keys.
Cross-reference the "completers" option, and explain how filtering works.
Originally submitted as part of #4418
Helped-by: Tim Allen <screwtape@froup.com>
As reported in [1], completions provided by "set global completers
option=my_completion" activate insert mode autocompletion, even when
the autocomplete option does not have the insert mode flag.
This happens because InsertCompleter::on_option_changed() calls
InsertCompleter::setup_ifn(), which shows the completion pager.
Fix this by computing whether the completion pager is enabled;
otherwise we can return early from setup_ifn().
The completion pager is enabled if the autocompletion bit is set,
or if the user has requested explicit completion.
[1]: https://github.com/kak-lsp/kak-lsp/issues/585
When `set` or `se` is found at the start of the modeline, it should stop parsing options after `:`.
When `modeline-parse` is called in the following file, it should _not_ recognize `tabstop=4` and `invalid_option=3`.
```
# kak: set indentwidth=0 tabstop=16: tabstop=4 invalid_option=3
```
More info: http://vimdoc.sourceforge.net/htmldoc/options.html#modeline
Now that it is, we get the following error when trying to execute
`test/compose/select-display-columns`
```sh
./enabled: 2: [: 4: unexpected operator
```
This commit fixes the enabled check
Even though the synopsis mentioned `kak -f` accepts filenames, it wasn't clear
to me that Kakoune would filter them in-place by default (I guess I assumed it
would write them to stdout like sed(1)).
