In this way, any message that is on the status bar after the search
will be a response to this search and not some leftover.
This fixes https://savannah.gnu.org/bugs/?59109.
(This effectively reverts commit ba47abb4 from two days ago, but it
groups things better. It makes an unnecessary call to bottombars()
for M-Q and M-W, but this hardly matters: searching in a help text
does not need to be efficient.)
This fixes https://savannah.gnu.org/bugs/?59108.
Bug existed since commit ba47abb4 from two days ago.
The tiny version is about being small, not about convenience features
that hardly anyone uses anyway.
Also exclude the description of the "+line[,column]" feature -- it is
unneeded verbosity.
This addresses https://savannah.gnu.org/bugs/?59101.
The cursor would disappear after any message on the status bar --
for example, also when M-W is typed and nothing is found -- so the
mitigation trick needs to be performed in statusline() itself.
This addresses https://savannah.gnu.org/bugs/?59091.
In the tiny version (built with Slang and running on Debian's bterm)
the Ctrl+Left/Ctrl+Right keystrokes do not work. When the terminal
is wide enough, instead of showing ^B + ^F for Backward and Forward
(which are unneeded because the unmodified arrow keys work fine),
show M-B + M-N for Prev Word and Next Word.
(Listing ^Space and M-Space instead would cause "Prev Word" and
"Next Word" to be truncated. They are weird keystrokes anyway.)
Also, list M-Q + M-W for "Previous" and "Next" next to "Where Is"
and "Replace", so that it is slightly clearer what they refer to.
For some reason, when running a tiny nano built with Slang on the bterm
of a Debian installer image, the cursor disappears when certain things
are written to the status bar. Make the cursor reappear by rewriting
the two help lines with dummy items (and then rewriting it again with
the normal menu in the central loop). Of course, this does not help
when the user uses -x or --nohelp to suppress the help lines, but at
least in the default setup the cursor doesn't get hidden now and then.
This mitigates https://savannah.gnu.org/bugs/?59091.
Bug existed since before version 2.2.4.
For some reason the Romanian PO file contains a literal ^Q in one
of its translated messages -- currently at line 1984. This stray
^Q causes 'file' to classify po/ro.po as data.
Make such mistaken control codes easier to spot when using nano.
Slang apparently needs a call to SLsmg_refresh() to restore the screen
content and put the cursor in the right place. But call this function
only when the suspension was actually caused by an external SIGSTOP,
because otherwise the original screen (from which nano was invoked)
gets plastered with nano's interface and content -- upon exit, this
is annoying and confusing.
Do not stuff a dummy keystroke into the input stream, as it seems to
get placed *after* the first byte of the next keystroke from the user.
That would cause an "Unknown sequence" for some keystrokes.
This fixes https://savannah.gnu.org/bugs/?59077.
Bug existed since version 2.8.5, commit 84ff9ebb.
The previous commit fixed https://savannah.gnu.org/bugs/?59071.
That bug existed since version 5.1, commit cc6d1d59.
But before that, a capital Ñ could not be typed (when built with Slang)
and would enter an invalid byte upon the next keystroke.
That bug existed since version 2.8.6, commit 43a5c876.
Instead of stuffing 0x91 into the input stream, use 0xFF when built
with Slang -- the same code that Slang itself produces when resuming
from an externally induced suspension. This byte is ignored.
In a UTF-8 locale, it should be safe to ignore the byte 0xFF coming
from the keyboard, as no valid UTF-8 sequence can contain 0xFF.
In an ISO8859 locale, this change prevents ÿ from being typed on the
keyboard -- it can still be entered with <Esc> <Esc> 255, though.
My apologies to the people of Pierre Louÿs and L'Haÿ-les-Roses.
Trying to ignore an external SIGSTOP/SIGTSTP with SIG_IGN does not work,
so always install the SIGCONT handler so that it is possible to continue
from a SIGSTOP.
This fixes https://savannah.gnu.org/bugs/?59073.
Bug existed since before version 2.0.6.
Also, don't format the wrapping quotes of strings,
and normalize the formatting of default values.
This addresses https://savannah.gnu.org/bugs/?59064.
Reported-by: Helge Kreutzmann <debian@helgefjell.de>
Constants that consist of a single character are valid too.
And a lone hash character on a line by itself also.
Signed-off-by: Hussam al-Homsi <sawuare@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
This probing has been changed four times in the past:
git log --grep get_wch
In March 2005, commit 2161fa62 changed the probe from get_wch() to
wget_wch(), reasoning that "get_wch() might be a macro instead of
a function". (Four months earlier, commit 3ba9c351 changed it
from addwstr() to wget_wch(), probably for the same reason.) But
three months later, in commit 25799f68, the probe gets changed to
get_wch() again, because "it's a more generic function"...
It seems clear that the non-macro argument is the stronger one.
See the NOTES section in 'man get_wch' for its possible macroness.
This addresses https://savannah.gnu.org/bugs/?58997.
Reported-by: Randall S. Becker <rsbecker@nexbridge.com>
This is the opposite of what 'ls' does in a UTF-8 locale, but nano
has never followed the collating rules of Unicode (uppercase after
lowercase, ignoring punctuation, and so on) -- it would be strange
to change that now.
Until now, nano left such equivalent names unsorted, in a seemingly
random order.
This fixes https://savannah.gnu.org/bugs/?59059.
Bug existed since before version 2.0.6.
And mention that a background color does not work on libvte before 0.55.
To find out the version of libvte on your system:
ls -R1 /usr/lib | grep libvte | grep 00 | grep -o "0\..."
Do the same what the normal "research" code does: if nothing was
searched for yet during this session, and there is a history of
search items, then search for the last item in that history.
Make case-insensitive searching in a UTF-8 locale eight times faster
when the actual characters involved are plain ASCII.
This makes us faster than 'less', and as fast as Vim and Emacs.
The disadvantage of this change is that searching for a string that
begins with a multibyte character is nearly ten times slower than
searching for one that begins with an ASCII character. This may be
unsettling when searching a huge file first for a simple ASCII string
and later for a UTF-8 one. Doing this second search, the user might
get impatient: "Why is it taking so long?"
(This patch fell through the cracks four years ago, when I worked on
the searching code. It sat in a branch on top of other changes that
I never applied because I made different improvements. The speedup
at the time, on that machine, was only around sixty percent, though.
But measuring it now again on the same machine, it clocks in at an
82 percent reduction with -O0 and an 87 percent reduction with -O2.)
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.
Benno Schulenberg