This prevents read() from returning unexpectedly and causing a crash.
This fixes https://savannah.gnu.org/bugs/?60537.
Reported-by: Filips Romāns <frfilips@gmail.com>
Bug existed since version 2.4.2, since the handling of SIGWINCH changed.
That is: call edit_refresh() right away, to prevent the edit_refresh()
in the main loop from overwriting the status-bar message.
This fixes https://savannah.gnu.org/bugs/?60516.
Bug existed since version 2.7.2, commit f920e0d3.
That is: call edit_refresh() right away, to prevent the edit_refresh()
in the main loop from overwriting the status-bar message.
This fixes https://savannah.gnu.org/bugs/?60518.
Bug existed since version 5.6, commit 76742cc1.
When there is just one row, the user wants to see text on this row,
not a bar with some meta info.
This fixes https://savannah.gnu.org/bugs/?60508.
Bug existed since version 5.5, since the minibar was introduced
with commit d31cc373.
This reduces startup time by seven percent (when using the standard set
of syntaxes) when opening just one file that doesn't match any syntax,
and more than ten percent when opening multiple files. It takes some
extra memory, but... not wasting CPU cycles is more important.
This addresses https://savannah.gnu.org/bugs/?56433.
When undoing several actions, it is possible for the line at the top
of the screen to be removed, leaving 'edittop' pointing to a structure
that has been freed. Soon after, 'edittop' is referenced to determine
whether the cursor is offscreen... Prevent this invalid reference by
stepping 'edittop' one line back in that special case. This changes
the normal centering behavior of Undo when the cursor goes offscreen,
but... so be it.
When a single node is deleted, it is always possible to step one line
back, because a buffer contains always at least one line (even though
maybe empty), so if the current line could be deleted, there must be
one before it (when at the top of the screen).
This fixes https://savannah.gnu.org/bugs/?60436.
Bug existed since version 2.3.3, commit 60815461,
since undoing does not always center the cursor.
Since two commits ago, the position of the indicator shows the position
of the viewport relative to the full buffer in terms of actual lines,
not of visual chunks (to avoid excessive computation). But the size of
the indicator stayed constant, as if it always covered as many lines as
the edit window has rows. But the latter will not be the case when
softwrapping occurs. Therefore, when softwrapping, compute how many
actual lines are visible in the viewport, and adjust the size of the
indicator accordingly.
Whenever softwrap was toggled on or line numbers were toggled on/off or
the window was resized, the extra rows per line needed to be recomputed
for ALL the lines. For large files with many long lines this was too
costly.
(This change causes the indicator to have an incorrect size when there
are many softwrapped chunks onscreen, but that will be addressed later.)
This fixes https://savannah.gnu.org/bugs/?60429.
Problem existed since version 5.0, since the indicator was introduced.
This makes the handling of plain ASCII a tiny bit slower, but it
affects only the users of --constantshow without --minibar, so...
All other uses of mbstrlen() and collect_char() are not in speed-
critical code paths.
Since the previous commit, mbwidth() is used only to determine whether
a character is either double width or zero width. There is no need to
return the actual width of the character; a simple yes or no is enough.
Transforming mbwidth() into is_doublewidth() also allows streamlining
it and is_zerowidth() a bit, so that they become slightly faster.
The number of bytes in the character were determined twice: first in
mbwidth() and then in char_length(). Do it just once, in mbtowide().
Also, avoid calling is_cntrl_char(), because it does unneeded checks
when we already know that the high bit is set.
This duplicates some code, but advance_over() is called a lot, so it
is important that it is as fast as possible.
This shouldn't slow down plain ASCII, as the extra checks (use_utf8
and *string < 0xA0) are done only for non-ASCII (apart from DEL).
The 'start_index' was in index in the given text, while 'index' is an
index in the displayable string. Having both of them using 'index' in
their name was somewhat confusing.
For a normal file (without overlong lines) the strlen() wasn't much
of a problem. But when there are very long lines, it wasted time
counting stuff that wouldn't be displayed on the current row anyway,
and reserved *far* too much memory for the displayable string.
Problem existed since commit cf0eed6c from five years ago that traded
a continuous comparison (of the used space with the reserved space)
against a one-time big reservation up front involving a strlen().
In retrospect that was not a good trade-off when softwrapping.
The extra check (charwidth == 0) is incurred only by characters that
have their high bit set, so the average file (with only ASCII) is not
affected by this -- it just loses an unneeded call of strlen().
In UTF-8 valid multibyte characters are at most four bytes long,
and now that we no longer make use of mblen() and mbtowc() from
the underlying system, we won't get five- or six-byte sequences
mistakenly reported as valid (by glibc). So it is always enough
to reserve space for just four bytes per character.
Calling wctomb() with NULL as the first parameter returns zero in a
UTF-8 locale, meaning that there is no state, so there is no point
in resetting it either.
The two calls of draw_row() are each immediately preceded by a call to
display_string(), which has already determined from which x position
and until which x position in the relevant line the current row will
be drawn -- doing this again in draw_row() is a waste of time. Even
though it is ugly, pass the two data points from one function to the
other via global variables.
For normal files (without overlong lines), this saves on average some
fifty calls of advance_over() per row. When softwrapping a file with
overlong lines, the savings for each softwrapped chunk are much higher.
(Well, it now checks that ^G is still the first shortcut that is bound
to 'do_help', but that is good enough: if the user did any rebinding,
they probably do not need any reminder about how to invoke 'Help'.)
This fixes https://savannah.gnu.org/bugs/?60315.
Reported-by: Robert Goulding <goulding.2@nd.edu>
This saves a function call, and the passing and checking of the
MAXCHARLEN parameter, and the checking whether wc is maybe NULL
(which for nano is never the case), and who knows what other
overheads mbtowc() has, and our workaround for glibc.
Code was written after looking at gnulib/lib/mbrtowc-impl-utf8.h.
Most implementations of mblen() do a call to mbtowc(), which is
a waste of time when all we want to know is the number of bytes
(and when we already know that we're using UTF-8 and that the
first byte is at least 0xC2).
(This also avoids burdening correct implementations with the
workaround that was needed only for glibc.)
Code was written after looking at gnulib/lib/mbrtowc-impl-utf8.h.
The mblen() and mbtowc() functions will happily return 4 or 5 or 6
for byte sequences that start with 0xF4 0x90 or higher. But those
sequences encode for U+110000 or higher, which are not valid Unicode
code points. The libc of FreeBSD and OpenBSD and Alpine correctly
return -1 for such sequences. Make nano behave correctly also when
linked against glibc, so that invalid sequences are always presented
as a series of invalid bytes and never as a single invalid code.
This fixes https://savannah.gnu.org/bugs/?60262.
Bug existed since before version 2.0.0.
The call of this function in make_mbchar() does not add anything,
because wctomb() already returns -1 for codes U+D800 to U+DFFF,
and parse_verbatim_kbinput() already rejects anything that starts
with U+11.... or higher, so make_mbchar() is never called for codes
beyond U+10FFFF.
And the call in display_string() just needs to check for wc <= 0x10FFFF
because mbtowc() already returns -1 for codes U+D800 to U+DFFF.
That is, accept U+FDD0 to U+FDEF, and accept U+xxFFFE and U+xxFFFF
for xx from 00 to 10 hex, being the 66 reserved "non-characters".
It may not be wise of the user to input these "things" (by typing
their code after M-V), but the codes are valid Unicode code points
and should not be rejected.
See https://www.unicode.org/faq/private_use.html#nonchar8 et al.
This fixes https://savannah.gnu.org/bugs/?60263.
Bug existed since before version 2.0.0.
When inserting a file into the current buffer, the 'fmt' element will
already be set. When we avoid overwriting the current value of 'fmt'
(when it's other than UNSPECIFIED), we don't need to save and restore
the value when inserting a file.
When saving the buffer under a different name, it should by default
have the same format as the original file.
This fixes https://savannah.gnu.org/bugs/?60278.
Bug existed since version 2.6.0, commit 0293eac1.
This improves the fix for https://savannah.gnu.org/bugs/?60269,
by not dropping error messages that happen before a buffer is opened.
This basically reverts commit b63c90bf from a year ago, except that
it now always deletes the created buffer when the user does not want
to override the lock file, also when it is the only buffer.
Set the 'format' of a file only when it has been fully read in,
so that this field can be used to indicate that any later error
message cannot be meant for this buffer.
This fixes https://savannah.gnu.org/bugs/?60269.
Bug existed since commit 6bf52dcc from yesterday.
Make sure there is an 'openfile' record before trying to save an
error message in this record.
This fixes https://savannah.gnu.org/bugs/?60268.
Bug existed since commit ede64d7e from yesterday.
When opening multiple files and some of them had an error, only the
first message was shown and the others were lost -- indicated only
by three dots. Improve upon this by storing the first error message
for each buffer and showing this message when the buffer is first
switched to.
Requested-by: Mike Frysinger <vapier@gentoo.org>
That is: reserve for the current line and current character the number
of positions needed for the total number of lines and characters, and
reserve two positions for both the current column and the total number
of columns. This will keep all nine numbers in the output in the same
place -- as long as there are no lines with more than 99 columns. In
this latter case there will still be some jitter, but all-in-all the
output is much stabler than it was.
Suggested-by: Mike Frysinger <vapier@gentoo.org>
The number of lines in a group is the difference in line numbers
between the last line and the first line *plus one*.
This fixes https://savannah.gnu.org/bugs/?60104.
Bug existed since version 2.9.0, since indenting and unindenting
became undoable, and commit f722c532 formed a part of that.
Allocating it again would leak the existing space.
This fixes https://savannah.gnu.org/bugs/?60172.
Reported-by: Mike Frysinger <vapier@gentoo.org>
Bug existed since version 5.6, commit 1fdd23d3.
When the version number is a trio, the version string will occupy
ten bytes and the terminating NUL byte would not be written (which
was not a problem as byte 12 of the lock data is zero anyway).
But it's better to not have the compiler complain, so allow writing
the terminating NUL byte outside of the ten bytes reserved for the
version string.
This fixes https://savannah.gnu.org/bugs/?60149.
Reported-by: Peter Passchier <peter@passchier.net>
Reported-by: Liu Hao <lh_mouse@126.com>
Bug existed since version 5.6, since a special color for highlighting
search matches was introduced in commit 87fe73dd.
Full justification (like justification of a selection) is probably
a rather rare action -- and possibly even an unintended action --
so it's good to give feedback about what happened also when using
the minibar.
When a line is marked as JUSTONTHIS, there should be no second start
match on that line, because otherwise the line would have been marked
as STARTSHERE (unless there is also a second end match -- but it's
fine to do unnecessary refreshes in this unlikely case, as long as
the necessary refreshes are made).
This fixes https://savannah.gnu.org/bugs/?60074.
Bug existed since version 2.5.0, but has been masked (for the C syntax)
by unnecessary refreshes since version 4.1, commit c9605e73.
When a line is marked as NOTHING, then the existence or the appearance
of an end match is irrelevant: there is no unpaired start match, so no
recoloring would occur, so there is no need to refresh.
When a line is marked as WOULDBE, then the existence or the appearance
of a start match is irrelevant (for the lines after the first WOULDBE
line): there already is an unpaired start match, so another one will
not change anything, so no refresh is needed. Only the appearance of
an end match would recolor things and thus require a refresh. However,
start and end regexes could match the same thing, so an end might get
misinterpreted as a start. So the rule has to check for the absence
of both a start and an end match, like for WHOLELINE.
This addresses https://savannah.gnu.org/bugs/?60072.
A step forward needs to be forced not when both start match and
end match have zero length, but when the "full match" (all text
from the start of the start match to the end of the end match)
covers zero bytes. In other words: the start and end match are
both of zero length AND are at the same spot.
Now that a search match gets highlighted, the unsuspecting user might
think that the text is selected, because it is colorized the same way
as selected text. Avoid this by colorizing a highlighted search match
with its own specific color, black on yellow by default.
In addition, suppress the feedback for M-C also when --minibar
isn't used, as the feedback obscures the effect of the toggle:
showing information about the cursor position on the status bar.
This fixes https://savannah.gnu.org/bugs/?60019.
Bug existed since commit 7545eb5b from one week ago.
Highlighting an occurrence is so much clearer than just putting the
cursor on it. People seem to like it. So let's make this how nano
behaves by default.
Take two conditions that are relevant only for a rather unlikely case
(a start match without a corresponding end match) out of an inner loop.
Give the case its own, dedicated loop.
When leaving the multidata unset (as was done until now) and the
end match is offscreen, then this could lead to miscolorings later
when jumping over this end match instead of scrolling past it.
This fixes https://savannah.gnu.org/bugs/?60012.
Bug existed since before version 2.1.10.
When a large piece of text or code is pasted or inserted, it could
contain matches for start= and end= regexes, and backtracking from
the current screen could mistake an end for a start and could thus
miscolor things. Avoid this by recalculating the multiline cache
for pastes and insertions that cover more than a screenful.
This fixes https://savannah.gnu.org/bugs/?59982.
Bug existed since version 2.6.0, but existed also before 2.4.3.
This allows having an even leaner interface, and gives the M-C toggle
an appropriate function (instead of leaving it a "dead" keystroke).
Suggested-by: Sébastien Desreux <seb@h-k.fr>
If a paste (or insertion) is more than a screenful, it will not set
'focusing' to FALSE. In that case, and when line numbers are already
active, then 'focusing' should be kept set to TRUE, despite it getting
set to FALSE by ensure_firstcolumn_is_aligned(). That latter action
is meant to cushion size changes of the edit window, but in this case
the large paste (or insertion) should trump the size change.
This fixes https://savannah.gnu.org/bugs/?59981.
Bug existed since version 2.8.3, commit 2b385478.
Commit 43d94692 fixed a miscoloring bug [1] by doing proper backtracking
for multiline regexes. But this change also solves an older miscoloring
issue [2] without needing to recalculate all the multiline data. So...
just drop the old fix. (This isn't perfect: it's probably possible to
cook up a replacement scheme where things get miscolored, but... until
then, this is good enough.)
[1] https://savannah.gnu.org/bugs/?59948
[2] https://savannah.gnu.org/bugs/?58481
Also, there is no need to set 'refresh_needed' in do_replace_loop(),
because each replacement prompt will call edit_refresh() anyway, and
the functions that call do_replace_loop() will set it afterward.
The precalc_multicolorinfo() routine will assign a value to every
element for every line without looking at any current value, so
wiping the data first is a waste of time.
After having been allocated, the multidata will get computed
immediately, in precalc_multicolorinfo() and draw_row(), so
first setting each element to -1 is a small waste of time.
The initialization of -1 cannot possibly match with NOTHING or
WHOLELINE or the other available values.
(Also, put in a warning, as I don't think an onscreen line without
a multidata cache can occur at all.)
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.
Benno Schulenberg