Highlighters now run in 3 phases:
Wrap, Move, and Colorize. That way we guarantee the wrap
highlighter runs first, then eventual line numbers/flags,
and finally the colorizers.
We also run a `compute_display_setup` method thats responsible
for computing the lines that will be displayed, eventually
scrolling the view to ensure the cursor is visible.
The command map can get mutated by command execution, so the iterators
can get invalidated (now that we use our curstom HashMap implementation,
all iterators are potentially invalidated by insert/removal)
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
The previous implementation could yield different positions when
iterating forward and backward, leading to confusion in boost regex.
This makes an existing problem a bit more visible: iterating with
to_next and with read_codepoint wont behave the same way, as
read_codepoint will put the iterator onto the byte following the
utf8 codepoint, whereas to_next will put it on the next utf8
character start byte, which might be different if the buffer content
is not valid utf8.
Fixes#1195
This commit allows "forced" writes to a write-protected file, by
attempting to temporarily grant the current user write permissions on
it. After the buffer has been written, the previous permissions are
restored if the file existed, or set to 0644 otherwise.
That means we wont have a very nice interaction between show_whitespaces
and column highlighters, but thats the simplest fix for now, if we want
a better behaviour we need to introduce a way to know that a replaced
range is splittable (meaning it means to have the same amount of columns
as the range it replaces)
Fixes#1275
We were letting stdin untouched, which meant child processes had
access to our terminal input. That meant `!fmt` was trying to read
from our terminal input and catching keystrokes.
Fixes#1281
