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)).
In normal mode, the mode line contains "1 sel" or "n sels (k)" when n > 1,
whereas in insert mode, it contains "n sels (k)" even for n == 1. Change
the contents in insert mode to match normal mode.
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.
trim_indent call was incorrect, trim_indent is intended to work
on multi-line strings and trims trailing whitespace as well (could
benefit from a better name).
Fixes#4378
adds the ability to press <ret> within a hunk and navigate to the original
source code. This can be useful because one often needs to go back and forth
between the diff and the full source code.
- You can press <ret> anywhere _within_ a hunk i.e. lines that start with
` `, `+`, `-`. You will be taken to the exact line in the source that corresponds
to where you pressed <ret> in the hunk. It actually does not make sense
to press <ret> on a `-` line because that does not exist anymore but
in that case you are taken to a nearby line in the hope this is still useful.
- You can also press <ret> on a range line (lines that
look like @@ ... @@). If you press <ret> on anywhere on a range line e.g.
```
@@ -120,3 +123,4 @@ fn some_function {
```
The code will try to navigate to the section heading "fn some_function {"
Note that the section heading is _not_ necessarily located at the
range line (in the above example the range line is 123).
- You can press <ret> on a +++ line also and you will be taken the first
line of the file
Caveats:
- Navigation to the original source file will be accurate only if any edits to
the original source file have been saved to disk, because otherwise
they will not be detected by the `:git diff` or `:git show` commands
- This feature should work well for most typical uses e.g. `:git diff`, `:git diff HEAD^`
`:git diff <some-sha1>`. In fact this feature should work in all scenarios when
the *current files* on disk are being compared _with_ some arbitrary git revision/staging.
It will be less useful in other scenarios when two arbitrary revisions are being
compared to each other or when you are trying to compare staging to some revision.
For example when you invoke `:git diff --staged` you are trying to compare staging
with HEAD but are navigating to what is currently on disk (which may be different
from staging).
Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Merge all lookarounds into the same instruction, merge splits, merge
literal ignore case with literal...
Besides reducing the amount of almost duplicated code, this improves
performance by reducing pressure on the (often failing) branch target
prediction for instruction dispatching by moving branches into the
instruction code themselves where they are more likely to be well
predicted.
Only ui type Terminal is intended to be a user interactive session.
If your ui type is not Terminal, don't worry about making
the tty your stdin if fd 0 is not a tty.
This allows json-rpc commands sent via stdin to be acted up rather
than sent to a fifo (which is the default behavior for kakoune).
Does not change the behavior for Terminal ui sessions
Now that Kakoune opts into extended key reporting, <c-i> is correctly
reported and hence needs to be mapped to forward jump.
We still need to keep <tab> mapped to it for legacy terminals.
Should fix#4333
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.
As per man page eval(1p):
> The eval utility shall construct a command by concatenating arguments together,
> separating each with a `<space>` character. The constructed command shall be
> read and executed by the shell.
When not quoting `$kak_opt_makecmd` in the eval, the variable is split by
newlines and spaces and then joined by spaces to form the command. If there
were newlines in `$kak_opt_makecmd`, the command would be malformed.
To reproduce:
```kak
set-option global makecmd "
echo foo
echo bar"
make a b c
```
Expected output in the `*make*` buffer:
```
foo
bar a b c
```
Actual output:
```
foo echo bar a b c
```
This patch fixes this.
