menu no longer supports the -markup switch since 1f1152983 (rc
tools menu: replace menu builtin with a prompt-based implementation,
2023-11-20). That commit removed all markup that ctags passes to menu
but didn't bother to remove -markup switch (because it's ignored).
Let's remove the switch to avoid the need for escaping "{".
Closes#5244
This fails because the new logic wrongly assumes the presence of a client:
hook global WinCreate /.* 'git show-diff'
The "diff" process hangs because we never write to ${kak_response_fifo}.
After a "pkill diff", the *debug* buffer shows
error while waiting for shell: 1:1: 'evaluate-commands': 3:13: 'execute-keys': no such client: '-draft'
shell stderr: <<<
The client argument is completely unnecessary since we always want
to use the calling context's buffer anyway. Remove it.
Note that we can probably further simplify this by using "write"
instead of a shell process. I'll send that patch along a few other
error handling improvements later.
Closes#5235
Staging/unstaging/reverting (parts of) the current buffer's file can
be a common use case.
Today "git apply" can do that based on a selection within a diff.
When the selection is on uncommitted content, we can probably assume
that the intent is to use the part of the selection that overlaps
with the +-side of "git diff" (or "git diff --cached" for
"git apply --cached").
Make "git apply" treat selections as content if the buffile is
tracked by Git. This differentiator is not perfect but I don't know
why anyone would want to use the existing "git apply" semantics on
a tracked file. Maybe we should pick a different name.
This feature couples well with "git show-diff", which shows all
lines with unstaged changes (in future it should probably show staged
changes as well).
Whereas on diffs, "git apply" stages the entire hunk if the selection
contains no newline, this does not happen when operating on content.
I didn't yet try implementing that. I guess the hunks are not as
explicit here.
Closes#5225
We pipe the output of the patch program to stderr (to have it show
up in *debug*) and print to stdout the remaining diff (the part of
the diff that was not passed to patch).
The next patch wants to use this script in a different way, so move
these decisions up.
A following patch wants to use this script without wrapping it in an
"evaluate-commands -save-regs e %{ ... }", so simply print the raw
error message and set the register to the caller.
This interface is a bit weird because the error is printed quoted
but for now that just makes things a bit more convenient.
If a file has unsaved modifications, then the show-diff flags below
such modifications will be wrong. Fix this by using the current
buffer contents, just like the git blame integration does.
This might make it a bit slower, I haven't tested that.
We call git blame
a. asynchronously in ":git blame"
b. synchronously in ":git blame-jump"
In both cases we
1. create a fifo
2. buffer the file contents in shell memory
3. print to the fifo
4. run git blame and remove the fifo
For the synchronous case the buffering and custom fifo is not
necessary; use ${kak_response_fifo} instead.
For the asynchronous case we do need a buffer that outlives the
enclosing %sh{} block. Buffering in shell memory can be somewhat slow
for large files. Let's use a temporary file instead.
The SQL filetype detection currently matches against a 'sql' suffix on
the filename, which incorrectly matches a filename like 'run-psql'.
Instead, explicitly match against a '.sql' suffix.
I configured :make to use a special makecmd for files called test.cpp.
hook global BufCreate .*/test.cpp %{
set-option buffer makecmd "g++ %val{buffile} && ./a.out"
}
Commit c93cb5c4d (Add a `fifo` helper command and refactor `make`
and `grep` to use it, 2024-06-07) made :make evaluate makecmd in the
toolsclient context instead of the calling context, so my buffer-local
override no longer applies. I'm not sure if this is something we want
to guarantee but it doesn't seem unreasonable, and we can fix it a
no cost I think.
Additionally, it changed
eval "${kak_opt_makecmd}" "$@";
to
$kak_opt_makecmd "$@"
meaning that the "&&" in my makecmd will no longer be evaluated.
Instead it will be passed as argument to g++, effectively
g++ %val{buffile} '&&' ./a.out
which I don't think is a reasonable expectation (unless we change
makecmd to be str-list options). Essentially, the above only applies
word splitting to makecmd; it seems simpler and less surprising to
treat them as raw shell commands.
Expand makecmd in the calling client again, and insert it verbatim
into the shell script.
grep hasn't needed it so far but keep it consistent.
We do not typically go into lengthy explanation of the code in the
support scripts. This would have a performance impact (as comments
are not trimmed in advance) and feels out of place.
The current python filetype module treats a single empty comment line
(typically created by hitting enter twice while in a block comment) as
the end of a block comment, deleting the empty comment and ending
comment prefix copying. This runs contrary to PEP8, which explicitly
allows for paragraphs in block comments, with an empty comment as the
paragraph separator.
This change implements support for using a single empty comment as a
paragraph separator, with two consecutive empty comments being treated
as the end of the block comment; both empty comment lines are deleted
and comment prefix copying is ended.
When using `eval` a new scope named 'local' gets pushed for the
whole evaluation, this makes it possible to temporarily set
an option/hook/alias...
Local scopes nest so nested evals do work as expected.
Remove the now trivial with-option command
In a noninteractive shell, asynchronous commands ignore SIGINT and
SIGQUIT. We typically use such shells to feed fifo buffers which we
do want to cancel them on Control-C. Make it so.
Same for SIGQUIT; that one is not typically used but I expect that
along the Kakoune server it kills any child processes that (haven't
been daemonized).
Note that for unknown reasons, Bash already doesn't ignore SIGINT in
async processes that use "eval".
Note that Dash has a bug that prevents this from working;
proposed fix is at
https://lore.kernel.org/dash/20240329153905.154792-2-aclopte@gmail.com/
(While at it balance out some parens, to help the m command)
Commit e43c7d6ab (Use complete-command for the :doc command,
2022-10-19) forgot to carry over the "-menu" flag, which means that
:doc completions are no longer auto-selected, even though they are
the only valid inputs.
Fix that.
Closes#4790
