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)
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.
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`.
Previously, spelling suggestions were presented with the :menu command,
requiring the user to cycle through wild and fanciful alternatives to get to the
one they wanted. Now, we present suggestions with the :prompt command, which
allows the user to type to filter down the list, and also to customise the
replacement after they've chose it (perhaps to fix capitalisation or add
apostrophe-S).
We also use the mispelled word as the initial content of the prompt. That
filters out the wildest alternatives by default, and allows the user to edit the
original word instead of forcing them to choose from among the suggestions. To
get the full list of suggestions, it's easy enough to just backspace until the
word you want appears in the list.
Ranges specified with a +<length> were inconsistent, with +0 meaning
an empty range, while +1 meant a two character long range (first character
+ the following one). Change that to mean a single character.
Fixes#3479
The first line returned by `aspell` isn't always an identification
string, it can also be an error.
This commit prevents the first line from being ignored in any case,
and allows errors to be reported consistently.
Related to #3330
This commit adds a `spell_lang` option that will be used by the
`spell` command when no language is passed to it directly.
Setting a buffer/window local option allows using `:spell` seamlessly
across several buffers, written in different languages.
Due to ambiguity in the POSIX standard, GNU and BSD versions of the `wc`
utility use slightly different whitespace conventions when formatting
their output [1]. When limiting the output to just counting the number
of bytes (as is done by Kakoune when calculating the length of words
for spell check highlighting), the BSD version of `wc -c` has some
additional leading whitespace:
gnu$ printf %s "test" | wc -c
4
bsd$ printf %s "test" | wc -c
4
This leading whitespace needs to be removed before defining the "region"
to highlight, or `set-option` will not be able to parse the given
`spell_regions` and will complain that there are "not enough elements
in tuple." In other words, the region `1.21+8|Error` on Linux ends up
looking like `1.21+ 8|Error` on macOS, which is invalid.
Removing the whitespace could be accomplished in a number of ways, but
using arithmetic expansion [2] is POSIX compliant and does not require
shelling out to another process.
[1]: https://unix.stackexchange.com/questions/205906/extra-space-with-counted-line-number
[2]: https://mywiki.wooledge.org/ArithmeticExpression