Patches as produced by "git format-patch" have a trailing signature
that is separated from the body by a line with "-- " on it. By default
it contains the Git version. We erroneously include this signature
in the diff we pipe to patch, which fails to apply as a result.
Add a targeted fix to suppress these signatures.
Sometimes a patch that fails to apply will apply cleanly after
adding -3. Also sometimes we do want to apply with conflict markers.
So this is another somewhat common option.
Sorry I did not test my earlier patch in production. It passes
blame flags via the environment. On a 5000 line file this results in
"execve failed: Argument list too long" errors.
Use a different way of checking whether blame info is shown.
Since :patch transforms its inputs into context-only lines, we can
easily get into a state where a file diff has only context lines.
git apply does not accept a "diff" without any hunk, so let's skip
that.
It is not an obviously better result than just displaying results
from each tag file, so remove sorting to take advantage of live
completion updates
As discussed in #5081
This test doesn't care about testing things like "if I send the next
key before we have finished reacting to the previous ones, nothing
bad ever happens".
Hence we can until exhaustion after each input. This should fix
bespoke flakiness. The handling of "c<esc>" should be atomic.
This reasoning probably applies to most tests; waiting for all events
seems like the safest and easiest approach overall (compared to sleep
or sleep-until). The downside is that the tests need changes when
UI code changes but it rarely does, and if it does we can automate
the updates.
Closes#5073
As of recently, shell script candidate completions are computed in
the background, and displayed incrementally.
Sorting completions means we can't show partial results.
We do this for "ctags-search"; but if there is only one ctags file
there is already a sensible order (which is slightly different than
what GNU sort does). So let's preserve the order in that case.
The number of completions is probably too high for an order to be useful.
Similarly, for "man", sorting is probably not very helpful because
there are so many results.
See https://github.com/mawww/kakoune/pull/5035#discussion_r1413015934
The last update is from 2017, it's pretty outdated. Current
support was combined from existing languages such as Ruby and
Zig and tweaked to fit the Pony language.
It turns out diffing was pretty fast, but applying the diff was
sub-optimal as it was constantly inserting/erasing lines which
led to lots of unnecessary shifting. Fix this by manually tracking
a read/write iterator and only shifting when necessary (on keeps,
and inserts).
Today "with-option foo bar command-that-fails" fails with
Error: 1:1: 'evaluate-commands': 1:1: 'with-option': 2:5: 'evaluate-commands': 4:9: 'evaluate-commands': 1:2: 'no-such-command': no such command
but leaks the option value. Fix this by resetting the option and
rethrowing the error. Unfortunately the original stack trace is lost
(questionable behavior inherited from C++?).
The awk-generated highlighters in scheme.kak need '\\.' to obtain '\.'
in the generated kakscript output. Fix the inf/nan rule (which should
generate '(?:inf|nan)\.0') to read '(?:inf|nan)\\.0' in the awk.
Kakoune's balanced strings require that delimiter characters nested inside
them are also paired, so for example in %{ }, each nested { must occur
before a corresponding } to balance it out.
In general this will automatically be the case for code in common scripting
languages, but sometimes regular expressions used for syntax highlighting
do end up containing an unbalanced bracket of one type or another.
This problem is easily solved because there is a free choice of balanced
delimiter characters. However, it can also be worked around by adding
a comment which itself contains an unbalanced delimiter character, to
'balance out' the unpaired one in the regular expression.
These unbalanced comments are not ideal as the semantic role they perform
is easy for a casual reader to overlook. A good example is
catch %{
# indent after lines with an unclosed { or (
try %< execute-keys -draft [c[({],[)}] <ret> <a-k> \A[({][^\n]*\n[^\n]*\n?\z <ret> j<a- gt> >
# indent after a switch's case/default statements
try %[ execute-keys -draft kx <a-k> ^\h*(case|default).*:$ <ret> j<a-gt> ]
# deindent closing brace(s) when after cursor
try %[ execute-keys -draft x <a-k> ^\h*[})] <ret> gh / [})] <ret> m <a-S> 1<a-&> ]
}
in rc/filetype/go/kak. Here, it is not instantly obvious that the comment
containing an unmatched { is required for correctness. If you change the
comment, delete it or rearrange the contents of the catch block, go.kak
will fail to load, and if you cut-and-paste this code as the basis for
a new filetype, it is a loaded gun pointing at your feet.
Luckily, a careful audit of the standard kakoune library turned up only
three such instances, in go.kak, hare.kak and markdown.kak.
The examples in go.kak and hare.kak are easily made robust by replacing
a %{ } with %< > or %[ ] respectively. The example in markdown.kak is
least-intrusively fixed by rewriting the affected regular expression
slightly so it has balanced { and } anyway.
