`x` is often criticized as hard to predict due to its slightly complex
behaviour of selecting next line if the current one is fully selected.
Change `x` to use the previous `<a-x>` behaviour, and change `<a-x>` to
trim to fully selected lines as `<a-X>` did.
Adapt existing indentation script to the new behaviour
The canonical way to disable all auto-insertion hooks is
set-option global disabled_hooks .*-insert
A recent change allowed to disable hooks that insert ) and }
independent of hooks that insert // (a step in the right
direction, we should do it for more filetypes).
Since the new hook ("go-insert-closing-delimiter") doesn't match
.*-insert, it broke the above snippet. Fix this by renaming it to
"go-closing-delimiter-insert".
This makes it a bit less obvious how to disable only comment insertion.
Not sure if there's interest in that, but make it easier by renaming
"go-insert" to "go-comment-insert".
In TOML's triple-quoted strings, it's allowed to place quotes just
next to the triple quotes.
foo = '''bar''''
^ part of the string contents
^^^ closing sequence
We greedily interpret the first three single quotes as closing
sequence. As a result the remaining single quote wrongly opens a new
string. Fix this by only treating triple quotes as closing if they
are not followed by another quote.
I don't think there is another possible interpretation of quadruple
quotes in TOML, so this should not affect other valid inputs.
Fixes#4143
Changed the indentation behavior such that an extra level of
indentation is added after a line containing a ( or { that is
not closed on the same line instead of aligning to the unclosed
( or {. This is consistent with how `go fmt` formats source code.
Added regression tests.
When indenting on newline in Go files, only remove trailing whitespace
on the previous line and copy indentation of the previous line if in
comment context.
Added regression tests.
Add a separate hook group for inserting ) and } on newline because the
current implementation does not work in 100% of cases and should be
able to be disabled independently of copying comment characters (which
is much easier in comparison to get right) if one does not care about
this feature.
While Wayland offers nothing general to help us support `focus` on all
window managers, WM-specific implementations are generally possible.
Sway is a tiling window manager that mimics i3, and has a reasonably
powerful CLI that can help us achieve this.
In addition to supporting `focus` for Sway, this change paves the way
for additional WM-specific Wayland functionality by adding a detection
step to wayland.kak, in a similar fashion to detection.kak.
An indent hook automatically adds whitespace, so it seems prudent to
add the hook to remove unwanted whitespace again. This is what we do
in most languages already.
Some languages have a trim-indent command but don't use it (for no
apparent reason). Make them trim trailing spaces when exiting insert
mode, like most other languages support scripts do.
An OCaml comment is `(* Some comment *)`. Like the C-family this can be
a multiline comment.
Recognize when the user is trying to commence a comment when they type `(*` and
then automatically insert `*)` on behalf of the user. A small convenience.
Co-authored-by: Maxime Coste <mawww@kakoune.org>
Fixes the handling of multiple backslashes before gitignore * and ?
glob patterns. Adds character classes to gitignore highlighting.
Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
Commit 85b78dda (src: Select the data inserted by `!` and `<a-!>`,
merged on 2021-03-06) broke autorestore by making it delete the
restored content. I've been using it for 6 months but never noticed
since I didn't use autorestore
Reproducer:
HOME=$PWD kak -s foo README.asciidoc -e 'exec iUNSAVED-CONTENT'
# In another terminal:
ps aux | awk '/kak -s foo/ {print $2; exit}' | xargs kill -HUP
HOME=$PWD kak -s foo README.asciidoc
Delete the trailing newline instead of the restored content.
While at it, remove some <space> commands from execute-keys, to make
it work on the breaking-cleanups branch which swaps <space> and ",".
Closes#4335
Add a group to the `file-detection` hooks.
There's no way to remove hooks without a group. With this patch, you'll be able to remove those
`file-detection` hooks manually. There's no need for two separate groups since if you wanted to
remove only one, you could run `remove-hooks` and then only add one again.
Related: #3670
There is a bug that causes `:git show-diff` to fail when using an external diff, for example difftastic.
This change ensures that we don't use an external diff tool when diffing the current buffer.
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
Go 1.18 introduces the `any` and `comparable` predeclared identifiers. Modify
the list of identifiers here, so syntax highlighting will catch these new
identifiers. See https://go.dev/ref/spec#Predeclared_identifiers.
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
*.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.
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.
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
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>
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.
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 '#'.
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".
This commit makes several improvements to the Lua indentation logic.
- Don't indent if the keyword is inside a string or comment
- Indent inside "do end"
- Indent inside "repeat until"
- Indent after a line ending with "{" or "("
- More accurate un-indentation for the "end" keyword
For the last point, previously we tried to match the indentation of the
starting keyword of the block. However, sometimes this guessed wrong
and produced the wrong indentation, as the following example shows. The
new logic is to indent the "end" by one less level than the contents of
the block.
while true do
if false then
end
end -- This was incorrectly matched with the "if"
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.
rockspec files are used by [Luarocks](https://luarocks.org/), the
most prominent package manager for Lua. Despite the different file
extension, these files are actually Lua files and should be syntax
highlighted as such.
For what it is worth, Neovim also does the same thing that I am doing in
this commit. They recognize both ".lua" and ".rockspec" as being Lua
files (and no other extensions, as far as I know).
