First try to break at a whitespace, if that fails (likely because
that last WORD is too long for the wrapping width), then try to
wrap at a 'word' boundary (on a non alphanumeric character).
Fixes#3048
Using <fg>,<bg>+<attr>@<base> will apply the given fg color,
bg color and attributes on top of base dynamically. Simply giving
<base> is a shorthand for default,default@<base>.
Inspired by the discussion in #2862
Also add test for tab preservation during c-family autoindentation, and correct alignment of '}' with opening of block in cases of wrap between '(' and ')' in c-family languages
The current implementation is wrong as it crosses basic blocks
boundaries. Doing basic block decomposition of regex is probably
a tad too complex for this single optimization.
Fixes#2711
This commit also introduces a regression in that I decided that the best way to
avoid overly long and confusing names was to rename the current shell-*
switches to script-*, and have the shell command completion be
shell-completion.
renamed script-{completion,candidates} to shell-script-*
Updated docs with new switch names
Added -shell-completion switch to x11-repl and kitty-repl
Final is more granular, it consists of FinalFg (f), FinalBg (g)
and FinalAttr (a) which control if a face's fg, bg, or attributes
fully overwrite the previous face (instead of merging) and if
following faces apply on top of this face or not.
Fixes#2388 if the Whitespace face has the FinalFg flag.
We cannot guarantee after an itersel that selections are going to
still be in ascending order, but we were calling a SelectionList
constructor that was assuming this was the case.
Currently, inserting a newline after a ruby method will incorrectly
cause the following line to repeat the method header. This commit
adds a test case to illustrate the bug.
Reference highlighters allow for potential mutual recursion between
highlighters. This is usually fine, but if the recursion happens on
the same buffer range, it means we will recurse infinitely.
Fixes#1920
Change the logic of open line commands so that if a selection lies
on the end of line character of the line from which we open a new
line, that selection does not move.
If we have two clients, A and B, with B's cursor on the eol character
of line L, and A hits `o` while on line L, B's cursor should stay
on the same (logical) line. Previous behaviour would make B's cursor
jump on the newly inserted line.
Various places in Kakoune code used to modify selections so that
cursors would not lie on an end of line. Remove those to increase
Kakoune's consistency and simplicity.
Now that end of lines are highlighted separately, they should not
be handled specially in most commands.
When on an end of line, certain behaviours can be surprising, for
example delete will join the following line (which makes sense, and
is consistent, but hard to predict if we do not know the cursor is
on and end of line).
As Kakoune is moving more and more towards treating end of lines
as any other character, making it clear when the cursor lies on
them seems like a good way to reduce surprise.
Avoiding end of line is a behaviour we avoid (pun intended) more and more
in Kakoune source code, now that end of lines are regularly selected, it
makes no sense to just to next line when last modification lies on an EOL
(and it probably did not make much sense back when that code was written).
Move recording of keys to the input handler itself instead of the
Insert mode so that eventual nested modes (potentially introduced
by <a-;> will get their keys recorded as well).
Fixes#1680
When using an env var that needed the selections in the pipe command line,
say $kak_selection, the selection update code would run, modifying the
selections to adapt to eventual changes. But the rest of the pipe logic
was assuming the selections would not change, leading to bugs.
That means we can now have highlighters active at global, buffer, and
window scope. The add-highlighter and remove-highlighter syntax changed
to take the parent path (scope/group/...) as a mandatory argument,
superseeding the previous -group switch.
Support arbitrary orders for column highlighters (it was previously
failing when column highlighters were not applied in column order).
Fix show_matching tab handling at the same time (horizontal scrolling,
tab characters and show_matching were behaving badly).
Window highlighting now runs user highlighters, then built-ins for each
phases, instead of running all phases for user highlighters, then all
phases for built-ins.
We now consider unprintable character to be 1-column width as we know
we will display them as "�".
Fixes#1615Fixes#1023
That way, insert mode knows when it can restore selections/avoid eol
instead of (wrongly) doing it in the destructor that ends up running
unpredictibly (as the mode is kept alive during its on_key call, even
though it can happen that it is not the active mode anymore at the end
of that call).
Fixes#1580
We were preserving the history in that case, so on fifo buffers
(that set the NoUndo flag until the fifo is closed), we still had
the history from the "previous life" of the buffer, leading crashes
when trying to apply it.
Fixes#1518
Previously, if you opened a new line after an underlined heading (what
the CommonMark spec calls a "Setext heading") or inserted a newline into
a line that started with `**strong emphasis**` the Markdown autoindent
hook would assume the leading symbols were list bullets and paste them
at the beginning of the new line.
However, the CommonMark specification says that list bullets must be
followed by at least one horizontal whitespace character, so Setext
heading underlines and strong emphasis are not valid list bullets and
should not be matched by the autoindent pattern.
This commit changes the regex that selects the pastable prefix of the
previous line so that it must match either:
- One or more `>` characters with optional whitespace between them
(a blockquote prefix), optionally followed by a list bullet; or
- An optional blockquote prefix and a list bullet
Since we don't strictly need either the blockquote prefix nor the list
bullet, we could concievably just make both optional... but for lines
without either, the regex would find a zero-length match, and for the
purposes of copy/paste Kakoune treats that as a one-character match.
Therefore, the regex is written to fail if neither pattern is found.
Replacing with empty strings is essentially a deletion, which means
it can end up push some selections out of the buffer (imagine 3 a
2 empty line buffer, and deleting the second one). We are fixing
the selections in SelectionList::erase, but we were not doing that
in SelectionList::insert.
Fixes#1504
