Typing ^H (by default equivalent to Backspace) at the start of the file
is not useful. When it happens, assume that the user is new and tried
to ask for Help. So... explain what the caret and the "M-" in the help
lines mean.
Also, to keep menu items nicely grouped in the Main, Search, Replace,
and Goto menus, reorder a few items when no help is available.
This addresses https://savannah.gnu.org/bugs/?59110.
When nano reports "Unbound key" or "Unknown sequence", this message
should stay onscreen only for the relevant keystroke, not for any
succeeding keystroke.
This addresses https://savannah.gnu.org/bugs/?59119.
Bug existed since before version 2.0.6.
Slang fails to translate the longer sequences, and then truncates
these sequences to just four bytes, effectively destroying them.
Therefore, when built with --with-slang, always activate --raw-sequences.
This avoids https://savannah.gnu.org/bugs/?49771.
Bug was visible since version 2.5.0, since bindings
for Ctrl+Left/Ctrl+Right were added.
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\..."
