| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Commit 888b23ffa (Fix grep arguments being evaluated in toolsclient
context, 2024-11-27) had good intentions but it broke commit ef18d3cbf
(rc make/grep: evaluate makecmd in calling context, use eval semantics
again, 2024-07-31), causing makecmd to be evaluated in toolsclient
again. Fix that by passing makecmd via a register, like grep.kak does.
|
|
Commit ef18d3cbf (rc make/grep: evaluate makecmd in calling context,
use eval semantics again, 2024-07-31) fixed a regression in make.kak
but didn't bother to fix a similar regression in grep.kak:
evaluation of both %opt{grepcmd} and %val{selection} were moved
to the toolsclient context.
Move them back to the calling context.
While at it, get rid of the double evaluation of makecmd, for
consistency with grepcmd, and in case makecmd contains unbalanced
braces.
|
|
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.
|
|
|
|
Avoid the brittle `exit; %arg{@}` trick
|
|
Running arbitrary commands in a fifo is very useful in its own right
and factoring out the common pattern is a nice added cleanup.
|
|
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)
|
|
|
|
`grep-next-match` works only on the `*grep*` buffer so it can't be used
on buffers that were preserved by renaming or on other grep-flavored
buffers created by 3rd party plugins kakoune-find and kakoune-lsp,
like `*find*` and `*references*`.
Let's generalize `grep-next-match` with a `jump-next` command that
takes a buffer argument.
This renames some options but I think they're not commonly used.
kakoune-lsp is an exception that uses grep_current_line but it's no big
deal, things will fail loud and early if options are missing.
Since grep.kak and friends now depend on jump.kak, move the jumpclient
declaration there as well.
|
|
Since the default make error pattern spans until the end of the
line, make-jump select the whole line, moving the cursor to the end.
This is especially bad when the error message is very long and hence
the cursor movement scrolls the viewport so the file:line:col is no
longer visible.
Stop moving the cursor in `*make*` and `*grep*` buffers.
We already have highlighting to indicate the current line.
|
|
Given
make[1]: Entering directory '/home/johannes/git/kakoune/src'
main.cc:66:9: error: expected ‘}’ before ‘asdf’
If I select the whole second line, including the newline, make-jump
fails with an enigmatic "no such file or directory main.cc". This is
because `gl` does not move the cursor away from the newline. Fix it.
This appears to have regressed in 80d661e6a (rc/: More consistent
uses of regex syntax, 2017-09-29).
|
|
If a user modifies a grep buffer, we can end up in weird situations
where we try match a filename over multiple lines.
Let's rule out newlines in filenames here. There is an argument
this is a case of GIGO but we already do this for the corresponding
highlighters.
We also do it in make.kak, see ca225ad4d (Cleanup make.kak and optimize
the make-next/make-prev regexes, 2016-12-09). There is one case left
where a filename would theoretically span multiple lines. Fix and
optimize this too.
|
|
grep-jump and make-jump[*] support Windows-style paths like C:\path.
However grep-next-match and make-next-error don't, which suggests
that no one uses this feature. IIRC Cygwin mounts Windows drives in
proper Unix paths like /mnt/drive_c.
Let's remove it for simplicity and consistency.
This reverts commit 6c47b204e (Support windows style path in grep
output, 2014-11-11).
[*]: Though make-jump recently regressed in 8e5ca3f21 (rc/make.kak
introduce a new option to be back compatible, 2023-10-27) by failing
to capture the "C:" prefix.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is equivalent to a change to grep.kak in 649e252f7 (bring *grep*
buffer to front in context of toolsclient, 2020-08-14).
If a toolsclient is set, make-next-error (and make-previous-error) will
jump to %opt{make_current_error_line}. This is wrong if the toolsclient
does not show the *make* buffer. In that case make_current_error_line
is undefined and we end up showing the goto menu. This has occasionally
been annoying me for a long time but I never bothered investigating.
Fix this by switching to the *make* buffer. The potential downside
is if make-next-error is run from the toolsclient, where we no longer
jump to the error but that's fine because we can use <ret>.
We can maybe improve this later by extending the logic, see
https://github.com/mawww/kakoune/pull/3656#pullrequestreview-472052285
|
|
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.
|
|
This cosmetics commit makes use of the auto-deindentation syntax,
available to docstrings.
|
|
|
|
This reverts commit 6c05e6e0f81243ec503a3de78cf36b5dc798cb1c.
Apparently the Linux sh needs subshells here.
|
|
|
|
Without these changes, kak would hang on the corresponding commands,
displaying a 'waiting for shell command to finish' message.
|
|
Closes #2783
|
