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
Fixup ctags-complete command to search for partial matches for the
current selection in all tags files listed in ctagsfiles option. Format
the results to fit the Kakoune completions type.
Add ctags-enable-autocomplete and ctags-disable-autocomplete commands to
add and remove an InsertIdle hook to select the previous word and call
ctags-complete.
Use the ctags_min_chars option to limit the noise of returning many
completions for very short selections.
Change regular expression in git blame, removing braces. New expression is supported on various awk engines used in some distributions as default ones. As trade-off, the new expression accepts more input character sequences.
adding init to git.kak
removing git init EOF line
git ls-files on on git.kak
no candidates for git-init, removed function
removed candidates for git-init
