When provided, this gives the maximal time to wait before exiting
handle_next_events. If not given handle_next_events will block, this
provides a more flexible approach than the previous "block" boolean.
Use this to wait for a millisecond between each try to open a fifo
for writing.
Fixes the 100% cpu usage discussed in github on commit
e74a3ac6a3
Commit 9cf8a3ccd (Check for buffer overflow when constructing the socket path., 2022-04-07)
made
$ kak -s $(printf %0100d)
fail but forgot to do the same for
$ kak -e "rename-session $(printf %0100d)"
which silently succeeds, only to fail at the next
$ echo nop | kak -p $(printf %0100d)
Fatal error: socket path too long: '/run/user/1000/kakoune/0000...'
Let's fail earlier.
While at it, don't validate "m_session" redundantly.
I'm not sure if we should validate the socket names in "kak -clear";
I guess it doesn't matter.
Commit 8c49c8ee4 (Highlight all atoms for the line regardless of
has_buffer_range, 2024-11-04) intentionally changes the behavior
to also highlight outside the buffer, painting over number-lines.
Let's use a final face as suggested to restore the test's previous
behavior, fixing the failure.
"ui_out -until-grep" invocations used to redirect the output from
grep, usually to /dev/null. Looks like the intention of 60fcc3443
(Change ui_out -until-grep to check for equality the next argument,
2024-11-02) was that grep no longer needs to print output, since we
can assert instead which is mildly better.
Unfortunately there are two places where -until-grep might not be
powerful enough, which is why we capture the output and check it
in the test script. For one of them we can use -until-grep with a
small change. Not yet sure about the other one. Let's try to use
eval instead, so we can silence the output.
I realize -until-eval is not great (the nested quoting is ugly)
but I guess it's better than the status quo.
Alternatively, we could print output only if the [expected] argument
is not given, and add >/dev/null to the other invocations.
Tests print a confusing error
./run: line 214: shift: shift count out of range
This is because ui_out -until-grep now shifts twice which conflicts
with the weird shift at the end of ui_out.
It also has a loop, making it possible to do something like "ui_out
foo bar baz" to expect three different messages. We don't use this
feature anywhere, and it seems just super surprising, given that
ui_out now consumes between 1 and 3 arguments each time. Let's get
rid of the loop, and always run shift right next to where we actually
use the argument. This should make things less brittle.
I noticed that reverse searches ending in "." stopped working in
version 2024.05.08:
kak -n -e "exec %{%cfoobar<ret><esc>gj<a-/>foo.<ret>}'
Bisects ca7471c25 (Compute StartDesc with an offset to effective start,
2024-03-18) which updated the find_next_start() logic for the forward
case but not for backward case. Add a symmetrical change and test
case, that seems to fix it. Not 100% sure if this is correct but
feels so.
Instead of outputing the matching output, either ignore the output
(if not extra argument is given) or match it.
Usage is: ui_out -until-grep <pattern> [<expected>]
The general is_horizontal_blank supports various unicode blanks,
but passing an utf8 continuation byte to it can lead to surprising
results as we can match with 0xA0 (when char is unsigned).
Fixes#5250
Since shell-script-completions now runs the script asynchronously
and unconditionally, there is no use for the CompletionFlags::Fast
anymore which means we can remove that type altogether.
Share most logic with shell-script-candidates. Now that we do not
block we can run the completion script implicitely instead of waiting
for an explicit completion request with <tab>.
Fixes#5245
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
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.
In b05295, the project switched from a root Makefile that simply pointed
to the "real" Makefile in src/, and made the root Makefile contain all
the build logic.
However, the documentation wasn't updated to reflect this change. I'm
updating the README.asciidoc file to point to the new location of the
file, to avoid further confusion
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.
Some people (i.e. in the Doom Emacs discord) mentioned being confused at that
X11 thing. The last commit that touched that line was in 2014, so I think
providing more up-to-date examples should remove any confusion.
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
9275d96 introduces a use of stdin as a function parameter name, but POSIX
allows stdin to be a macro, which will conflict with this. This breaks
the build on musl systems.
Rename in the same way as the previous fix for this in c7d887d.
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.
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.
Calling it as part of the insert method was error prone and often
led to slightly surprising behaviour, such as the <c-r><esc> hiding
the menu on <esc>.
