Backtracking from the first row is needed in case a start match was
added recently somewhere offscreen and the user jumped to the current
location (instead of scrolling) so that the CWOULDBE markings did not
reach the current lines.
Also, search for an end match only for the first screen row. For the
other rows, rely on the CENDAFTER, CWHOLELINE, and CWOULDBE values to
indicate whether there *is* an end match (the first two values) or not.
This saves considerable time when there is no end match in the large
remainder of a buffer: it will search in vain for the end match just
once, instead of for every row of the screen.
This fixes https://savannah.gnu.org/bugs/?59948,
and addresses https://savannah.gnu.org/bugs/?59945.
Bug existed since version 2.7.5, commit b3bcc8ee.
Like the other two fragments that advance over a zero-length match,
also this fragment should avoid the possibility of stepping beyond
the end of the line.
When a zero-length match is beyond the width of the screen, there
is no point in continuing evaluating the rule, so the check for
"offscreen to the right" needs to come first. The check for a
zero-width match needs to come second because otherwise we would
get stuck on such a match when it is offscreen to the left.
When the match of a coloring regex is beyond the width of the screen,
there is no point in continuing to evaluate the regex for the rest of
the line, because any other matches will be offscreen too.
This will save some time when there are several overlong lines.
A syntax has on average a dozen coloring rules, but on average maybe
three or four pieces of text (rough estimate) in a line get painted.
So, on average, it is cheaper to call wattron() and wattroff() only
when actually coloring a piece of text, instead of calling wattron()
before starting to evaluate each rule and wattroff() after finishing
its evaluation.
When reaching end-of-line after having found a zero-width end match,
nano should not continue at 'seek-an-end' but instead at 'step_two':
going on to seek a start match in the current line.
(There is no bug report, because I cannot figure out how to trigger
this issue and cause nano to misbehave. The problem was found while
reviewing the comments.)
Bug existed since commit 9a4a5454 from four years ago,
but the behavior was poorer before that commit.
When the filename, header-line, and magic regexes are first compiled
while reading in the rc files (to check their validity), REG_NOSUB is
used, but for some reason this wasn't done when each of these regexes
gets recompiled in order to be used. Fix this oversight. It shaves
some twenty percent off of each of these regexes' compiling time.
The combining characters (that are zero-width) start at U+0300.
After that it's pretty much chaos, width-wise.
The mbwidth() function is not called for control characters (whose
representation takes up two columns), as they are handled separately.
The calls of mbwidth() that *can* happen with a control character as
argument are only to determine whether the character is zero-width,
and then it doesn't matter whether the exact width is 1 or 2.
An invalid UTF-8 starter byte should not be represented in the same way
as a valid Unicode character.
This fixes https://savannah.gnu.org/bugs/?59832.
Bug existed since two weeks ago, since the mini-bar code was merged.
The first byte of a multi-byte UTF-8 sequence must be in the range
0xC2...0xFF. Any other byte cannot be a starter byte and can thus
immediately be treated as a single byte.
When the tail of the answer still fits exactly on the screen, the ">"
continuation character should not be shown -- also when the start of
the answer is "scrolled off" to the left.
This fixes https://savannah.gnu.org/bugs/?59816.
Bug existed in this form since version 4.0, commit 56181896.
When making small movements in the lower right corner, ncurses can
get confused about where the cursor actually is -- a double-width
character seems to throw its calculations off.
This addresses https://savannah.gnu.org/bugs/?59808.
Bug existed since version 5.4, commit 39705c60.
Show leading dots for the truncated part, or (if there is no room
at all) show just an underscore instead of the file name.
This fixes https://savannah.gnu.org/bugs/?59802.
Bug existed since version 2.9.3, commit 97cbbb0c.
Now all toggle functions have the same name as their corresponding
long command-line option. Also, all names now indicate the effect
of the toggle when it is invoked from a default setting.
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.
This will not work for the deviant escape sequences for F1 to F5
on the Linux console nor for Alt+arrow on urxvt and such, but...
I can't be bothered to handle those too.
This fixes https://savannah.gnu.org/bugs/?58929.
Bug existed since commit be203832 from earlier today.
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.
When Unicode Input has started (by typing 0 or 1 at the Verbatim Input
"prompt"), and something is typed that is not a hexadecimal digit, then
don't try to enter this character into the buffer but simply report it
as invalid and ignore it. Because most likely the user mistyped and
actually meant to enter a valid hex digit.
This fixes https://savannah.gnu.org/bugs/?58927.
The bug was old -- it existed since at least version 2.0.6.
Just like <Ctrl+Down> goes to the end of the buffer when after the
cursor there are only blank lines.
This fixes https://savannah.gnu.org/bugs/?58921.
Bug existed since version 2.6.2, since <Ctrl+Up/Down> were introduced.
The correct sequences begin with "Esc [" instead. I cannot find in the
histories of VTE and Gnome Terminal when these sequences were corrected.
Also exclude a bug check from the tiny version.
When we get an ESC from the keyboard, it might be the start of an
escape sequence, but the keyboard routines will need a little time
(tens of microseconds, probably) to get these codes to ncurses.
So, when doing verbatim input, pause a moment after an ESC.
This completes the fix for https://savannah.gnu.org/bugs/?58909.
Always interpret ESC followed by BS or DEL as <Alt+Backspace>.
This fixes https://savannah.gnu.org/bugs/?58910.
Bug existed since commit 40b03162 from one week ago,
since M-Bsp was hard-bound to deleting a word backwards.
(This could lead to unwanted behavior when the user wants to enter
a literal escape character (0x1B) while the input is somehow getting
stalled, because then a command keystroke after the M-V <Esc> would
get inserted verbatim too, instead of getting acted upon. But that
is a small price to pay for getting the correct behavior for both
M-V M-Bsp and M-V M-Enter.)
This fixes https://savannah.gnu.org/bugs/?58909.
Bug existed since version 2.6.3, commit 08c51cfd,
but also occurred erratically beforehand.
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.
The user had better avoid using the keystroke in a macro, but
when typing directly at a responsive machine there is no problem,
M-[ is a perfectly valid and recognizable keystroke.
This fulfills https://savannah.gnu.org/bugs/?58820.
The make_new_node() function initializes 'extrarows' to a bad value
on purpose, to catch cases like this one where it doesn't get updated
properly.
This fixes https://savannah.gnu.org/bugs/?58890.
Reported-by: Jerry Kindall <kindall@gmail.com>
Bug existed since version 5.0, since the indicator was introduced.
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.
When compiling with GCC 10.1.0 and -O2 -Wall, the strncpy() call
in measured_copy() produced two stringop-truncation warnings.
This addresses https://savannah.gnu.org/bugs/?58861.
Signed-off-by: Michalis Kokologiannakis <michalis@mpi-sws.org>
Between an endwin() and a doupdate() there should be no calls of
statusline() or statusbar() -- these two functions may be called
only when in curses mode.
This fixes https://savannah.gnu.org/bugs/?58868.
Bug existed since version 4.3, commit 57390cff.
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.
It jars a bit that it is <Ctrl+Delete> that deletes a word rightward
and <Alt+Backspace> that deletes a word leftward. But it's good to
also have a two-key keystroke bound by default to 'chopwordleft',
and not just the three-key <Ctrl+Shift+Delete>.
This fulfills https://savannah.gnu.org/bugs/?58709.
Requested-by: Axel Scheepers <axel.scheepers76+gnu@gmail.com>
While ignoring permission errors from fchmod() and fchown() is okay
(since normal users are not always privileged to make such changes),
ignoring also more serious errors (like EIO) is not ideal.
Signed-off-by: Michalis Kokologiannakis <michalis@mpi-sws.org>
Benno Schulenberg