Instead of redetermining the entire span of the converted string,
simply move one character left, and then bite it off to make place
for the trailing $.
If the last two columns of a row would be taken up by a double-width
character (and the line is longer than that), don't print it, because
it wouldn't leave any room for the $ character.
This fixes https://savannah.gnu.org/bugs/?50491.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
The platform's default char type might be signed, which could cause
problems in 8-bit locales.
This addresses https://savannah.gnu.org/bugs/?50289.
Reported-by: Hans-Bernhard Broeker <HBBroeker@T-Online.de>
On a system with up-to-date GNU tools, this does not change
the size of nano's binary.
We start off with importing only a few modules, although we
don't yet delete the fallback logic for them.
The gettext-0.18.3 release was made in Jul 2013, while the 0.11.5
release was made in Aug 2002. Time to update :).
Also drop all the bundled gettext m4 files. When you run autogen.sh,
these will get copied in automatically for you.
The autoconf-2.69 release was made in Apr 2012.
The automake-1.14 release was made in Jun 2013.
Update the requirements so we know we can rely on macros/features
available in those versions.
The mark only needs to be off when calling replace_marked_buffer(),
because this indirectly calls ingraft_buffer(), which fiddles with
the end points if the mark is on.
Running strlenpt() on a string that takes up more than 80 columns
(the width of an average terminal) takes /more/ time than simply
converting an extra character (the one that will be overwritten
by the "$" at the edge of the terminal). So... just convert one
more character than necessary when the line is overlong. In the
most common case, however, the line will fit fully onscreen, and
we save a whole call of strlenpt().
Since we only need span columns of the string, stop scanning the string
as soon as we have that many columns, instead of scanning the string all
the way to the end. This speeds up the conversion of very long lines.
Replace partitioning with calls to extract_buffer() and ingraft_buffer().
In addition to pasting the unjustified text back into the buffer at
current[current_x], ingraft_buffer() also deals with renumbering and
updating totsize, so do_justify() doesn't need to do those anymore
when unjustifying.
With read_file() revamped, it now uses partition_filestruct() indirectly
via ingraft_buffer(), so we can't use partition_filestruct() to replace
marked text in the alternate spell checker anymore without segfaulting.
Add the new function replace_marked_buffer() to accomplish this instead.
Based on replace_buffer(), it uses extract_buffer() to throw away the
marked un-spell-checked text, and then uses read_file() to insert the
spell-checked text at the position where the mark was.
Accordingly, remove unneeded partitioning and related stuff from
do_alt_speller(). Besides pasting the file into the buffer at
current[current_x], ingraft_buffer() also deals with renumbering,
updating totsize, and handling a magicline, so do_alt_speller()
doesn't need to do those anymore.
Move buffer handling and '\r' stripping from read_line() to read_file(),
so that the file gets its format determined and gets stored in its own
buffer entirely in one function. Then use ingraft_buffer() to insert
this new buffer into the current one.
In addition to pasting the file at current[current_x], ingraft_buffer()
also deals with renumbering, the updating of totsize, and the handling
of a magicline, so read_file() doesn't need to do those anymore.
Note that all this makes read_file() depend on the position of
current[current_x] to know where to insert the file. Accordingly,
set current_x to zero in initialize_buffer_text() instead of in
make_new_buffer(), so that replace_buffer() keeps working properly.
Add its explanation as a separate paragraph.
Also: improve the argument of the --syntax option, as this is a <name>
and not merely a bundle of characters like the other <str> arguments.
In this last loop of break_line(), the pointer 'line' is one step ahead
of the index 'lastblank'. So the loop should first add the length of
the preceding character to 'lastblank' before determining the length
of the current character (and using this to advance 'line').
(There is something wrong in the last loop: line is one character ahead
of lastblank, but the current character length is added to both of them.
It thus assumes that all blank characters are the same number of bytes.
For spaces and tabs this works fine. But for more exotic blanks...)
Benno Schulenberg