Commit 5b1f9255 (rc: Use the standard `fail` command to report errors,
2019-11-14) replaced uses of "echo -markup {Error}" with "fail".
This made format-buffer do
echo "eval -client $kak_client %{ fail }" | kak -p $kak_session
Unfortunately "fail" fails in the client spawned by "kak -p" and not
in $kak_client where the user would see the message. Correct this.
While at it, clarify the error message, so users immediately know
that the number is the exit code.
Fixes#3254
*.ini files traditionally use ; but for example the "foot" terminal's
foot.ini uses #. Add a hack to treat ini files as "conf" filetype
if they contain a #-comment (very slim chance of false positives).
This requires to explicitly set comment_line to the default #,
because we set the "ini" filetype earlier.
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>
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.
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>
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.
OCaml does not have line comments, and as far as I can tell neither
does Coq. Setting it to '' (like markdown and html do) throws an error
that can be handled or displayed instead of inserting the default '#'.
kak-lsp uses these faces to mark errors inside the buffer, instead of the Error
face which is much more jarring, and which does not have an associated warning
face. Since the :spell command marks errors inside the buffer, it's also updated
to use this new face.
Adding these faces to Kakoune makes it more likely that colorschemes will
automatically do the right thing when used with kak-lsp, and makes it possible
to use a subtle appearance (like curly underlines) for in-buffer errors while
keeping Kakoune errors bold and jarring as they should be.
If the session wasn't valid anymore by the time the linter finishes,
writing to "$dir"/fifo would hang forever leaving temporary files in
/tmp/kak-lint.XXX and the process alive. This commit fixes that by
not writing to the fifo if the session was not valid.
throwawayaccount12345-1 Copyright Waiver
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.
The off-by-one was introduced by cd9b1e66 which changed `column-1` to `column`.
The refactoring solves some esoteric quoting errors: I think cases like
unbalanced braces in the bufname and client were not supported.
This commit removes the default prompt value from the `spell-replace`
command.
Currently, running the command after selecting a misspelled word
might not allow the editor to propose alternative spellings because
it completes upon whatever is inserted into the prompt. If the words
returned by `aspell` are too different from the currently misspelled
word, no candidates are shown.
For example, selecting “unanymously” and running `:spell-replace`
will not show any candidates under the current implementation (the
‘y’ probably trips the fuzzy-matcher).
The user develops a habit of clearing the prompt every time, because
that's the only way to make sure all suggestions from `aspell` are
visible, so the editor might as well not have any default value for
`:spell-replace`.
