It seems that when -atomic was implemented for `:write`, the usage
strings were not updated to reflect that a new flag was available.
The `write-all` command didn't benefit from the implementation of
the new flag despite also writing files - this commit fixes that.
The first attempt at a bug fix for @ symbols in selection buffer names
worked, but it was very inefficient. In particular, it allocated three
different vectors, and we really only needed the correct elements.
Manipulating iterators to give us the right slices of the existing
vector is far more efficient.
By reversing the original content and taking the last two, we're able to
get the number of selections and main selection without too much hassle.
The buffer name is everything from the start of the content to the
selection count. This gets us through with only one vector allocation.
Credit to @mawww for the optimization idea and for fixing my types.
The selection descriptions use the format
`<buffer>@<timestamp>@<main_index>`. This fails when file paths have `@`
symbols in them: the parser splits on `@` symbols and finds more values
than it expects.
We here modify the behavior to require *at least* two @ symbols, using
the last two for `<timestamp>` and `<main_index>` and leaving the
remaining text for the <buffer>. This should work for any number of `@`
symbols, since `<timestamp>` and `<main_index>` are numbers and should
never contain `@` symbols.
The description of startup_info_version in the manual says "only messages
relating to a Kakoune version greater than this value will be displayed,"
but showed messages relating to the version equal to that value.
This change aligns the code with the manual and makes a workaround that set
startup_info_version next to the original version (ex. 20200117) unnecessary.
Signed-off-by: Masanori Ogino <masanori.ogino@gmail.com>
When a region calls the regex highlighter, it is incorrect to share
the regex cache as it means we can get matches that span multiple
regions.
Fixes#3041
Do not access Buffer::m_changes to find the inserted range, return
it directly from Buffer::insert and Buffer::replace. This fixes a
wrong behaviour where replacing at eof would lose the selected end
of line (as the implementation does not actually replace that end
of line)