Instead of redisplaying the minibar only upon the next keystroke
(when some feedback message is shown on the status bar), time the
waiting for the keystroke out after four fifths of a second, then
redisplay the minibar and continue the wait.
This avoids poor wordings such as "Words: 1 Lines: 1 Chars: 1".
Also, display the numbers in a more logical, ascending order: lines
first, words second, characters third. This is what 'wc' uses, too.
Some linters report a column position (assuming a TAB to be 8 spaces)
instead of a byte index, so make sure that the cursor is not placed
out of bounds when interpreting such a column number as an index.
This fixes https://savannah.gnu.org/bugs/?59419.
Reported-by: Ava McWhorter <qwerty0s.e.m@gmail.com>
Bug existed since version 2.8.1, commit 2439e1e4.
Those casts are redundant, and sometimes ugly. And as the types of
variables are extremely unlikely to change any more at this point,
the protection they offer against miscompilations is moot.
Signed-off-by: Hussam al-Homsi <sawuare@gmail.com>
The two functions findnextstr() and do_replace_loop() do not change
or even touch 'last_search', so there is no need to save and then
restore its value when doing corrections of misspelled words.
Storing the orientation of the marked region beforehand is not needed,
as this orientation is readily available also after the justification.
(By the way, cursor and mark need to be swapped after justifying
a backward-marked region because the rule is that the cursor gets
placed *after* the justified paragraph. Maybe that should change?)
During verbatim input at most four integers are produced (the longest
possible unicode sequence), so use the value 999 to indicate a special
condition (a screen resize) that should not enter anything into the
buffer AND should not produce any error message or beep.
This fixes https://savannah.gnu.org/bugs/?58923.
Bug existed since version 5.0, commit 5899181a.
After commit 59bbc0b8 from five days ago (that made a divergent pipe
failure to be treated in the same way as the other two), this became
possible without having two different pipe-failure messages.
More generally, after invoking the formatter, the entire buffer should
be cut (to be replaced with the reformatted text) and not just the part
before the mark, because then everything after it would be duplicated.
This fixes https://savannah.gnu.org/bugs/?58879.
Bug existed since version 4.9, commit 19517fc5.
If forking fails, we must first return to curses mode before we can show
an error message on the status bar. (This additionally requires storing
the error number, because doupdate() apparently sets it to zero.)
This fixes https://savannah.gnu.org/bugs/?58864.
Bug existed since version 4.8, commit 61197563.
The codes from (for example) U+D800 to U+DFFF are invalid. If any
such invalid code is entered at the Unicode Input prompt, nano should
not act as if the code was accepted and inserted into the buffer, and
should certainly not mark the buffer as Modified.
This fixes https://savannah.gnu.org/bugs/?58714.
Bug existed since version 4.9, commit b3faf353.
The constant cursor display must be suppressed whenever a message
was printed to the status bar. That is: whenever 'lastmessage' is
something other than 'VACUUM'.
Before version 2.9.8, nano would consider any line that started with
leading whitespace as the beginning of a new paragraph, and would thus
be unable to justify an indented piece of text (unless autoindent was
switched on). I thought that this was too limiting and changed the
way nano detects and parses paragraphs. It works fine in texts where
paragraphs occupy multiple lines, but breaks down for paragraphs of
a single line: nano merges those with adjoining lines.
Now, when -O or --bookstyle or 'set bookstyle' is used, nano will again
consider a line that begins with whitespace as the start of a paragraph
-- when 'autoindent' is OFF.
This addresses https://savannah.gnu.org/bugs/?57402.
Indirectly-reported-by: Sébastien Desreux <seb@h-k.fr>
Also-reported-by: Bill Kendrick <nbs@sonic.net>
The parameter was referenced in just one place. So, simply check for
the three relevant menus (and unrestricted mode) and be done with it.
This also has the pleasant effect that the menu name is now the first
parameter of do_prompt(), thus clearly indicating what prompt it is,
instead of having an opaque TRUE or FALSE value at the beginning.
Instead of burdening seven other calls of do_prompt() with a useless
parameter, just check for MGOTODIR in the appropriate place. It also
saves having to pass the parameter down through three more functions.
Instead of storing for each line the ordinal number of the first chunk
in that line, simply store the number of extra chunks in the line.
It now takes some more computation to actually draw the scrollbar, but
it saves a lot of computation when just inserting or deleting characters
(when using --softwrap and causing a change in chunk count).
This fixes https://savannah.gnu.org/bugs/?58510.
Bug existed since commit 6bccedb3 from two days ago.
Instead of creating a special Tools menu, add the five functions that
affect the whole buffer to the "Execute Command" menu. There is room
for these five functions there, and they kind of fit in because three
of them (Speller, Linter, and Formatter) actually invoke an external
command, and Full Justify could have been implemented externally, and
the destructive Cut Till End ought to have required a double keystroke
since the beginning.
In the past, when Speller and Linter and Formatter were all bound
to ^T (later ones taking priority), it was easier to exclude also
the formatter code when --disable-speller was used. But since the
formatter was reintroduced (in commit 34170611) and bound to its
own keystroke (M-F), this is no longer the case.
Just let all anchors disappear when doing an external spell check or
formatting or piping the buffer through an external command, because
leaving just a single anchor on the top line is useless.
This fixes https://savannah.gnu.org/bugs/?58273.
Bug existed since commit 732cf887 from one month ago. That code
causes an anchor to persist at the point where lines are removed.
When a single paragraph is justified, any anchor on any of its lines
gets moved to its first line. Let a full justification do the same
for each of the paragraphs.
This fixes https://savannah.gnu.org/bugs/?58272 in a better way.
This fixes https://savannah.gnu.org/bugs/?58272.
Bug existed since commit 732cf887 from one month ago. That code
causes an anchor to persist at the point where lines are removed.
Benno Schulenberg