Calling strstrwrapper() with the Backwards, Casesens, and Regex flags
unset is equivalent to calling mbstrcasestr(). So... do that instead
and quit saving and restoring the flags for each call of findfile().
This saving-and-restoring has been redundant since commit b0957254
from eight years ago.
The dots gave the impression that the next keystroke (hex digit) would
land somewhere on the dots. But this is not so -- the current digits
are instead shifted to the left and the new digit is added at the end.
Also adjust and improve several comments.
Also elide three calls of tolower(), using ORing with 0x20 instead,
as we're dealing with plain ASCII here.
Rename a variable too, away from a double abbreviation.
Instead of requiring always six digits, allow the user to indicate
with <Enter> or <Space> that the digits typed so far are the complete
Unicode code point (when prefixed with the missing number of zeroes).
This fulfills https://savannah.gnu.org/bugs/?63021.
Inspired-by: the <Ctrl+Shift+U> shortcut that some desktops have
This does not quite do what I would have liked (scroll only when needed)
when on a softwrapped line and jumping to a different chunk, but... it's
still better than needlessly centering the line.
(The user can still center the line, if that is what they want, by using
a period or a slash instead of a comma.)
This addresses https://savannah.gnu.org/bugs/?63008.
Nobody will configure nano with --enable-tiny --enable-extra, but *if*
someone does, the title bar should be absent during the crawl.
Also, swap two messages, so that their order in the POT file will be
more sensible -- a closing brace comes after the function name.
"Cannot map name %s to <thing>..." was unnecessarily verbose and vague.
I have kept these strings unchanged all these years because I didn't
want to invalidate the existing translations. But now it's time to
harmonize things and simply say "Unknown <thing>: %s" for an invalid
function name, menu name, option name, and syntax name.
("No such <thing>: %s" is nice and snappy, but its translations often
are clumsy and longer and unclear.)
(It is a harmless leak, but LeakSanitizer is loud when it complains.)
After having determined that there is a menu name, first check that
it is valid, before processing the string or the function name.
This fixes https://savannah.gnu.org/bugs/?62991.
Problem existed since version 2.9.4, since string binds were introduced.
This makes more sense than letting the formatter and the linter depend
on ENABLE_COLOR (which maybe should have been named ENABLE_SYNTAX).
This fulfills https://savannah.gnu.org/bugs/?50080.
Six years ago, commit a878f5f1 introduced a call of regenerate_screen()
directly in the input routine, which made the call of refresh_func() in
the prompt routine redundant -- except when in the file browser.
Since version 6.0, with option --zero, the edit window can cover
the whole terminal. Make use of this also for the credits crawl.
Also, shorten and quicken the crawl a bit, and make it start always
on the bottom row, instead of (for mysterious reasons) one row higher
when the terminal has an odd number of rows.
Furthermore, don't put back the key the user typed to stop the crawl.
Instead of starting always from the top of the buffer, start at the
current line, as it is quite likely to be near the target line.
(Since the previous commit we're assuming that openfile->current is
always valid, so we might as well make use of this assumption.)
Also, rename a parameter to make its meaning more explicit.
After undoing an <Enter> or redoing a line join, it is likely that the
"eaten" and freed line was the current line. In fact, goto_line_posx()
should not refer to it any more, but... accommodate for this and just
set openfile->current to a valid value before calling goto_line_posx().
This fixes https://savannah.gnu.org/bugs/?62952.
Bug existed since version 6.3, commit eea3e1f0.
Checking for the literal ^N, ^Q, and ^Y before checking for do_toggle
and full_refresh made it impossible to rebind any of those keystrokes
to these two functions. (Not that anyone would want this, but...)
Problem existed since version 4.3, commits 341601e1 and 82aea04c.
This allows specifying bindable functions in a string bind by name
instead of by the literal control code or escape sequence to which
they are bound, which makes for a much more readable string bind,
and also allows specifying functions that are not bound to any key.
The opening brace, {, is made into a special symbol inside a string
bind, and each literal occurrence there needs to be escaped as {{}.
This fulfills https://savannah.gnu.org/bugs/?61692.
Requested-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Original-idea-by: Brand Huntsman <alpha@qzx.com>
https://lists.gnu.org/archive/html/nano-devel/2018-02/msg00006.html
This makes that the three options that change the default layout
of the interface (--stateflags, --minibar, --zero) come last.
Also, sort the option letters into a consistent order in the code.
(That 'also_the_last' now gets reset to FALSE whenever the cursor moves
to a different line is fine -- it is redundant when the mark is off, but
it does no harm.)
It was silly to check again specifically for <Del> and <Bsp> after
any possible keystroke had been handled. It was an anomaly.
This makes the tail of do_deletion() similar to the tail of inject().
(That sometimes the current line is redrawn twice is acceptable -- how
often does one type <Backspace> while having Shift-selected something?
Normally one wouldn't, because it would cancel the selection, so it's
fine to accept some inefficiency for this case.)
The checking for all functions that are marked as not-okay-for-view-mode
was excessive and unneeded. It had been inherited from commit d47d8cd4
from thirteen years ago, and was never verified for correctness.
This addresses the main part of https://savannah.gnu.org/bugs/?62903.
The linter has been marked as NOVIEW since it was introduced in 2.3.3.
But that was a mistake, as the tool does not change the buffer contents.
This addresses a minor part of https://savannah.gnu.org/bugs/?62903.
This is especially meant to avoid dereferences of 'shortcut' after its
linked function has been executed, because in an upcoming commit this
execution may have freed the shortcut's structure.
(For symmetry, make the same change also in do_statusbar_input(), even
though it is not needed there.)
This addresses one part of https://savannah.gnu.org/bugs/?62899.
The only menus that are accessible in view mode are WhereIs, Insert,
WhereIsFile, GoToDirectory, and Help. In the WhereIs menu, the only
keystroke that is not allowed in view mode (^R) is caught explicitly.
In the other four menus, all available shortcuts are permissible in
view mode, so... there is no need to check them at execution time.
(The ^R keystroke in the WhereIs menu is still shown in view mode
so as not to upset the pairing of the subsequent shortcuts.)
Since commit 63f2be7a from four years ago, view mode always sets
multibuffer mode, allowing ^R (Insert) to be invoked. But the
user is then not allowed to switch multibuffer mode off, so...
don't show the toggle.
This allows one to complete also words that are present in other files
(when these are open in other buffers).
This fulfills https://savannah.gnu.org/bugs/?61691.
Requested-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Original-patch-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
When confirm_margin() first sets the margin needed for the requested
line numbers, also then it needs to keep 'focusing' TRUE. Only when
actually toggling --linenumbers ON (from a zero margin to something)
should focusing be suppressed, in order to obtain smooth scrolling
when the cursor is pushed off-screen.
This fixes https://savannah.gnu.org/bugs/?62885.
Bug existed since version 4.4, since the search-at-startup feature
was introduced.
In many keyboard layouts M-< and M-> are awkward to type (in a Spanish
layout, for example: Alt+Shift+AltGr+Z and Alt+Shift+AltGr+X when there
is no LSGT key), whereas M-, and M-. are simple two-key keystrokes in
most Latin-script layouts. So, show M-,/M-. before showing M-</M->.
Also, make a condition more precise, to not show M-Left and M-Right in
the tiny version, when those shortcuts are not understood.
Since version 6.0, Suspend is no longer bound by default, which meant
that it dropped out of the help lines, leaving the items after it in an
unpaired arrangement. Move the Suspend item and its intended partner
to near the end of the list, to reestablish pairing for several items.
This makes invoking the formatter cleaner, by giving feedback and *not*
leaving curses mode. Leaving curses mode had the small advantage that
any messages from the formatter would be on the terminal after closing
nano. But it had the disadvantage that invoking the formatter flashed
the screen.
This basically reverts commit 2b9f0619 from three years ago and then
solves the issue of intruding formatter messages in a different way.
This fulfills https://savannah.gnu.org/bugs/?62789.
Requested-by: Gert Cuykens <gert.cuykens@gmail.com>
Also, elide an unneeded condition: when not softwrapping, left_x will
be zero, which is always smaller than or equal to the indentation.
Furthermore, reshuffle a few lines, improve three comments, and adjust
one to mention the parameter that was added in the previous commit.
This adjusts the main softwrapping routine so that it remembers the
reached point in a line's text and the corresponding column. This
avoids having to scan the line from the beginning for each iterative
call, and thus saves a substantial amount of time when softwrapping
very long lines.
This mitigates https://savannah.gnu.org/bugs/?62442.
Reported-by: Devin Hussey <husseydevin@gmail.com>
Original-patch-by: Devin Hussey <husseydevin@gmail.com>
The double slash would derail the file browser, causing a crash.
This fixes https://savannah.gnu.org/bugs/?62760.
Reported-by: Frank Wolff
Bug existed since version 6.3, commit fdd946c0.
Due to CVE-2022-24765, Git refuses to operate on local repositories if
it runs as a different user from its owner. Since version 2.35.2:
$ sudo git describe --tags
fatal: unsafe repository ('/home/lh_mouse/GitHub/nano-win' is owned by someone else)
To add an exception for this directory, call:
git config --global --add safe.directory /home/lh_mouse/GitHub/nano-win
Conventionally, a user, who wishes to build and install nano from Git,
does this:
$ ./configure
$ make
$ sudo make install
The first `make` command builds the program as the current user.
The `make install` then installs the built files.
However, we have a recipe for 'revision.h' that is always executed,
even in the case of `make install`. As here it is run as root, Git
actually fails and produces an empty string. This causes `make install`
to rebuild nano.o and winio.o and results in an empty version string in
the upper left corner.
The solution is simple: First we attempt a dryrun of `git describe`.
If it fails, 'revision.h', which should have been updated by the first
`make` command, will be left intact.
Reference: https://nvd.nist.gov/vuln/detail/CVE-2022-24765
Signed-off-by: LIU Hao <lh_mouse@126.com>
When one wants an Undo to restore the cursor to where it was before an
operation, one shouldn't fiddle with the position before it is stored
in the relevant undo item.
This fixes https://savannah.gnu.org/bugs/?62341.
Bug existed since version 4.9, commit 38af812a.
(This effectively reverts commit 38af812a from two years ago.)
For some reason, when copying something to the system clipboard
with 'xsel', it wants to see all output descriptors closed before
it will exit without requiring ^C.
This fixes https://savannah.gnu.org/bugs/?62276.
Reported-by: Shi Yanling <sylphenix@126.com>
Bug existed since version 2.9.8, since piping text through an
external command was introduced.
Instead of silently opening an empty buffer when the user tries to
open a file in the current but disappeared directory, give a clear
warning about the absence of this directory.
This improves the fix for https://savannah.gnu.org/bugs/?62244.
When the working directory has been deleted from under nano's feet,
get_full_path() would move up in the directory tree until getcwd()
would succeed. This meant that a filename that was specified on the
command line without any path (or with a relative path) would refer
to a different file than what the user intended. Not good.
So, stop changing directories in get_full_path(). Use the realpath()
function with NULL as second parameter instead -- it has been part of
the POSIX standard since 2008, time enough for operating systems to
have caught up.
In the bargain, this saves seventy lines of complicated logic.
This fixes https://savannah.gnu.org/bugs/?62244.
Bug existed since version 2.0.0, commit 85e35e67.
Especially when softwrapping and when multiline regexes are involved,
colorizing takes roughly exponential time relative to the line length.
To avoid bogging down, stop colorizing a line beyond a certain point.
This mitigates https://savannah.gnu.org/bugs/?61799.
Reported-by: Devin Hussey <husseydevin@gmail.com>
Although an anchor at the top line is rather pointless, it shouldn't
get cleared when the user pipes just a part of the buffer through an
external command.
When the filter command makes just small, per-line changes, keeping the
cursor at the same line number allows the user to observe the effect of
the changes -- which is not possible when the cursor gets moved to the
end of the buffer.
This partially fulfills https://savannah.gnu.org/bugs/?57248.
The same line number may not be the same position in the text, but
it will be approximately -- and it is certainly better than leaving
the cursor at the end of the buffer.
This fulfills https://savannah.gnu.org/bugs/?61175.
When making a forward movement larger than a screenful, we cannot rely
on the multidata of the line before the new screen start to have been
set correctly by a previous screen drawing, so we need to recompute all
of the multidata, for the whole buffer, so that afterward we can freely
move around and draw the screen without having to do any backtracking.
Also when a piece of text larger than a screenful is pasted or inserted,
all the multidata needs to be recomputed.
This fixes https://savannah.gnu.org/bugs/?60041,
and fixes https://savannah.gnu.org/bugs/?62056.
First bug existed in this form since version 2.4.2, commit d49c267f
(but editing Python was incomparably slower in those days).
Second bug existed since version 5.6, commit 43d94692.
This does not waste time looking for an end match, which is especially
wasteful when there is none. Also, it makes the coloring behavior more
consistent: any start match will cause coloring of the subsequent text,
no matter whether the user is in the middle of the file or near the end.
As it's possible for the start regex to match what is actually the end
match of a multiline thing (see the Python triple quotes, for example),
make sure that such a detected start match is *not* an end match, just
to avoid a needless full-screen refresh.
This makes nano conform to the https://no-color.org/ idea: suppressing
any color in the output (in the default setup) when NO_COLOR is set in
the environment.
Specifying a color for any interface element will, however, re-enable
also yellow for the spotlight and red for error messages.
This mitigates https://savannah.gnu.org/bugs/?36864.
Reported-by: Clarence Risher <sparr0@gmail.com>
Problem has existed since the beginning, as nano empties the existing
file before writing the current buffer contents into it.
Fix building with x86_64-w64-mingw32 to cross-compile native Windows
programs. Need to:
* add checks for missing functions
* don't use signals that are unavailable on the platform
* avoid useless non-Linux sys/ioctl.h include
* use putenv instead of setenv as the latter is unavailable
That is, take into account that the cutbuffer could be NULL
(when updating the undo item).
This fixes https://savannah.gnu.org/bugs/?62107.
Bug existed since version 4.9, commit b15c5a7e.
The 'endmatch.rm_eo' value is relative to the end of the start match,
so to find the end of the end match, one has to add 'startmatch.rm_eo'
plus 'endmatch.rm_eo' to the starting point of the line.
This addresses https://savannah.gnu.org/bugs/?62091.
Problem existed since version 5.6, commit 0596b875.
In version 2.2.0, pyflakes changed its output format,
from 'filename:line: text' to 'filename:line:column text'.
This fixes https://savannah.gnu.org/bugs/?62057.
Problem existed since version 2.9.0, commit 5dcf375f.
(That commit tried to compensate for an introductory message from gcc
that no longer seems to exist.)
The new name 'gauge' more clearly indicates that it is a distance
between two "columns", two "pillars", two "piles". Using 'longest'
was poor, because in fact it was set to 'widest + 10'.
(Also, change the type of 'piles' to an integer -- it will always
be smaller than COLS, and COLS is an integer.)
A newer compiler (gcc-10.3) said: browser.c:174:34: warning:
field width specifier '*' expects argument of type 'int'
It's fine for 'longest' to be an integer, as a filename in Unix is
at most 255 bytes long, which can occupy at most 510 columns (when
the name consists entirely of control codes), and that fits easily
within an 'int', which has at least fifteen bits, unsigned.
Well... in theory 'tabsize' could be set to an insanely high number,
and if a filename contains several tabs, this could cause 'longest'
to overflow. (Why doesn't the compiler warn about that?) If that
were to occur, and the filename with the tabs were the last in the
list, then 'longest' would get set to the minimum width: 15. That
would not be correct, but... nothing bad would happen.
This addresses https://savannah.gnu.org/bugs/?62014.
Reported-by: Mike Frysinger <vapier@gentoo.org>
This wipe suppression is meant to prevent the last row of the edit window
getting cleared when edit window and bottom window overlap, and this is
relevant only when the user is actually editing -- the file browser and
help viewer take care not to use this bottom row for content.
This fixes https://savannah.gnu.org/bugs/?62031.
Bug existed since version 6.0, commit be61aad9.
Problem existed since commit 3b657a26 from five days ago.
In addition, exclude pasting-at-the-prompt from the tiny version, as
it's hardly useful when one cannot copy a selected piece of text.
When re-entering curses mode, ncurses will pick up the new size of
the terminal and set the LINES and COLS variables appropriately.
(We don't ask the terminal for its size when nano starts up, so why
would we need to do it when the terminal is resized?)
Since version 2.8.7 the user can paste text at the prompt (with ^U),
but the ability to copy what is present at the prompt was overlooked.
For feedback, the cursor is moved to the start of the answer -- like
it moves to the start of the next line when in the edit buffer.
This addresses https://savannah.gnu.org/bugs/?61702.
Reported-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
In most cases, the cursor will be at the end of what the user typed
at the prompt (or retrieved from history), and ^K will work as it
always did, erasing the whole answer. But if the user has moved the
cursor to somewhere in the middle of the answer, a ^K will now erase
just the part after the cursor. A second ^K will erase the rest.
Inspired-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Because doing the spotlighting after those extra keycodes have been
handled will most likely spotlight the wrong piece of text. Also,
if those keycodes hadn't arrived early, the first of them would have
cancelled the spotlighting.
This fixes https://savannah.gnu.org/bugs/?61962.
Bug existed since version 5.8, commit 3f340836.
When a large piece of text was pasted into nano, then the old way of
repeatedly moving the buffered text one more position toward the head
of the keystroke buffer would waste a lot of time. With this change,
pasting the current NEWS file into a buffer goes down (on my machine)
from around 30 seconds to just 2.
This addresses https://savannah.gnu.org/bugs/?61822.
Reported-by: Radu Caragea <rcaragea@protonmail.com>
Problem existed in this form since version 1.3.6, commit 7483571f.
When the user exits with ^X and gets warned that the file on disk
has changed, then typing ^C at the question whether to continue
saving should not discard the buffer and exit, but should return
the user to the filename prompt.
This fixes https://savannah.gnu.org/bugs/?61883.
Reported-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Bug existed since version 2.9.0, commit 217cfbf3.
And don't mention <Tab> for the 'indent' function, as the keystroke
is equivalent to M-} only when lines are marked.
Reported-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
The value of 'consumed' may not exceed the given 'length'.
Bug existed since version 2.9.3, commit e739448c.
(Bug was found by studying Fedora crash reports. Thank you, Fedora!)
Saying "Unbound key" would imply that it could be bound in a nanorc.
This fixes https://savannah.gnu.org/bugs/?61574.
Bug existed in this form since version 2.6.0, commit e0c4f9c5.
Letting the dummy key KEY_FRESH do a full refresh in the tiny version
allows a 'fg' to properly resume after an external SIGSTOP.
(Reminder: the ungetch() is needed in the normal version to prevent
the eating of a keystroke: https://savannah.gnu.org/bugs/?48331.)
Achieve this by translating KEY_SUSPEND back to ^Z.
(Strictly speaking, this is incorrect, as the terminfo entry
might specify some other keystroke for 'kspd', but... meh.)
This fixes https://savannah.gnu.org/bugs/?61573.
Bug existed since before version 2.2.0, since keys became rebindable.
With --zero, any message that was there will get overwitten by the
text window anyway as result of the current operation. And with
--minibar, any message will get overwritten with the minibar.
This fixes https://savannah.gnu.org/bugs/?61539.
Bug existed since commit 03637030 from two weeks ago.
The unsetting should happen after the three possible early returns,
to avoid leaving the flag unset.
Also, don't bother to exclude the setting and unsetting from the
tiny version, to get rid of some cluttering conditionals.
Most terminal emulators support a palette of 216 indexed colors:
the 6x6x6 color cube pioneered by Xterm. But as an index gives
little indication about what kind of color it produces, allow the
user to specify the color with three hex digits instead, one for
the level of red, green, and blue each, in the format #rgb.
One hex digit allows for sixteen values, but as there are only
six levels available, only 0, 4, 8, a, c, and e are significant
-- other values get reduced to the nearest lower one.
This fulfills https://savannah.gnu.org/bugs/?56445.
Requested-by: Peter Liscovius, Erik Lundin, Owen Maresh, Dave Lemonby
Signed-off-by: Brad Town <brad@bradtown.com>
Only requested information (^C, M-D) and alerts stay onscreen until the
next keystroke, but less important messages are overwritten after 1.5
seconds (or 0.8 seconds with --quick). This makes the behavior more
consistent with dropping a message when there is a spotlighted match.
This fragment suppressed the cursor when it was on the bottom row of
the terminal and a message was displayed on the status bar. But since
commit a2a00577 from eight days ago, the cursor will be scrolled off
of the bottom row when there is a message.
Also, reshuffle one call and drop another: the cursor has been placed
fifteen lines earlier (either directly or in edit_refresh()).
(Important test case: toggling softwrap.)
For consistency of style, the number of lines read should only be shown
when inserting a file into the current buffer, not when reading it into
a new buffer.
This amends the fix for https://savannah.gnu.org/bugs/?61509.
Inserting another file is somewhat unusual -- it's better to give
feedback about it.
This fixes https://savannah.gnu.org/bugs/?61509.
Bug existed since version 5.5, since the minibar was introduced.
Things like "Cancelled" and "Undid addition" are not needed. They
are nice for discovery, but become distracting once you know nano.
This fixes https://savannah.gnu.org/bugs/?61508.
Bug existed since commit 03637030 from last week.
Also when adjusting the viewport, after the cursor has gone offscreen
(by toggling the help lines, for example), should the SHIM be applied.
This fixes https://savannah.gnu.org/bugs/?61503.
Bug existed since commit 03637030 from last week.
It's an editor -- the largest element should be the text to be edited,
not some part of the interface.
(It would be better if the edit window was always the largest element,
larger than or equal to all interface elements combined. But that is
something for another time.)
There is no need to prevent NO_HELP from being unset on terminals
with fewer than five rows, because the bottombars() routine already
automatically suppresses the help lines on such terminals.
This improves the fix for https://savannah.gnu.org/bugs/?61497.
(The problem with absent feedback is still there when the terminal
has just one row.)
This should make it slightly easier for translators when they compare
their PO file to nano's main help text.
Also, drop a die() -- a forgotten toggle name is not worth dying over.
When the syntax contains a 'tabgives' command, toggling the conversion
of tabs-to-spaces has no effect -- not for the current file. So, tell
the user that and don't change the flag.
This fixes https://savannah.gnu.org/bugs/?61496.
Bug existed since version 4.5, since 'tabgives' was introduced.
Messages like "Search Wrapped" and "This is the only occurrence"
do not need to be shown until the next keystroke. Dropping them
quickly gives a better fullscreen experience.
When <Tab> at a prompt shows a list of filenames, this list should
not "sit" on the prompt bar but float one row above it.
This addresses the third issue mentioned in commit 03637030.
If there is a status-bar message and the cursor happens to be on the
bottom row of the screen (in hidden-interface mode), then scroll the
viewport one row down, to keep the cursor in view.
This addresses the second issue mentioned in commit 03637030.
(The issue was rereported in https://savannah.gnu.org/bugs/?61464.)
This needlessly wipes the status bar when --constantshow is active,
but it already needlessly wiped it when --minibar is active, so...
It is not a performance issue. It was just a small optimization.
(Plus, with --zero, nano does a full edit_refresh() when in fact
only the bottom row needs to be redrawn, but there is no easy way
to do that when --softwrap is active, so...)
(Using --constantshow with --zero doesn't make sense, but the user
might want to have the --constantshow when they toggle --zero off.)
This fixes https://savannah.gnu.org/bugs/?61460.
Bug existed since version 5.0, commit d3954901, since in the normal
version ^T was repurposed to give direct access to the Execute menu.
The --noread option should apply only to the files listed on the
command line, but once nano has started, it should be possible to
insert other files into the current buffer or into a new buffer.
This fixes https://savannah.gnu.org/bugs/?61458.
Bug existed since version 2.3.3, since --noread was introduced.
Before version 4.3, commit 3eab405e, nano would write a help text to
a temporary file and then read this file into a buffer. The NOREAD
flag interfered with the latter, so needed to be reset for showing
help. But since the mentioned commit nano writes a help text directly
into a buffer and the unsetting of the NOREAD flag is superfluous.
The display code never references the LINE_NUMBERS flag -- the trigger
for displaying line numbers in front of the text is 'margin > 0'. So,
since commit 90bd25c1 that put help texts into a "normal" buffer, the
unsetting of the LINE_NUMBERS flag has been superfluous.
As a special case, and because it doesn't need any feedback on the
status bar nor other calls, add a special function and key binding
to allow the user to flip the LINE_NUMBERS flag also in a tiny nano.
This fixes https://savannah.gnu.org/bugs/?61441.
Reported-by: Hannu Nyman <hannu.nyman@iki.fi>
When the terminal has just one row, there is no room to constantly show
the position of the cursor, so do not allow the user to switch it on.
This fixes https://savannah.gnu.org/bugs/?61445.
Bug existed since version 5.8, commit 36ffb5f0.
With --zero or 'set zero', nano will hide the title bar or the minibar
(whichever is active) and will use all rows of the terminal for showing
the text of the buffer. Only when there is an important message will
it be shown on the bottom row -- until the next keystroke.
This feature can be toggled with M-Z.
The feedback at startup ("Read nnn lines") is suppressed with --zero,
because it disrupts the fullscreen experience (and is hardly useful).
The "Reading..." message then needs to be suppressed too, otherwise
it creates an annoying little flash.
There are still some issues that need to be addressed:
* In the browser, when the highlighted item is on the bottom row, it
will get obscured by the prompt bar or the "Search Wrapped" message.
* In the edit window, when the search occurrence is on the bottom row,
it can get obscured by the "This is the only occurrence" message.
* When tabbing at a prompt shows possible completions, they are shown
a row too low.
The text to be justified has been excised from the buffer and is now
in the cutbuffer, so we cannot compare any of its lines to 'filetop'.
This fixes https://savannah.gnu.org/bugs/?61438.
Bug existed since version 4.0, commit 14c08589.
In the beginning, the goal for nano was to be a drop-in replacement for
Pico. Pico did not know a Suspend command, so the ^Z keystroke needed
to be conditionalized on an option (-z or --suspend or the toggle M-Z),
just like the ^S and ^Q keystrokes (for stopping and resuming terminal
output) were conditionalized on --preserve.
But nano has abandoned full Pico compatibility since version 4.0. It
is time to unconditionalize ^Z as well. This should not be a problem:
Debian and Ubuntu have had 'set suspend' in their /etc/nanorc for years,
so a considerable portion of nano users have had ^Z enabled by default
for a long time, and no one seems to have complained.
If the keystroke bothers some user, they can unbind it in their nanorc.
They will still be able to suspend nano through the Execute menu: ^T^Z.
This addresses https://savannah.gnu.org/bugs/?61372.
The spotlighting should only be dropped when in the main menu, like in
the code thirty lines up, where 'timed' became TRUE only for MMAIN.
This fixes https://savannah.gnu.org/bugs/?61398.
Bug existed since version 5.8, commit 3f340836.
Normally, returning to the main loop will set 'focusing' back to TRUE,
but the replacement loop doesn't return until replacing is finished.
This fixes https://savannah.gnu.org/bugs/?61397.
Bug existed since version 5.0, commit d8249917.
When --breaklonglines is in effect and the user pasted just a few words
(anything without a linebreak), then act as if this short text had been
typed by the user and hard-wrap the line when it became overlong.
This fulfills https://savannah.gnu.org/bugs/?61353.
When --wordbounds (-W) is active, nano considers punctuation as
word-forming characters and will thus count words the same way
as 'wc -w' does. This is how nano counted words until now.
But when --wordbounds is not active (the default), only letters
and digits will be considered word-forming and thus lone groups
of lines and dashes and other punctuation will not be counted
as words, which is more like how a human would count words.
This addresses https://savannah.gnu.org/bugs/?61367.
In olden times, each help text started with a title line in the text
window followed by a blank line. But since version 2.8.2, since the
help texts have become almost regular buffers (and thus searchable),
the title of the help text is in the title bar, and since version 4.0,
since --morespace became the default, the text will start immediately
below it. But a title line immediately followed by text, without a
blank line between them, does not look nice. So, add such a blank
line back when not using --emptyline (and also when using --minibar,
because the top of the terminal window is like a title bar).
When the history file has been created by nano, it will not contain
any duplicate search or replace strings, nor duplicate commands, so
checking for such a duplicate for each read item was a waste of time.
And if the user edited the history file and created duplicates, who
are we to filter them out? They will not cause the history mechanism
to malfunction; they just take a little extra memory.
(Aaah, being able to define a keyboard macro
came in very handy when making this edit.)
This fixes https://savannah.gnu.org/bugs/?61331.
Bug existed since before version 2.2.0.
If all is programmed well, then the functions 'get_older_item' and
'get_newer_item' will only occur when a history list is passed to
acquire_an_answer(). But let's keep it certain we don't dereference
a NULL pointer.
Benno Schulenberg