When space is too tight to show all three elements, show the report on
the number of lines in preference to the current location and character
code. The latter two will be shown again upon the next keystroke, so
there is little harm in hiding them for a moment.
Having a block cursor present when highlighting a match...
does not look nice. So... hide the cursor until the next
keystroke, unless --showcursor or 'set showcursor' is used.
Not only does the match get highlighted (for better visibility), but
this also allows deleting the match with a single keystroke (^K, or
<Del> or <Bsp> when --zap is used) and then type something else.
This https://savannah.gnu.org/bugs/?59655.
Requested-by: Noam Sondak <noamso@gmail.com>
Remarks are about unsurprising things but it's good to give feedback
on them; "mistakes" are unexpected things, and get colored like an
error; and information is something that the user requested and thus
needs to stay on the status bar until the next keystroke.
For some reason, calling halfdelay() undoes the ISIG mask.
So, mask keyboard interrupts again immediately after the call.
Reported-by: Peter Passchier <peter@passchier.net>
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.
The bottom window (the prompt bar and the shortcuts) does not shift
its position when line numbers are active, so mouse clicks in this
window should be not be compensated for the line-numbers margin.
This fixes https://savannah.gnu.org/bugs/?59749.
Indirectly-reported-by: ObeliX <ObeliX-@gmx.de>
Bug existed since version 2.7.0, since line numbers were introduced.
Clicking on the cursor toggles the mark, meaning that the flags in
the title bar should be updated when --stateflags is active.
This fixes https://savannah.gnu.org/bugs/?59747.
Indirectly-reported-by: ObeliX <ObeliX-@gmx.de>
Signed-off-by: OIX <ObeliX-@gmx.de>
The state flags are relevant only when editing.
This fixes https://savannah.gnu.org/bugs/?59744.
Indirectly-reported-by: ObeliX <ObeliX-@gmx.de>
Bug existed since version 5.3, since --stateflags was introduced.
This allows using <Esc> <Esc> <letter> in a macro as an alternative
for <Ctrl+letter>, but it does require that one does not type <Esc>
by accident when recording a macro as it might modify the subsequent
keystroke when the macro is replayed.
This fixes https://savannah.gnu.org/bugs/?58904.
Bug existed since version 3.0, commit ecc9211a.
The workaround was for https://savannah.gnu.org/bugs/?51335
(a cursor-misplacement bug), but both an recent Xfce Terminal
and a recent Konsole appear unaffected by the issue. So, drop
the workaround for modern systems.
Checking for the actual version of libvte is too complicated, so
assume that libvte is 0.58 or newer (where the problem is fixed)
when ncurses is 6.2 or newer.
It was only ever needed when the user lied about the size
of the terminal, which should be considered a user error.
It was a workaround for https://savannah.gnu.org/bugs/?48852.
This avoids unnecessarily truncating the last help item on the
very bottom row when there is still plenty of room.
This fixes https://savannah.gnu.org/bugs/?59550.
Bug has been visible since at least version 2.5.1.
Subtract one from the count only if all possible items in the menu
have been counted (item == NULL), meaning that the last item in the
Write-Out menu (the 'discard_buffer' function) has been counted too.
This fixes https://savannah.gnu.org/bugs/?59549.
Bug existed since version 4.5, commit b3ace4d8.
When getopt() does not recognize an option, it returns '?', which means
that '-?' cannot be used as a valid option because any invalid option
would be treated the same way as '-?'.
Spewing out the full help text drowns the "invalid option" message at
the beginning.
This fixes https://savannah.gnu.org/bugs/?59530.
Bug existed since version 5.3, commit 5bd92d4c.
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.
This makes the cursor move smoothly left and right -- instead of
"stuttering" when passing over a zero-width character.
Pressing <Delete> on a normal (spacing) character also deletes
any zero-width characters after it. But pressing <Backspace>
while the cursor is placed after a zero-width character, just
deletes that zero-width character. The latter behavior allows
deleting and retyping just the combining diacritic of a character
instead of the whole character.
This addresses https://savannah.gnu.org/bugs/?50773.
Requested-by: Mike Frysinger <vapier@gentoo.org>
(Yes, the test is for 6.0, but the bug was actually fixed in 5.9,
as far as I remember -- I just wasn't sure and didn't want to bother
building different versions of ncurses myself.)
Those versions are more than five years old. If there are still
machines with those versions, people should upgrade ncurses too
if they want the newest version of nano.
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.
This takes eight extra calls of copy_of(), but saves ten calls of
free(). But more importantly: it avoids an unneeded copying and
then freeing again of the argument after 'titlecolor' and friends.
And in the bargain elide a variable, and make it clearer
what the return value is at two early exit points.
[This change makes use of the fact that TRUE (successful write) == 1
and FALSE (failed write) == 0. But this is already used twenty lines
earlier, for the other call of write_file().]
Web links and email addresses do not belong in the version information.
This has bothered me for a long time. The URL is in the man page, and
bug reports should go to Savannah.
The terminal window in the graphical Debian installer (the default)
produces the same escape sequences as xterm for F1 to F4. Though
TERM is set to xterm, the xterm terminfo data is not available, so
ncurses is unable to translate the sequences for us. :| Therefore,
recognize the relevant raw escape sequences.
Also, eat all bytes of the non-recognized modified function and arrow
keys, so that they do not enter junk into the buffer.
The tiny version is probably only ever used in the Debian installer,
on the bterm terminal, which produces escape sequences like those of
a Linux console. So, exclude all other raw sequences.
(After support for Slang has been removed, we can maybe even exclude
ALL raw sequences from the tiny version, and the corresponding option
(-K/--rawsequences) too.)
At least since version 229 of xterm (from August 2007), the escape
sequences for F1 to F4 have been "Esc O P" to "Esc O S". There is
no bracket in those sequences, and there probably never was -- most
likely the extra "[" in nano's code was a slip of the fingers.
Trying to determine which syntax to apply with the help of libmagic
can be a somewhat time-consuming and yet often still fruitless affair.
Therefore using libmagic should not be the default; it should require
an option to tell nano to try using libmagic when it can't determine
the applicable syntax from the file's name or first line.
This is better than having a --nomagic option (and using libmagic by
default), because when the user has 'set nomagic' in their nanorc or
--nomagic in their alias, then switching the use of libmagic back on
is troublesome. But with --magic (and not using libmagic by default),
when nano fails to recognize a file, it is a simple ^X, add -! to the
command line, and restart.
The short form of the option is -! because we have run out of letters.
This addresses https://savannah.gnu.org/bugs/?59028.
With --stateflags (short form: -%) or 'set stateflags', nano reserves
the righthand end of the title bar not for showing "Modified" but for
showing the state of auto-indentation (I), the mark (M), the breaking
of long lines (L), macro recording (R), and softwrapping (S).
When the buffer is modified, this is indicated with a star (*) after
the file name (shown in the center of the title bar).
This fulfills https://savannah.gnu.org/bugs/?57953.
Requested-by: Sébastien Desreux <seb@h-k.fr>
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.
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.
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.
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.
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?)
The most likely reason for stat() returning -1 is that the file
does not exist. And an absent positionlog file is not an error.
(In some cases it is, like immediately after writing the file,
but even then we don't want to complain, because it may have
been some other process that deleted the file straightaway.)
This fixes https://savannah.gnu.org/bugs/?58993.
Bug existed since version 5.0, commit fcb9e58b.
This ability was lost in commit 92298349 from two hours ago, which
bypasses the keystroke buffer and its integrated screen resizing.
This new implementation is better than it was before, because it
responds almost instantly to a resize instead of with a delay of
up to a second.
(Still, this does not allow a full escape sequence to be used as
the Cancel command, but I think that is an acceptable limitation,
because 1) nobody ought to be using --rawsequences, and 2) very
few people will bind Cancel to something like F3 or Ins.)
This improves the fix for https://savannah.gnu.org/bugs/?58825.
When checking (during a Search command) whether the user has pressed
the Cancel keystroke, look at ncurses' input stream directly instead
of at nano's own keystroke buffer, because the latter may contain the
copied keystrokes of a macro and we don't want to discard those.
(This does not yet allow a Meta keystroke to be used for Cancel, but
the next commit will fix that.)
This fixes https://savannah.gnu.org/bugs/?58825.
Bug existed since version 2.9.0, since the macro was introduced.
There is no reason to deselect the region, as nothing has changed.
(This also retains the shift-selected region when a non-shortcut key is
typed in view mode, which makes sense, as again nothing was changed.)
This fixes https://savannah.gnu.org/bugs/?58980.
Bug existed since version 4.9, commit 0ed62e84.
When keypad() is set to FALSE, like for verbatim input, ncurses is
not waiting its fifty milliseconds after an ESC to see if another
code will follow it, so nano itself will have to pause a little.
Otherwise 'solitary' could get set to TRUE when in fact the ESC
is followed very closely by another code.
This fixes https://savannah.gnu.org/bugs/?58955.
Bug existed since version 2.6.2, commit f2150d3f.
Also when each character is just one byte, parse_verbatim_kbinput()
can produce two bytes; plus the terminating NUL that is three bytes.
This fixes https://savannah.gnu.org/bugs/?58959.
Bug existed since version 4.9, commit 03d296eb.
Benno Schulenberg