A forward slash does not need to be escaped, and the backslash itself
should not be escaped: it serves to escape the star, to make it literal.
Also, remove a stray end-of-line anchor ($).
When there is just one match when <Tab> is pressed, and this match
is a directory, then a slash is added to 'shared', overwriting the
terminating NUL character. So, strcpy() cannot be used for copying
this 'shared' string, but strncpy() is needed, and the result needs
to be NUL terminated afterward.
This fixes https://savannah.gnu.org/bugs/?58826.
Bug existed since commit b0f56398 from eleven days ago.
The whiles are unneeded because the result of get_input() can
never be NULL when in waiting mode -- and only when searching
for something are we NOT in waiting mode.
<Ctrl+numeric slash> does not invoke Go To Line, so it is fitting
that <Esc> <Esc> <numeric slash> does neither. If some user does
want the double escape plus slash to work, they can use --raw.
(Also, if someone really uses <Esc> <Esc> <numeric slash>, they
probably also type the desired line number on the numeric keypad,
and for that to work they needed to have NumLock engaged, and in
that case the double escape plus slash will work fine.)
(Getting rid of this numeric-slash support makes the three-escapes
case very similar to the one-escape case, allowing the first to be
folded into the latter in the next commit.)
With the two situations that need to preserve the escape counter
now returning directly, the resetting of this counter can happen
at the end of each case block.
The escape-parsing routine nowadays returns FOREIGN_SEQUENCE instead
of ERR when encountering an unknown sequence. So, with the two cases
that demand ERR now handled directly, there is no need to check for
ERR any more.
There is no need to reset the digit counter (because this counter
matters only when the escape counter equals two) -- resetting the
escape counter is enough.
The digit counter will be reset to zero the next time when <Esc>
is pressed, and the byte holder gets re-initialized when the next
first digit is pressed. And the escape counter is reset to zero
after returning from a result-giving call of get_byte_kbinput().
When get_byte_kbinput() is called, it has already been determined that
the keyboard input is a digit from zero to nine (or from zero to two
for the first digit), so there is no need to check this again.
When <Esc><Esc> is followed by digit 0 or 1 or 2 but then NOT two more
digits follow, then both the escape counter and the digit counter should
start afresh when a new ESC code arrives.
This fixes https://savannah.gnu.org/bugs/?58788.
Bug existed since before version 2.0.6.
Root has carte blanche to both read unreadable files and write
unwritable files -- the file system does not prevent this. So,
alert root when opening a file that is intended to be read-only.
This fulfills https://savannah.gnu.org/bugs/?58685.
Requested-by: Marius Bakke <mbakke@fastmail.com>
Also, remove an unneeded 'if', as parse_escape_sequence() is only
ever called when there are at least two bytes after the Esc code.
(If there were not, the 'for' loop after calling convert_sequence()
would use an uninitialized 'consumed' value.)
Rereading is unlikely to fail, but *if* it fails, maybe there is a
serious problem and the user wants to try and fix it before saving
the buffer and thus overwriting the original file.
After thinking about it, I don't like it that nano makes an unrequested
failsafe backup: in the vast, vast majority of cases it is a waste both
of time and of disk wear. If the user is worried about data loss, they
can use --backup. The fsync() after writing out the buffer (added in
commit a84cdaaa) already reduces the chances on data loss somewhat.
This change moves the code responsible for backup creation to a new,
separate function, backup_file(). This function returns a boolean
indicating whether saving the buffer should proceed or not.
Signed-off-by: Michalis Kokologiannakis <michalis@mpi-sws.org>
The escape-sequence codes for the different keypad keys are simply
the relevant ASCII code plus 0x40, so they are easy to translate.
Also, do not accept keypad keys with multiple modifiers (Shift+Alt,
Shift+Ctrl, Alt+Ctrl, Shift+Alt+Ctrl) -- report "Unknown sequence"
for those.
Until now, on an xterm, Shift plus any keypad key would say
"Unknown sequence", which is not useful. On other terminal
emulators (urxvt, Pantheon, LXTerminal), Shift plus a keypad
key already produces the relevant digit or symbol, so this
change harmonizes the behavior of the different emulators.
However, on a Linux console, Shift plus a keypad key moves
the cursor and selects the text that is passed over. And
holding Alt while pressing a keypad key does nothing at all.
For the operator keys on the numeric keypad (/, *, -, and +),
make both the Alt and the Ctrl modifier a no-op.
This fixes https://savannah.gnu.org/bugs/?58731.
Bug existed since version 2.9.3, commit e734488c.
The file-saving procedure that nano followed was not crash-safe
under ext4 (and perhaps other filesystems) when editing existing
files. Specifically, modifying an existing file could lead to data
loss, since a modified file is not replaced atomically on disk.
Using "-B" did not ensure crash-safety either since the backup might
not have persisted on disk when the writeout of the file started.
In addition, if I/O pressure filled up the remaining disk space
after an existing file is truncated during save, nano would not
be able to finish saving the file, which would remain truncated.
This change addresses these issues by making nano do the following:
1) Make a temporary backup of the file being written so that there
is no time window such that (a) an existing file is truncated, and
(b) the buffer corresponding to said file has not been flushed to
disk. Such time windows are dangerous because, under certain
circumstances, they can lead to data loss on some filesystems.
The backup is made by copying the original file, and a second
attempt to HOME is made in case that first copy fails.
2) Use fsync() so that, when the save finishes, it is certain
that the file has been successfully written to disk.
This addresses https://savannah.gnu.org/bugs/?58642.
Signed-off-by: Michalis Kokologiannakis <michalis@mpi-sws.org>
This allows pasting six hexadecimal digits after typing M-V
in order to enter a specific Unicode character.
This fixes https://savannah.gnu.org/bugs/?58730.
Bug existed since version 4.8, since bracketed pastes
were introduced in commit f705a967.
The codes from (for example) U+D800 to U+DFFF are invalid. If any
such invalid code is entered at the Unicode Input prompt, nano should
not act as if the code was accepted and inserted into the buffer, and
should certainly not mark the buffer as Modified.
This fixes https://savannah.gnu.org/bugs/?58714.
Bug existed since version 4.9, commit b3faf353.
There is no need to place the cursor up front, as the drawing of
each name includes the coordinates where the name must be drawn.
Also, trim two comments and reshuffle a free().
When using --constantshow and --nohelp and opening a new buffer,
the cursor location should be shown on the status bar right away.
Bug existed since commit 2e688640 from a few hours ago.
The constant cursor display must be suppressed whenever a message
was printed to the status bar. That is: whenever 'lastmessage' is
something other than 'VACUUM'.
By default, this function is bound to ^L, to make that keystroke do
something actually useful. To not lose the Refresh function that this
keystroke had, the centering function additionally does a full redraw
and refresh of the screen.
The Haiku recipe seems to detect a .git directory somewhere, even though
they are building from a tarball. So, check instead for the presence of
nano's release script, which ought to be present only in a git checkout,
not in a released tarball.
Before version 2.9.8, nano would consider any line that started with
leading whitespace as the beginning of a new paragraph, and would thus
be unable to justify an indented piece of text (unless autoindent was
switched on). I thought that this was too limiting and changed the
way nano detects and parses paragraphs. It works fine in texts where
paragraphs occupy multiple lines, but breaks down for paragraphs of
a single line: nano merges those with adjoining lines.
Now, when -O or --bookstyle or 'set bookstyle' is used, nano will again
consider a line that begins with whitespace as the start of a paragraph
-- when 'autoindent' is OFF.
This addresses https://savannah.gnu.org/bugs/?57402.
Indirectly-reported-by: Sébastien Desreux <seb@h-k.fr>
Also-reported-by: Bill Kendrick <nbs@sonic.net>
Instead of calling a function that tries to find the relevant operation,
just add three hidden hard-bindings at the end of the shortcuts list.
They are hidden because we don't want them to show up in the help text,
because we don't know what to call them (as a Cancel and Suspend key
don't exist on normal keyboards) or naming the key would be confusing
(Sh-Ins is grabbed by the desktop manager and doesn't reach nano).
The get_history_completion() function is called in just one place,
and gets called only when the length parameter is larger than zero.
Also, improve a few comments.
Especially when it are just a handful of possible completions, it is
much nicer to have them listed close to the prompt bar where the eyes
of the user are.
This fulfills https://savannah.gnu.org/bugs/?58620.
This gives quicker feedback, and spares the user unnecessary beeps
and typing. Also, now a beep after a <Tab> means just one thing:
there are NO completions.
This fulfills https://savannah.gnu.org/bugs/?58627.
The Spell Checker is no longer among the first twelve items of the
main menu, so the conditional placing of the Go To Line item should
no longer depend on it.
The parameter was referenced in just one place. So, simply check for
the three relevant menus (and unrestricted mode) and be done with it.
This also has the pleasant effect that the menu name is now the first
parameter of do_prompt(), thus clearly indicating what prompt it is,
instead of having an opaque TRUE or FALSE value at the beginning.
Tabbing can list all files in the given directory, but restricted mode
is supposed to prevent the user from any access to the filesystem...
This fixes https://savannah.gnu.org/bugs/?58632.
Bug existed (in this form) since version 1.3.4, commit f7b5d930.
Instead of burdening seven other calls of do_prompt() with a useless
parameter, just check for MGOTODIR in the appropriate place. It also
saves having to pass the parameter down through three more functions.
The single dot serves no purpose, as the user is already there. And
the double dot is reached more easily by typing a second dot first.
And anyway, . and .. are not shown when the user does not type a dot
first, so why show them when the user types a single dot followed by
<Tab><Tab>? Most likely the user wants to see actual dot files, so
just show those.
This fixes https://savannah.gnu.org/bugs/?58619.
Now the help lines can be toggled not only while editing, but also at
the Read (^R), Write (^O), Execute (^T), Search (^W), Replace (M-R),
Goto (^/), and Yesno prompts, and also in the file browser and when
searching for a file name. The help lines cannot be toggled in the
help viewer, nor when searching in a help text, nor in the linter,
as these three things force the help lines to be on.
Furthermore, the 'nohelp' function can be rebound in all relevant
menus (default binding: M-X).
This fulfills https://savannah.gnu.org/bugs/?58471.
The modifier has to come before the foreground color name, separated
by a comma, and after 'bold,' (when present). This has no effect on
terminals that are incapable of cursive text, like the Linux console.
This fulfills https://savannah.gnu.org/bugs/?56525.
The username_tab_completion() function taken from busybox-0.46 was
just a stub, it contained basically nothing. Chris himself wrote
the function in November 2000 (commit be77c611), and rewrote it in
January 2001 (commit 2c2c5f21).
The version of username_tab_completion() in that latter commit looks
somewhat like the version of Vladimir N. Oleynik <dzo@simtreas.ru>
(busybox commit 4e338757). That commit comes three days after Chris'
commit, but Vladimir's original email is from a week earlier:
http://lists.busybox.net/pipermail/busybox/2001-January/035687.html.
So... it is quite possible that Rocco saw that email and suggested
to Chris to rewrite username_tab_completion() using getpwent().
Anyway, the version that was taken from busybox-0.46 was just four
lines and thus not worthy of copyright. The two other functions
that were copied were heavily modified in 2000, so it's better to
add that year in the copyright notice. It is fine to tweak the
notice: it just says that the original authors must be attributed,
not that the exact text must remain unchanged.
Instead of first trying to match things, and then discarding these
matches when the cursor is not at the end of the offered fragment
('buf'), simply don't bother to do any matching in that case.
The variable is set to zero at its declaration, and the second function
is called only when the first is either not called or found nothing --
thus '*num_matches' will still be zero.
This increases the chances that the wanted hash will be present in
the checkout when we haven't changed the hash for a few months.
Reported-by: Félix Piédallu <felix@piedallu.me>
Names give a rough idea of what the color will look like, whereas
numerical indexes would not do this at all.
Nine extra colors seems enough. If there were more, no one would be
able to say for sure which is which when two similar colors are used
several rows apart.
This partially fulfills https://savannah.gnu.org/bugs/?56445.
After a year or so, when people have had time to convert their syntaxes
to use 'bold' and/or 'light' instead of 'bright', we can drop this
colorizing, and still later stop recognizing 'bright' altogether.
Having the M-F toggle non-persistent, makes the behavior of ^R
predictable. This allows string binds that load a file to work
correctly independently of when M-F was last pressed.
The -F/--multibuffer command-line option and "set multibuffer"
in a nanorc file determine the default behavior of ^R.
Signed-off-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
The name 'bright' does not fit its effect (often bolding the typeface),
so better discourage its use.
Furthermore, colorize 'bold' and 'light' also for interface colors.
There were no calls of statusbar() or statusline() before curses mode
was entered. But since the previous commit curses mode is entered
even earlier, so...
A background color *can* be bright (in the sense of lighter, shinier).
It's just that the background cannot be bold. Only the typeface used
on the foreground can be bold (if the terminal supports it). So, let
"bright", when used with a background color, simply mean "light".
This makes it possible to avoid the misnamed prefix "bright". It is
misnamed because (on current terminal emulators, when the brightening
of bold is switched off) it just makes the typeface bold, not the color
brighter. The prefix "light" will now only make the color brigther,
and the modifier "bold" will just make the typeface bold (on terminal
emulators, when the brightening of bold is switched off).
On a Linux console, which is not capable of bolding the typeface,
"bold" will brighten the color.
This fully fulfills https://savannah.gnu.org/bugs/?58503.
The prefix "bright" will continue to make the color brighter AND/OR
make the typeface bold (depending on how the terminal is configured
and on its capabilities), but the prefix "light" will just make the
color brighter (if the terminal can do that).
The prefix "bright" continues to do the same as what it did before,
to not change the appearance of user-defined syntaxes. And having
an option to change the meaning of "bright"... would be confusing.
This partially fulfills https://savannah.gnu.org/bugs/?58503.
This way we don't have to probe twice, and the result is accurate also
when nano is reading data from standard input. Standard output should
always be connected to a terminal, as nano is not meant to operate
without a screen.
Each listing of a name is preceeded by a call to wmove(), so there
is no need for an initial wmove(). And after writing "more" on the
bottom row of the edit window, the loop is terminated, so there is
no need to check that this is the first item on the bottom row.
And when the margin changes (when line numbers are switched on or off,
or when the buffer grows or shrinks), and when a piece of text from a
different buffer with a different margin is pasted.
This fixes https://savannah.gnu.org/bugs/?58517.
Bug existed since commit 9a9f36fc from yesterday.
Instead of storing for each line the ordinal number of the first chunk
in that line, simply store the number of extra chunks in the line.
It now takes some more computation to actually draw the scrollbar, but
it saves a lot of computation when just inserting or deleting characters
(when using --softwrap and causing a change in chunk count).
This fixes https://savannah.gnu.org/bugs/?58510.
Bug existed since commit 6bccedb3 from two days ago.
There is no need to be explicit about not having saved the buffer --
it is implied in the "Too many". And anyway, no one is ever going to
see this message -- who will have a hundred thousand .save files?
Trimming this message makes the tiny version smaller.
Also, rewrap a neighbouring line.
By default, the position indicator is off. It can be turned on
by passing -q or --indicator on the command line, or by adding
'set indicator' in your nanorc file.
A new member ('chunk_nr') is added to each 'linestruct', to store
the serial number of the first chunk of that line, so that, when
softwrap is on, the scroll-bar thing can be computed relative to
chunks instead of relative to actual lines.
To guarantee that 'chunk_nr' is correctly synced, the buffer is
renumbered whenever the number of chunks in a line changes, and
also when softwrap is toggled on, and when buffers are switched.
Signed-off-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
This displays a scrollbar-like thing on the right edge of the screen,
giving a rough indication where in the buffer the text that is being
shown in the viewport is located, and how large/small a portion of
the buffer this text is.
(Support for softwrapping, and an option to turn the indicator on,
will arrive in subsequent commits.)
This fulfills https://savannah.gnu.org/bugs/?57956.
Original-patch-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
(Unfortunately, this means that ^L cannot be used for the
Linter in the "Execute Command" menu.)
This fixes https://savannah.gnu.org/bugs/?58469.
Bug existed since around version 2.1.0.
Nano would beep (and report "Unknown sequence") only when in the main
edit window, in the help viewer, or in the file browser. But the same
keystroke at a prompt would be enigmatically silent.
Also, in the file browser, nano would leave the cursor at the end of
the "Unknown sequence" message when --showcursor was used.
This fixes https://savannah.gnu.org/bugs/?58490.
Bug existed (in this form) since around version 2.7.4,
and in a worse form since around version 2.3.5.
A help text is contained in a normal buffer (since quite a while now),
so cursor placement should work like in a regular edit window.
Also, remove an unneeded switching on of the cursor -- it is already on
as nano is waiting for keyboard input.
This fixes https://savannah.gnu.org/bugs/?58489.
Bug existed since version 3.2, commit 10d9742c, since --showcursor
shows the cursor also in the help viewer.
If a replacement changed the matching of a multiline coloring regex,
then wipe the existing multiline data and recalculate it for the whole
buffer.
There is no need to redraw the current line (let alone the whole window)
directly after a replacement, because if there is a next occurrence, the
edit window will be redrawn then in order to spotlight that occurrence;
and if there is no other occurrence, the edit window will be redrawn in
the main loop because there has been at least one replacement.
This fixes https://savannah.gnu.org/bugs/?58481.
Bug existed (in this form) since version 2.7.5. Before that,
the miscoloring could happen even without scrolling.
When resizing the screen or toggling the help lines or refreshing
the screen with ^L, what used to be total_refresh() would first call
what used to be total_redraw(), to tell ncurses to redraw whatever
had been on the screen so far, before proceeding to fully redraw the
content of the title bar and the edit window and the bottom bars.
That was duplicate work.
Thus, rename total_redraw() to total_refresh(), so that ^L in the
edit window, help viewer, and file browser will redraw the screen
just once. This also preserves whatever was on the status bar
(when --quickblank isn't used).
Rename the old total_refresh() to draw_all_subwindows() and call
this routine when resizing the screen or toggling the help lines
or returning from the credits crawl.
This makes that the M-F toggle stays roughly in the same place when
toggling between "Read File" and "Execute Command", and groups the
six special commands together.
This makes suspension more discoverable, and allows the user to rebind
^Z in the main menu without losing the ability to suspend nano.
This drops the ^X (Flip Execute) toggle from the menu -- keeping it
would make an ugly uneven number and would reduce the space for each
menu item too much (clipping "Full Justify" and "Cut Till End") --
but it is still present as a blind toggle.
Make the "Execute Command" menu accessible also with a single keystroke
(^T), not just with a double one (^R^X). This is useful, because no one
will suspect that "Execute Command" can be found behind "Read File".
To not disturb muscle memory too much for people who are used to ^T
invoking the Spell Checker, a second ^T will invoke it.
Instead of creating a special Tools menu, add the five functions that
affect the whole buffer to the "Execute Command" menu. There is room
for these five functions there, and they kind of fit in because three
of them (Speller, Linter, and Formatter) actually invoke an external
command, and Full Justify could have been implemented externally, and
the destructive Cut Till End ought to have required a double keystroke
since the beginning.
Also, do not prompt when there is no space left on the device,
because then trying to save the actual file would likely lead
to truncating it, resulting in an empty file.
Only when fclose() is called, does the data get flushed out to disk,
and maybe only then the system realizes that there is no space left on
the device, as Chris noted in: https://savannah.gnu.org/bugs/?24000.
When asking this question when deleting fails or writing fails,
it should be asked too when creating fails. Otherwise the user
is blocked from saving the file -- until she realizes that maybe
toggling off backups would help.
If the user answered "No" or "Cancel" the first time, they should
be allowed to answer "Yes" the next time -- possibly after fixing
the necessary permissions in another terminal.
This fixes https://savannah.gnu.org/bugs/?58442.
Bug existed since version 2.3.0, commit 3d411188.
Access control lists can permit read and write access to a file
but not permit to manipulate any attributes of the file. So it
is quite possible for futimens() to fail, just like chown() and
chmod() can fail, but this should be no cause for alarm: as long
as writing the backup file worked, then writing the file itself
will probably work too.
First, it is very unlikely that chmod() would fail as the user just
created the file herself. Second, even if chmod() would fail, this
is not a problem, because we have created the file with read+write
permissions for the owner only, so the file cannot accidentally be
left accessible to unintended others.
But most of all, such a failure should not stop nano from trying to
write the backup file. Only when the actual *writing* fails, should
we bother the user with a prompt.
If there are still systems where mkstemp() creates world-readable
temporary files, then please holler. On current BSDs and on GNU,
I've verified that mkstemp() creates files with 0600 permissions.
When deleting an existing backup file failed, we do not want to
append to this file, but want instead to overwrite it (when the
user has put 'set allow_insecure_backup' in their nanorc file).
Also, when using O_EXCL (in the normal, secure case), O_APPEND
is pointless, because the file will be created and thus empty.
This fixes https://savannah.gnu.org/bugs/?58439.
Bug existed since version 2.2.5, commit 461519cc.
A normal user can change the group of a file (if the user is a member
of that group), but cannot change the owner of that file. So, when a
user edits a file that belongs to a different user, the call of fchown()
will fail. But there is no harm in that. Also when the user is root,
there is no harm in fchown() failing -- it will simply mean that the
backup file will remain owned by root and will not be writable by the
intended owner (when root has the normal umask of 0022).
This fixes https://savannah.gnu.org/bugs/?58383.
Bug existed since version 2.2.5, commit 86be3af7.
In the past, when Speller and Linter and Formatter were all bound
to ^T (later ones taking priority), it was easier to exclude also
the formatter code when --disable-speller was used. But since the
formatter was reintroduced (in commit 34170611) and bound to its
own keystroke (M-F), this is no longer the case.
When, at a prompt, the user chose a function shortcut instead of typing
an answer, and this function printed some message to the status bar,
then we do not want to wipe this message. Also: the message overwrote
and cleared the prompt bar, so there is no need to wipe the latter.
This fixes https://savannah.gnu.org/bugs/?56273.
Bug existed since version 4.0, since justifying started giving feedback
(or rather since version 4.1, since M-J no longer crashed).
Commit 12cf1c99 added a beep() for every invalid keystroke at the
Yes-No prompt, but overlooked that KEY_WINCH is not invalid.
This fixes https://savannah.gnu.org/bugs/?58422.
Bug existed since version 4.8, commit 12cf1c99.
Commit b63c90bf avoided creating an empty buffer before asking the
yes-no question when encountering a lock file at startup, but the
SIGWINCH code still expected to have an open buffer whose contents
to show.
This fix also has the pleasant effect that, when resizing the screen
at the lock-file yes-no prompt, the title bar doesn't suddenly appear.
This fixes https://savannah.gnu.org/bugs/?58414.
Reported-by: Liu Hao <lh_mouse@126.com>
Bug existed since version 4.9, commit b63c90bf.
If unlinking would fail because the parent directory is unwritable,
then a check in has_valid_path() would have prevented do_lockfile()
from being called at all.
If in between the unlink() in delete_lockfile() and the fopen() in
write_lockfile() some other process creates a symlink in the place
of the lock file, then the fopen() could unexpectedly overwite a
root-owned file (when the user is root).
This basically reverts the previous commit, b4299f4f, but makes the
code a bit conciser.
One microsecond earlier, the lock file has been deleted (if it existed),
so, if between our unlink() and our open() some other process managed to
recreate the lock file... well, we want to delete it *again*. So, just
overwrite and truncate the lock file (if it exists).
When the lock file did NOT exist (a few microseconds earlier, when
checking in do_lockfile(), before calling write_lockfile()), then
the user expects the lock file to be written, so: just write it.
That between the check and the actual writing of the lock file there
is a small window of opportunity for other processes to write this
lock file is unfortunate, but it is not a reason to bother the user
with an error message when it happens.
One microsecond before a lock file is created an existing lock file
has been deleted, and if that deletion failed, writing the lock file
is aborted. So why should writing the lock file not be aborted when
the lock file cannot be exclusively created one microsecond later?
This makes no sense. So... always include the O_EXCL flag, also
when the INSECURE_BACKUP flag is set.
(And anyway: lock files are not an essential part of editing, they
are just a small service to the user, AND they have nothing to do
with backups, so a backup flag should not influence them.)
When two lines are joined, 'refresh_needed' is already set to TRUE,
so only when a midline character is deleted the check for a changed
number of chunks is needed.
Now all functions that are relevant only to softwrapping
get called only when softwrapping is on.
This also allows to elide an intermediate function call.
A file is always in either Unix or DOS or Mac format, and should
by default be saved again in that same format.
Any lone CRs or LFs after the first line should not change the
format that was deduced from that very first line.
Only when a CR is seen before any LF, and the CR is not followed
by a LF, should this CR be interpreted as a line separator. And
only then the file should be reported as being in Mac format --
as long as --noconvert is not used.
This fixes https://savannah.gnu.org/bugs/?58357.
Bug existed since at least version 2.0.6.
Also, when finish() is called when the user presses Cancel upon
encountering a lock file, there is no need to save any history
files because nothing has changed.
When the user mentions the file "zzy" on the command line,
the magic spell "Xyzzy" does not actually get typed, so the
Easter egg should then not be triggered.
This will not catch all cases, but at least it will precalculate the
data when syntax coloring was toggled off (M-Y) while in one buffer
and then toggled back on after having switched to a new buffer.
When a file is saved under a different name, and as a result the
applicable syntax changes, and the old syntax had multiline regexes
and the new syntax doesn't, then the call of precalc_multicolorinfo()
in write_file() should not result in nano setting up a multicache of
zero bytes for each line in the buffer.
(Problem was found by locally letting nano crash when zero bytes are
allocated, and then happening to rename a file.py to a file.sh.)
A long option should describe what it does, not vaguely hint at it.
Also, in several places of nano's code we deal with actual temp files,
and then having a flag called TEMP_FILE that doesn't have anything to
do with temp files is somewhat confusing.
Just let all anchors disappear when doing an external spell check or
formatting or piping the buffer through an external command, because
leaving just a single anchor on the top line is useless.
This fixes https://savannah.gnu.org/bugs/?58273.
Bug existed since commit 732cf887 from one month ago. That code
causes an anchor to persist at the point where lines are removed.
When a single paragraph is justified, any anchor on any of its lines
gets moved to its first line. Let a full justification do the same
for each of the paragraphs.
This fixes https://savannah.gnu.org/bugs/?58272 in a better way.
This fixes https://savannah.gnu.org/bugs/?58272.
Bug existed since commit 732cf887 from one month ago. That code
causes an anchor to persist at the point where lines are removed.
When set_colorpairs() is called, no files have been loaded yet, so
no syntaxes will have been loaded yet either. Thus it is pointless
to run through the list of available syntaxes.
Its major function is to find an applicable syntax, if there is any.
And if the syntax hasn't been used before, to prime its color pairs.
Also, reshuffle a line to be able to elide an #ifdef.
In "Cut Text" and "Paste Text" the word "Text" is superfluous. (It
could even be called slightly misleading, because by default ^K will
cut the current line, whether or not it contains text.)
The "Get Help" is of course inherited from Pico, but to me it has
always sounded a bit as if it would go search help on the internet.
Instead of "Spelling" I would have preferred "Spellcheck", but that
gets a bit too cramped on an 80-column terminal.
For ^C I've chosen "Location" because I tend to understand "Position"
as a verb, especially when seen next to "Go To Line" (even when having
two items with the same meaning next to each other doesn't make sense).
"Mark Text" has simply always been wrong. It doesn't mark anything,
but just *sets* the mark (or unsets it, but that normally happens
automatically, no need to mention that in the label).
The "Cut Till End" and "Full Justify" get shown only on very wide
terminals, and at such widths there is enough room for each label
to write out those two labels in full.
Fortran and POV-Ray files are not found on any regular install of a
Unixy system nor in common software packages. People who want these
syntaxes will have to make a little effort to enable them.
Also, do not colorize the text between two stricken-through words,
do not colorize text immediately after an indented piece of code,
but do give color to a double trailing space.
Signed-off-by: Ryan Westlund <rlwestlund@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Bind the toggling of a bookmark to <Alt+Insert>, and the jumping to the
previous and next bookmark to <Alt+PageUp> and <Alt+PageDown>, so that
these functions are available by default.
Signed-off-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
With the 'bookmark' function, the user can place a bookmark on any
line in the buffer. Multiple lines can be bookmarked in this way.
With 'prevbookmark' and 'nextbookmark', the user can then easily
return to the bookmarked lines. The search for a bookmark wraps
around, as if start and end of buffer are connected.
[However, in this implementation, when a bookmarked line is deleted,
the bookmark is deleted too. This is undesirable. Also, when such
a deleted line is pasted elsewhere, the bookmark reappears with it,
and when pasted multiple times, the bookmark will be there as many
times. This is thoroughly undesirable. These behaviors will be
changed in a later commit.]
A bookmark is not yet visible in any way.
This fulfills https://savannah.gnu.org/bugs/?57577.
Requested-by: Ken Tyler <kent@werple.net.au>
Signed-off-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
This has the pleasing effect of not changing the linestruct of the
succeeding line when a line is cut.
This addresses https://savannah.gnu.org/bugs/?56226.
Instead of duplicating information, just refer to 'man nanorc'.
Also reshuffle a paragraph, and add a suggestion to just select
the syntax files that will actually get used.
It should give the same result as 'wc -w' as long as the content
of 'wordchars' does not affect the counting.
This fixes https://savannah.gnu.org/bugs/?58123.
Bug existed since version 2.6.2, since the --wordchars option was
introduced in commit 6f12992c.
First the clause for the intro text and the normal lines, and then the
clause for the continuation lines (that are narrower and indented).
Also, avoid blanking the status bar when initializing the subwindows
anyway, and avoid an unneeded resfreshing call -- the bottombars()
function will take care of that.
Normally, when undoing an <Enter> that created automatic indentation,
the created whitespace should be skipped when rejoining the two lines.
In other words: take the data starting from tail_x in the second line.
But when the <Enter> occurred at the end of leading whitespace, then
that whitespace has disappeared from the original line and it should
be copied back in from the second line. That is: from x is zero.
This fixes https://savannah.gnu.org/bugs/?58108.
Reported-by: Liu Hao <lh_mouse@126.com>
Bug existed since version 4.9, commit 1961c052.
Avoid having to decrement the count in order to offset the increment
at the end of the loop.
Also, declare a variable on a separate line, and rename it.
When using --nonewlines and the cursor has arrived at the end of the
final line, each press of M-6 would add another copy of that line to
the cutbuffer. That is clearly not the right behavior.
Also, give feedback when a press of M-6 does not actually copy anything.
This fixes https://savannah.gnu.org/bugs/?58088.
The bug was old -- it existed since before version 2.2.0.
First cutting the text to be copied (before copying it back into the
buffer) had unwanted side effects: it moved the cursor, and changed
the linestructs of the current line and the line where the mark was.
[This takes thirty more lines, but the idea is to later get rid of
the partitioning routines entirely.]
This means that in most cases mark_is_before_cursor() is called twice:
once before get_region() is called, and once by get_region() itself.
This small duplication of effort is acceptable: the affected functions
are not time critical, and it makes the code shorter.
It is very unlikely that anyone uses those keystrokes: 1) no keyboard
has such keys; 2) the default bindings for these keys were removed a
year and a half ago, and no one complained; 3) for several years nano
did not recognize the modern xterm escape sequences for F13 to F16,
and no one ssh'ing from a new machine to an old machine complained.
The only people who might be affected by this removal are Konsole users:
a Konsole claims to be an xterm, but sends its own peculiar "Esc O 2 X"
sequences for F13 to F16. Using the data from terminfo, ncurses will
not recognize those sequences, and will pass them untranslated to nano.
When nano now stops recognizing them too... Well, let's see if there
are any Konsole users that use F13 to F16.
All those items that were marked as DONE are not actually TO-DO items.
Also, most of those things are mentioned in the IMPROVEMENTS file too.
So, add the few that were missing there, and condense/rewrap some.
We do not provide an RPM package. And distros like Fedora, Mageia,
and Suse have their own spec files -- they don't need ours. And in
case anyone would like to create their own RPM package from nano,
they can look at the spec files of those distros.
It is incomplete at the top, in the middle, and at the bottom.
Also, the Makefile from gettext automatically includes this ChangeLog
in a release tarball when the ChangeLog exists. This is an unneeded
burden on the tarball, as I don't think any distro installs this file
in nano's doc directory. And if any does, I don't think they should:
it is not helpful for using nano.
If anyone would like to know more about the history of a PO file,
since we now have git, they can do something like:
git log -p po/<LANGUAGECODE>.po |
grep -e Revision-Date -e Last-Translator |
grep -A1 "^\+.PO" | less
Even though a user would never type ^J to start a new line, accept it
as a synonym of <Enter> (^M) in a bracketed paste, because apparently
bash accepts it as a synonym too.
This works around https://savannah.gnu.org/bugs/?58010.
Only for the last item at the end of each of the two help lines there
are sometimes a few extra columns available. Do not use these extra
columns also for the other help items, because apparently, when wmove()
lands in the second column of a double-width character, it does not
wipe out this character (replacing it with a space) but goes to the
next column instead, causing a misalignment of the text.
This fixes https://savannah.gnu.org/bugs/?57994.
Bug existed since version 1.3.12, commit e806ab84.
The placeholder half-duplicates the character that is actually shown
at the beginning of the next row. When NOT softwrapping, showing a
"[" before the ">" kind of makes sense: to avoid having a gaping gap
there. But when softwrapping, all characters of the line will be on
the screen (except when going offscreen at the bottom), so there is
no need to show a placeholder for anything.
I imagine that when reading softwrapped Chinese or Japanese text,
things are easier to understand when no characters are shown that
are not actually in the text.
This avoids https://savannah.gnu.org/bugs/?57993.
Bug existed since version 2.8.6, commit 8490f4ac.
When the description of a keystroke starts with a very long word,
or when it does not contain any spaces at all (like for Chinese
and Japanese), do not break in the blanks before the description
but instead break IN the description, at the edge of the screen.
In other words: when wrapping a help text, do not consider blanks in
the first 17 columns to be blanks (unless it is a continuation line).
This fixes https://savannah.gnu.org/bugs/?57987.
Bug existed since version 4.8, commit 1486f32d,
when the wrapping of help texts was improved.
Keeping the invisible cursor at the left edge avoids any line getting
scrolled horizontally.
This fixes https://savannah.gnu.org/bugs/?57991.
Bug existed since version 2.8.2, since the help texts got generated
and displayed in a different way in order to become searchable.
When either only --disable-justify or --disable-speller is used, the
"Go To Line" item should not be placed after the ^C Position item, to
keep the subsequent items (Undo, Redo, and so on) nicely paired.
(Things changed since the Linter is no longer bound to ^T by default.)
Only when the endpoint of the selection is actually IN a leading part,
then it should be advanced to include the whole leading part, so that
the succeeding paragraph will get the proper first-line indentation.
When justifying a selection from the middle of a paragraph, the first
line of both that selection and of the new paragraph after it should
get the same indentation as the first line of the original paragraph.
This fulfills https://savannah.gnu.org/bugs/?56308.
So that also the line after the newly made paragraph gets the
leading part that belongs to the start of a new paragraph.
This https://savannah.gnu.org/bugs/?57974.
Bug existed since version 4.0, since the justifying
of a marked region was introduced.
This assignment should have been removed in commit f5ac8c1e from
six years ago, as it became superfluous then. Later changes made
'cutbottom' become valid only when something had actually been cut.
Consecutive additions all happen on the same line. When automatic
hard-wrapping occurs, the ADD item is grouped together with an ENTER
item, and subsequent additions go into a new ADD item.
If the user really wants to match anything, ".*" should be used.
(This also stops nano looking at the rest of the line as soon as an
empty regular expression is encountered. This may seem like poorer
feedback than before, but... I think that multiple error messages
per line are more confusing than helpful.)
This fixes https://savannah.gnu.org/bugs/?57942.
Bug existed since before version 2.2.0.
A short allows for more than 32 thousand values, and the maximum number
of multiline regexes in any of the current syntaxes is... just four.
Reshuffle it to the beginning also because it is used the most often.
Either the marked region was cut (even when zero characters) or
the entire contents of the buffer were cut. In both cases this
is what needs to be piped to the command. That is: the contents
of the cutbuffer.
This fixes https://savannah.gnu.org/bugs/?57931.
Bug existed since version 2.9.8, commit f304b9ae,
when piping text to an external command was introduced.
Allow the creation of an empty CUT undo item (because the result of a
filtering operation may be empty), but then don't crash when undoing
such an empty CUT.
This fixes https://savannah.gnu.org/bugs/?57929.
Bug existed since version 2.9.8, when filtering was introduced.
Trying to do so would dereference a NULL pointer in copy_node().
This fixes https://savannah.gnu.org/bugs/?57915.
Bug existed since before version 2.2.0.
Also, remove two superfluous closings of file descriptors. The second
one has most likely already been closed by send_data(), by closing the
tube, and the first one will be closed by exiting from the process.
Also, avoid two superfluous assignments of a message, as they get
overwritten immediately by other ones, and later with the same.
Furthermore, remove two pointless placements of the cursor. Any
necessary placements are handled by the actual adding of data and
the breaking of lines in the ADD and ENTER items.
Especially when undoing an addition, reallocating the line data is a
waste of time, because most likely other text will be added instead.
(This also removes a coding error in the redo code for a deletion:
it allocated too many bytes for the new line data: twice the amount
of the deletion too much.)
I don't know what I was thinking three years ago with this convoluted
'from_x' and 'to_x'. When undoing an <Enter>, the cursor always needs
to be placed back at the 'head' point. And the data always needs to be
copied starting from 'tail_x' (skipping any whitespace that autoindent
might have added).
When redoing an <Enter>, there is no need to reallocate and copy the
data of the line, it is enough to just clip it at the original cursor
position. (This wastes some memory, but... how often does one redo
an <Enter>? So, conciseness of the code is preferable.)
Also, remove superfluous parentheses, add missing edge-of-word markers,
correct the "ppciseries" keyword, and fold some regexes (or elements of
them) together.
In RPM 4.15, a number of new spec section features were introduced:
* %dnl - macro-engine level comments
* %elif, %elifos, %elifarch - 'else if' stanzas for conditionals
* %sourcelist - section for listing sources line by line
* %patchlist - section for listing patches line by line
* %generate_buildrequires - script section after %prep for
generating build dependencies
(Reference: https://rpm.org/wiki/Releases/4.15.0.html.)
An enhancement added in RPM 4.13:
* Sections for file trigger stanzas
(Reference: https://rpm.org/user_doc/file_triggers.html.)
As these are being increasingly used in Fedora and other distributions,
it's quite helpful to have syntax highlighting be up to date on handling
them.
Signed-off-by: Neal Gompa <ngompa13@gmail.com>
Now all remaining calls of measured_copy() have a "+ 1" in their
second argument, and can thus be simplified. And each of those
calls is followed by terminating the string with a NUL byte, so
thát can be pulled into the function.
The old address has become invalid, and probably does not have enough
room for the write, thus causing a crash.
This fixes https://savannah.gnu.org/bugs/?57858.
Bug existed since commit 8625609c from two days ago.
Not doing it characterwise saves a reallocation, a memmove(), several
checks, and an update_undo() for each character over one.
This has been tested by temporarily setting 'bracketed_paste = FALSE'
instead of 'bracketed_paste = TRUE' in convert_sequence() in winio.c,
and then pasting stuff into nano.
And before the buffer size is adjusted, so that the add_undo()
doesn't need to correct the stored former size of the buffer.
This will allow the injection of multiple characters at once,
in the next commit.
The SPLIT_BEGIN item gets tucked underneath the ADD item on the top of
the undo stack. Thus: that SPLIT_BEGIN item should copy the 'wassize'
of the ADD item instead of storing the current buffer size.
This fixes https://savannah.gnu.org/bugs/?57832.
Bug existed since the undo functionality was added, and existed
in this form since version 2.3.5, commit be10c2a4.
In theory this would allow injecting more than one character at a time
into the edit buffer. But the creation and updating of an undo item for
the addition or the deletion of a character are a bit strange. For all
other operations and add_undo() is called before the operation, and an
update_undo() afterward. But for an ADD, the add_undo() is called after
the operation, and for a DEL/BACK, the update_undo() is called before
the operation. There is some logic to that, but things would be easier
to understand if all operations were handled the same: an add_undo()
beforehand (when needed), and an update_undo() afterward.
When something is pasted or inserted onto the final, empty line of a
buffer, an automatic new magic line is created after it, when needed.
When this paste or insertion is undone, the added magic line should
also be removed again.
This fixes https://savannah.gnu.org/bugs/?57808.
Bug existed since the undo capabilities were added,
since before version 2.3.0.
When the user (unexpectedly) types a multibyte character after M-V,
put its first byte back into the keyboard buffer, so that the next
call of process_a_keystroke() will retrieve the byte sequence as a
whole, and will inject them as one character into the edit buffer.
This fixes https://savannah.gnu.org/bugs/?57804.
Bug existed since version 2.6.3, commit 08c51cfd.
Using straightforward comparisons is clearer and faster and shorter.
Again, note that this does not filter out 0x7F (DEL). But that is
okay, as that code will never be returned from get_kbinput().
The few calls of the injection routines that had 'filtering' set to
TRUE have already filtered out ASCII control codes earlier on. And
in the case of injecting a completion, this completion only contains
word-forming characters -- and if the user somehow added a control
code to the word-forming characters, then nano should NOT filter it
out, so in fact that setting of 'filtering' to TRUE was mistaken.
Note that this filtering did not filter out 0x7F (DEL). But that is
fine: it should not occur in the input stream at that point anyway,
as it gets translated to either KEY_DC or KEY_BACKSPACE earlier in
the keyboard parsing routines.
When opening multiple files, and the first of them has a lock file,
and the user chooses to not open the corresponding file, then nano
should NOT create an empty buffer in its stead.
This fixes https://savannah.gnu.org/bugs/?57777.
Bug existed since lock files were introduced, in version 2.4.0,
specifically since commit 6948d2e7.
When copy-pasting has resulted in a nanorc file with DOS line endings
(CR+LF), then silently ignore the carriage return, to avoid printing
an error message that partly overwrites itself.
This fulfills https://savannah.gnu.org/bugs/?57756.
Requested-by: Matthias Aßhauer <mha1993@live.de>
Also, show that the argument in the extendsyntax format is not optional,
as any command requires at least one argument. Also mention 'tabgives'
among the commands that are allowed in an included file.
Since the previous commit, nano exits from curses mode soon after
this message is printed, so that the user does not have any time
to read it or even see it.
When invoking the "internal" speller, leave curses mode while the three
programs in the pipe array are executing, to prevent 'hunspell' from
writing a long error message to the end of the status bar, making the
screen scroll, and thus messing it up. Now the error message gets
printed to the screen that nano was started up from, and will thus be
visible when the user exits from nano. (At least: it will be so on a
terminal emulator -- on a VT, nothing will be seen.)
This fixes https://savannah.gnu.org/bugs/?57728.
Bug existed since version 4.6, commit 4d77e0ad.
When at startup the user presses Cancel at the "open anyway?" prompt,
cancel the whole startup: quit. But when the user answers No, just
skip the file and continue starting up.
Don't bother looping until the 1024 bytes are read. Writing the lock
file takes just one shot too, and that is more important to get right.
Also, correct the type for the result of read(), so that -1 doesn't
get turned into a positive number, which would mean that any error
would get ignored.
It would be better if nano wrote the full filename into the lock file,
because that would be clearer when Vim displays its warning, but...
this is faster and will do for now.
(Nano should simply also store the full filename in the openfile struct,
so that get_full_path() needs to be called just once for each file.)
This addresses https://savannah.gnu.org/bugs/?57713.
The call of ferror() as parameter of a %s specifier was a mistake --
it returns a number, not a string. Avoid the problem by combining
two error checks.
The man page of fwrite() does not say anything about errno, but I guess
that the function calls write() and that the possible error numbers of
that function apply.
In theory it is now possible that fclose() fails and returns an error
that then masks an earlier error of fwrite(). But I can't be bothered:
lock files are not essential, and any errors that might occur are most
likely overlooked anyway because they are not displayed in red.
This fixes https://savannah.gnu.org/bugs/?57724.
Bug existed since lock files were introduced, in version 2.3.2,
commit bf88d27a.
All the things that we need are located within the first 68 bytes of
the .swp file. We do write byte 1007 when the file is modified, but
we never reference it. We always wrote just 1024 bytes to the .swp
file, so it makes no sense to read in any more than that.
(Vim writes 4096 bytes to a .swp at first, before adding undo stuff
four seconds later. But the 1024 bytes appear to be enough for Vim
to recognize it as a lock file.)
When asking "continue?", I always thought that answering No would mean
that nano would not continue, that it would stop, that it would abort.
But No only means that it will not open the relevant file but continues
anyway to start up. Asking "open anyway?" is more easily understood in
that way.
Unreadable or corrupt lock files are not a user error nor user intent,
so they should not keep the user from editing the corresponding file.
Also, combine some error conditions to compact the code.
This addresses https://savannah.gnu.org/bugs/?57700.
When in view mode, the file cannot be edited, so there is no need to
warn anyone (through a lock file) that the file might soon change.
This fixes https://savannah.gnu.org/bugs/?57694.
At that point, 'u->cutbuffer' will always be NULL, either from the
original creation of the INSERT undo item, or by having been freed
and set to NULL by do_redo().
The 'prev' and 'next' links get assigned to immediately after the
call of copy_node(). And anyway, it does not make sense to link
a copied node to the predecessor and successor of its original.
Also slightly regroup some lines.
Also, the disabling of the keyboard interrupt (SIGINT) must happen
after that initialization call, otherwise ^C will still do nothing
after returning from suspension (when nano is built against Slang).
This fixes https://savannah.gnu.org/bugs/?57656.
Bug existed since version 2.2.0, commit daaf468c.
When the guiding stripe (when softwrapping) will be shown in
a later chunk, it shouldn't be shown in the current chunk.
This fixes https://savannah.gnu.org/bugs/?57654.
Bug existed since --guidestripe was introduced, in version 4.0.
When having prepared a line for displaying on the screen, nano already
determind whether the line extends beyond the right edge or not. There
is no need to calculate again the full width of the current line later.
Just let display_string() make a note whether the piece of text that
it converted to displayable form still has more text coming after it,
and use this note when it's time to show the ">" continuation sign.
Using a static variable is ugly, but passing it along as a parameter
would be even uglier, because for all other calls of display_string()
the parameter would be just a useless burden.
(The diff is stupid. It should just remove 440 contiguous lines, and
add back 440 contiguous lines further down. Instead it tries to find
similarities between what is moved and what remains, and makes a mess.
You have to use --patience or --minimal to get the better diff.)
The plain keys that are valid in the help viewer are a perfect subset of
those that are valid in the file browser, so just use the same function
to do the interpretation for both. It is not a problem that it returns
function pointers for some keystrokes that have no meaning in the help
viewer, because both NULL and an unhandled function pointer result in
the "Unbound key" message.
Allow the user to paste in the character for Yes, No, or All. If the
paste contains more than one character, ignore all but the first.
This fully fixes https://savannah.gnu.org/bugs/?57623.
Reported-by: Brand Huntsman <alpha@qzx.com>
The tiny version is oblivious of bracketed pastes, as it serves no
purpose: in the tiny version there is no auto-indent nor undo nor
tabs-to-spaces conversion.
Any modifier keys that are needed to start the execution of a macro
(or of a string bind) should not affect the interpretation of the
keystrokes that are contained within the macro or the string.
This fixes https://savannah.gnu.org/bugs/?57660.
Bug existed since macros were introduced, in version 2.9.0.
A control code cannot be a Meta keystroke, and a plain printable
character as key code necessarily means it is a Meta keystroke.
So, comparing just the key code is enough.
Note that DEL_CODE (0x7F) will never occur as input key code, because
it gets translated to KEY_DC in the input routine (or to KEY_BACKSPACE
when --rebinddelete is in effect).
The Shift detection on a Linux console was meant to affect only the
dedicated cursor-movement keys, not <Shift+Meta+character>.
This fixes https://savannah.gnu.org/bugs/?57598.
Indirectly-reported-by: Brand Huntsman <alpha@qzx.com>
As long as the user does not define any Sh-M-X bindings in their nanorc,
<Shift> and <CapsLock> will not have any effect on <Alt+letter> combos.
But as soon as any Sh-M-X combination is bound, <Shift+Alt+letter> will
be seen as different from the unshifted keystroke.
This kind of fulfills https://savannah.gnu.org/bugs/?54659.
Requested-by: Peter Passchier <peter@passchier.net>
Since ^@ is rebindable too and also a synonym of ^Space, it makes
more sense to allow the user to specify ^` instead, as it is an
unshifted keystroke on US keyboards.
Also, color ^` as valid in a nanorc file, and color ^` and ^@ in
the help viewer.
The meta flag needs to be suppressed only for the self-defined
<Meta+arrow> key codes.
This fixes https://savannah.gnu.org/bugs/?57643.
Bug existed since commit 5130c35b from a few hours ago.
Some key strings map to the same key code, so to unbind also a string's
synonyms, go through the list comparing against the key code. It has
the additional advantage that it is faster: a plain value comparison
instead of a string comparison.
There is no need to compare also the meta flag, because plain printable
ASCII characters (from 0x20 to 0x7E) cannot be shortcuts, so when such
a character matches, it necessarily means it is a meta keystroke.
This fixes https://savannah.gnu.org/bugs/?57397.
When assign_keyinfo() gets passed zero as key code, it will call
keycode_from_string() to determine the key code from the string.
So, remember the key code when keycode_from_string() gets called
the first time to avoid the second call.
When the mark is set at the current cursor position, and then something
is pasted (either with ^U or from outside of nano), then this entire
pasted text should be marked -- just like when it had been typed. So,
the mark's position should not be adjusted not only when it is located
before the cursor but also when it is at the same place as the cursor.
This fixes https://savannah.gnu.org/bugs/?57631.
Bug existed since version 2.0.7.
Just like nano beeps when an unbound key is pressed at other prompts,
or in the help viewer, or in the file browser.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
The suppression of auto-indentation, automatic hard-wrapping, and
tab-to-spaces conversion is now inherent in the way the reading-in
of a bracketed paste is handled by the previous commit: as a single
block of text.
This makes an external paste (with mouse or <Shift+Insert>) behave
the same as an internal paste (^U), and also inherently suppresses
auto-indentation, automatic hard-wrapping, and tab conversion.
This fulfills https://savannah.gnu.org/bugs/?54950.
This is a workaround for the VT not being able to handle zero-width
characters properly, displaying them mistakenly as visible characters.
This avoids https://savannah.gnu.org/bugs/?52954.
The problem has existed since forever, but has become noticeable
since the capability for line numbers was added in version 2.7.1.
(The ideal behavior would be that nano would warn the user beforehand,
before the file that is being edited by someone else gets overwritten,
but that would require many more changes. So... just give a helpful
warning -- that's already better than it was.)
(When the new or changed name is that of an existing file AND this
file is being edited by some other editor (or nano itself), then the
behavior is rather strange: nano asks whether to continue, but the
file has already been overwritten and there is nothing the user can
do to cancel or revert things. A later commit should improve this.)
This fixes https://savannah.gnu.org/bugs/?47975,
and fixes https://savannah.gnu.org/bugs/?53883.
Also, tell the terminal to switch on bracketed-paste mode, and toggle
a boolean when the start and stop sequences of such a paste are seen.
This boolean can later be used to suppress auto-indent and such.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
The file may not be modified when in View mode, so it makes no sense
to prominently show the M-J keystroke in the Search menu when in that
mode, especially since the keystroke does not really belong there.
This addresses https://savannah.gnu.org/bugs/?57574.
The extract() and copy_from_buffer() functions are mainly used for
cutting a line or a region, so move them to src/cut.c. Also move
the function for which copy_from_buffer() is a wrapper.
When suspending nano on a Linux console (or FreeBSD console), the
helpful message about using the 'fg' command overwrote the start
of the second help line, kind of hiding the message. So, output
a double newline before the message to make it stand out.
Also, drop a pointless cursor movement, as endwin() determines
the placement of the cursor all by itself.
Since the previous commit, USE_SLANG can only be defined when NANO_TINY
is also defined. This means that code that is present only in non-tiny
versions does not need to cater for Slang.
Slang contains bugs that get triggered when resizing the terminal,
or rather: when its existing data structures get reinitialized.
Avoid those bugs by forcing the exclusion of the resizing code
when nano is configured with --with-slang.
(The only reason for not entirely eliminating the support for Slang
is to allow Debian to build a tiny nano against Slang for on their
install image.)
This avoids https://savannah.gnu.org/bugs/?57520,
and avoids https://savannah.gnu.org/bugs/?57518,
and dodges https://savannah.gnu.org/bugs/?57513,
and dodges https://savannah.gnu.org/bugs/?57507.
With ncurses, a window resize will cause getch() to return immediately
with some dummy value, which nano can discard. But with Slang, getch()
will return only when the next keystroke is typed, so the received code
should then not be discarded.
This fixes https://savannah.gnu.org/bugs/?57507.
Use bolded HTML entities for the four arrows, instead of the literal
triangular Unicode "arrows" which many fonts don't include.
This addresses https://savannah.gnu.org/bugs/?57505.
The F13 to F16 function keys are no longer bound by default, and when
there is no nanorc file, there is no way to bind them, so there is no
point in recognizing their escape sequences.
Also, avoid calling a case-changing function when it's not needed.
And elide a default case that can never occur (because the function
always gets called with one of the four letters).
Nano does not do anything for the keystroke anyway (KEY_B2, the center
key on the numeric keypad, gets translated to ERR later on), so there
is no point in recognizing some of its escape sequences -- let those
sequences result in "Unknown sequence" instead.
When --rawsequences is used, consume the full escape sequences for
the F17 to F24 function keys (on xterm-compatible terminals and on
the Linux console), to prevent them entering junk into the buffer.
This fixes https://savannah.gnu.org/bugs/?57483.
When a line in a help text is wider than the terminal, then do not break
that line at COLS - 1, but simply at COLS. In olden times it made some
sense to have an empty column on the right of the introductory text, to
mirror the one on the left. But since the width of the introductions
got limited to 74 columns (four years ago, in commit a9aa0ef9), those
texts have (on a default 80-column terminal) at least six empty columns
on their righthand side. And on narrower terminals, we really don't
want to waste anything and should use all available space.
Also, this whole mechanism of making an exception for end-of-string or
end-of-paragraph and letting only those make use of the final column,
it was a waste of time: it kind-of did the whole break_line() process
again, but then for the entire string (which can be some five hundred
characters long in the introductory texts). So... get rid of it, make
it simple. On an 80-column terminal it doesn't make any difference.
When break_line() is called with its last parameter set to TRUE
(meaning that it will break also at a newline) it will return a
value that is bigger than 1. So it is pointless to ensure that
it is at least 1.
When justifying a paragraph, always first squeeze() is called on
the text (which at that moment consists of a single long line),
which means that (in its wrappable part) this line contains only
single spaces as word separators (and maybe a double space after
a period). So there is no need to call the general is_blank()
function -- checking for a space is enough.
Rationale: nano should not wrap inside the quoting part of a line
because it would change the quoting level, which would misrepresent
things, nor should it wrap inside the indentation part because when
the user tries to indent something beyond the target wrapping width,
she/he does not intend to create a line containing only whitespace,
but effectively wants to push the text beyond the wrapping width.
This copies the behavior of the rewrap_paragraph() routine that is
used during justification, so that automatic hard-wrapping ends up
with the same result as justifying.
Also, always do automatic hard-wrapping when --breaklonglines is in
effect, also when --autoindent is active.
This fixes https://savannah.gnu.org/bugs/?57425.
The bug was old -- it existed since at least version 2.0.6.
This furthermore avoids https://savannah.gnu.org/bugs/?57422.
Reported-by: Sébastien Desreux <seb@h-k.fr>
That bug existed since version 4.4, commit 8fce33af.
That is: allow tabs and spaces to be mixed when comparing indentation.
When the mix of tabs and spaces pushes the text of a line to the same
column as on a consecutive line, then those two lines are considered
to have the same indentation and thus belong to the same paragraph.
This reverts the previous commit (594ef222), and improves upon how
nano has behaved since version 2.9.8.
This fixes https://savannah.gnu.org/bugs/?57404 differently.
That is: two consecutive lines are considered to belong to separate
paragraphs when the smallest indentation of those two lines is not
character-by-character identical with the corresponding piece of
indentation of the other line.
In other words: if one line is indented with spaces, and a consecutive
line is indented by the same distance but with tabs, they are taken to
belong to different paragraphs: a justification will not merge them.
This fixes https://savannah.gnu.org/bugs/?57404.
Bug existed since version 2.9.8, commit 432a7d77.
Go back to how line numbers were colored in versions 2.7.1 to 4.3 --
coloring the space (when a background color is used) was unintented.
This fixes https://savannah.gnu.org/bugs/?57412.
Bug existed since version 4.4, commit 699cacf7.
For symmetry with the help viewer.
Even though the user could still exit with the bare Q, E, or X keys,
these are not listed in the help text, so they don't really count.
As was noted two months ago: nowhere in the manual does it say that
keywords are case-insensitive, and the manual shows all keywords in
lowercase, and all the examples are in lowercase too. So... simply
expect keywords to be in all lowercase.
It allows entering a TAB character at the cursor position while the
mark is on the same line as the cursor, as some users sometimes do.
This refines the feature that was added in version 2.9.2, and makes
it behave like in the Gedit and Kate editors, for example.
This addresses https://savannah.gnu.org/bugs/?57357.
Reported-by: Sébastien Desreux <seb@h-k.fr>
A negative line number given on the command line counts from the end
of the relevant file (-1 meaning the first line from the bottom),
and a negative column number from the end of the relevant line.
The feature was added in version 2.8.5 but not mentioned in the manual.
This addresses https://savannah.gnu.org/bugs/?57342.
Suggested-by: Andreas Schamanek <schamane@fam.tuwien.ac.at>
When we switch to another buffer, the window may have been resized
since we were last in this buffer, so make sure that 'firstcolumn'
gets a fitting value.
This fixes https://savannah.gnu.org/bugs/?56991.
Bug existed since version 2.8.0, since the softwrap overhaul.
Also, 'hunspell' is sensitive to the 'LANG' environment variable,
so that spell checking will take place for the language that the
user is using, instead of always for English. (This is a behavior
change, and some people may not like it, expecting the spell check
to occur always for English, but... we'll see.)
This increases the chances that spell checking will work out of the box,
without any extra installing or configuration.
This addresses https://savannah.gnu.org/bugs/?57296.
There are several cases (searching, replacing, spell checking, ...)
where exiting from the help viewer does NOT return the user to the
editing of the buffer.
This fixes https://savannah.gnu.org/bugs/?57295.
Bug existed since version 4.3, commit 5817e83e.
Also for the "universal" functions (like cursor movement) and the
special 'implant' function, the 'all' keyword should include the
browser menu.
This fully fixes https://savannah.gnu.org/bugs/?57280.
Bug existed since version 3.2, commit cc01bc3e.
Also, when something goes wrong in the later stages of the pipeline,
the error code would try to close descriptors that are already closed,
which is not right. So, just let exit() handle any file descriptors
that are still open.
When something goes wrong, nano should beep and the status bar should
use the error color (red by default).
This fixes https://savannah.gnu.org/bugs/?57116.
Run the formatting program outside of curses mode, so that any output
(complaints) that it produces will be on the terminal after exiting
from nano -- at least on a terminal emulator, not on a Linux VT.
This also allows the formatter to be an interactive program.
The disadvantage is that the screen flickers when typing M-F.
This fixes https://savannah.gnu.org/bugs/?57104.
For a nonzero exit status of the formatting program, report on the
status bar that the program "complained", but read in the (probably)
reformatted text anyway -- it can be easily undone with M-U. Only
report failure when the intended program could not be run.
This fixes https://savannah.gnu.org/bugs/?57105.
The word "fixer" sounds too much as if the command would be able
to fix mistakes or correct errors. Especially when seen next to
"linter", it sounds as if one does a syntax check and the other
fixes the found mistakes. (Although the command might in theory
be used for this, it is not its intended purpose.)
Attribute names that are a part of another word should not be colored,
nor should attribute names within strings.
This addresses the other half of https://savannah.gnu.org/patch/?9865.
Original-patch-by: Ryan Westlund <rlwestlund@gmail.com>
When dealing with a plain, seven-bit ASCII character, don't bother
calling is_cntrl_mbchar() but determine directly whether it is a
control character. Also reshuffle things so that we don't compare
charlen == 1 when we already know it is 1.
After the previous change, all remaining calls of parse_mbchar() have
NULL as their third parameter. So, drop that parameter and remove the
chunk of code that handles it. Also rename the function, as there are
already too many functions that start with "parse".
Do not wait for the user to press a key when there is some problem
with any of the history files. Just start and indicate the problem
on the status bar. The precise error message is stored and will be
shown on the terminal when exiting from nano.
This addresses https://savannah.gnu.org/bugs/?56524.
Now all calls of mallocstrncpy() have NULL as the first parameter
(apart from one call in utils.c, but that can be changed), so the
function can be simplified.
This case is caught (by O_EXCL) later on, at the appropriate moment:
when the file is created.
Also, this removes a superfluous lstat() for each temporary file.
Weird bug. The first occurrence is probably never hit because the
existing file has been tentatively opened fourteen lines earlier,
but that looks superfluous: double work. And the second occurrence
will not be hit because the temp file is unlikely to have disappeared.
Also, don't bother assigning the stream pointer of the existing file
to variable 'f', as it gets overwritten right away by the pointer of
the temp file.
A possible change in filename won't be pushed to the screen until a
doupdate() is done, and that won't happen until nano is waiting for
a keystroke again. So... just let it be.
The old default behavior of showing the first three messages with a
long pause after each of them was annoying, and the final "Further
messages were suppressed" hid the relevant information. So, when
there is more than one error message, just pause very briefly and
then add trailing dots to the first message.
This makes the 'nopauses' option a no-op.
This addresses https://savannah.gnu.org/bugs/?57048.
Nowhere does the manual say that nanorc keywords are case-insensitive,
and none of the examples use uppercase keywords. So, simply consider
uppercase keywords to be invalid. This will later allow nano to use
case-sensitive comparisons, which are slightly faster.
The command can be used to run some kind of formatter or corrector or
arranging tool on the buffer. By default the command is bound to M-F.
The formatter/corrector/arranging program must be non-interactive.
This addresses https://savannah.gnu.org/bugs/?55365,
and addresses https://savannah.gnu.org/bugs/?54651.
The nano.h file is included only by proto.h, and the proto.h file is
included just once by each src/*.c file. The include guards for these
two header files serve no purpose.
(Include guards are useful when you have bunches of header files
and several of them include others from amongst themselves.)
When an operation that replaces the entire buffer is undone, the
position of the viewport is lost. Compensate for this by storing
the row of the cursor in the undo item, and, after executing the
undo item, arranging the viewport so that the cursor is back on
the original row -- the row where the operation was invoked.
This fixes https://savannah.gnu.org/bugs/?57039.
For the three operations (justification, spell checking, and filtering)
that need to undo or redo two suboperations (cutting and then pasting)
in one go, pass the message that describes the operation to add_undo(),
so that the undo item does not need to be modified after the call.
This looks better, but does add some twenty NULL parameters elsewhere.
When 'extendsyntax' is used with a 'header' or 'magic' command, it
must be processed immediately. It is pointless to store the command,
because when then it is processed (when the syntax gets used), it is
too late to have any effect.
This fixes https://savannah.gnu.org/bugs/?56997.
With-help-from: Brand Huntsman <alpha@qzx.com>
Bug existed since version 4.3, commit cba9d8d0.
Instead of marking the buffer as modified, provide the feedback that
"nothing was cut", like when trying to chop a word rightward at the
end of the buffer.
This fixes https://savannah.gnu.org/bugs/?57015.
Bug existed since version 4.4, commit 4314b8de.
For historical reasons the rebinding code allows binding F13...F16,
which on most terminals are typable with Shift plus F1...F4. But,
at least on an Xfce Terminal, Shift plus F1...F12 produce F13...F24.
On a Linux console, Shift plus F1...F8 produce F13...F20. So: allow
to bind the full shifted F13...F24 range. It costs no extra code
and makes things more rounded.
Hard-binding the ^H control code prevents the user from rebinding
the keystroke.
This fixes https://savannah.gnu.org/bugs/?56995.
Bug existed since version 4.0, commit 72a49dbb.
In a non-UTF8 build, mbwidth() returns always 1, so it is pointless
to call that function and compare its result to zero then.
Also, don't bother special-casing the function for a non-UTF8 locale.
When there are fewer than four menu items, act as if there are four:
make their clickable width half the width of the screen.
Until now, when there were two menu items, their clickable width would
be the full width of the screen, which was overwide. But when there
was just one menu item, its clickable width would suddenly be as small
as when the menu had the maximum number of items (12 for an 80-column
screen). This was odd.
Also, slightly simplify another computation.
The first_sc_for() function is somewhat costly, so avoid calling it
when it is not necessary.
Most menus have either so many entries that unbinding some keys does
not reduce the number of shown entries, or they have so few entries
that each entry already has space enough and will not profit from
having more room available. But the WriteOut menu is an edge case.
Most translators don't use --tempfile and translate the key tags for
the WriteOut menu making use of all 17 positions that are available
for each of them. This makes that when --tempfile is used, some of
those tags get truncated. This is not so bad, because --tempfile is
normally not used. But when it isn't used (when the discardbuffer
function isn't bound), the WriteOut menu should make full use of the
available width to avoid truncating any translated tags.
In this way the keycode cannot be unbound from the 'indent' function,
so pressing <Tab> on a marked region will always indent the region.
This fixes https://savannah.gnu.org/bugs/?56960.
Bug existed since the "tabbing" of a marked region was introduced,
in version 2.9.2, commit 09958ebd.
The 'tabgives' command is syntax-specific and should be followed by a
string containing the character(s) that a single press of the <Tab> key
should produce -- most likely a single TAB or a small bunch of spaces,
but any string is allowed. This overrides the 'tabstospaces' option.
When one wants to make sure <Tab> inserts always four spaces and never
a TAB when editing a Python file, one could add to one's nanorc:
extendsyntax python tabgives " "
where there are four spaces between the quotes. And when one wants
to ensure, when editing a Makefile, that <Tab> always inserts a TAB
and never spaces, independent of what tabstospaces is set to, one
could add to one's nanorc:
extendsyntax makefile tabgives " "
where there is a literal TAB character between the quotes.
This fulfills https://savannah.gnu.org/bugs/?53661,
Requested-by: Andrew Pennebaker <andrew.pennebaker@gmail.com>
And addresses https://savannah.gnu.org/bugs/?54760.
Requested-by: Henry van Megen <hvanmegen@gmail.com>
And addresses part of https://savannah.gnu.org/bugs/?54775.
Requested-by: Dirkjan Ochtman <dirkjan@ochtman.nl>
As printf() is not UTF8-aware, we have to determine ourselves how many
columns each short and long flag take up and add the required number of
spaces (not tabs, because their size is not fixed) to fill things up.
This fixes https://savannah.gnu.org/bugs/?56928.
Bug existed since version 4.3, commit 2f169107.
When the user specified an absolute path... it is NOT relative to the
current working directory.
This fixes https://savannah.gnu.org/bugs/?56902.
Reported-by: Brand Huntsman <alpha@qzx.com>
Bug existed since version 2.4.2, commit ec8d51be.
For a forward search from the command line, pass FALSE to 'skipone'
so that an occurrence at the head of the file is not skipped over.
This fixes https://savannah.gnu.org/bugs/?56845.
Reported-by: Derek Wolfe <dwwolfe1@gmail.com>
Signed-off-by: Brand Huntsman <alpha@qzx.com>
The regcomp() function from glibc-2.27 (and older) considers the
bracket expression ['-.] to be invalid -- mistakenly. Avoid using
any range expression in the relevant regex and instead enumerate
all acceptable characters.
This avoids https://savannah.gnu.org/bugs/?56766.
Allow the user to specify that the search string should be interpreted
case-sensitively and/or as a regular expression by preceding the search
indicator (/ or ?) with c and/or r. Or to switch these things off by
using C and/or R.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The string to "jump to" is specified with +/ for a forward search
(from the top of the file), or with +? for a backward search (from
the bottom of the file).
This fulfills https://savannah.gnu.org/bugs/?54535.
Requested-by: Derek Wolfe <dwwolfe1@gmail.com>
With-help-from: Brand Huntsman <alpha@qzx.com>
So that in the error message the correct filename gets shown
instead of the name of the (first) include file.
Reported-by: Brand Huntsman <alpha@qzx.com>
When reporting a syntax without any color commands, show the line number
of the relevant 'syntax' command instead of the line number where the
emptiness is concluded, because the latter can be many lines later.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
The previous commit saves and restores filename and linenumber for
each single included file (after globbing), so it is now redundant
to do it for each 'include' command.
For each included file, save and restore file name and line number of
the including file, so that an error message about a faulty 'include'
command can indicate the location of this 'include'.
This fixes https://savannah.gnu.org/bugs/?56488.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
It's in a two-column format that fits on a single page, and uses the
more widely known Ctrl+X and Alt+X notations (instead of ^X and M-X).
The file is published on https://nano-editor.org/cheatsheet.html.
And generally improve the regex for coloring Perl variable names.
This fixes https://savannah.gnu.org/bugs/?56713.
With-help-from: Brand Huntsman <alpha@qzx.com>
Bug existed since the Perl syntax was introduced,
in version 1.2.2, commit 70047eef.
So that 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/?56737.
Require that a comment starts at the start of a line or is preceded by
whitespace. This prevents most hash signs used for other purposes (and
what follows them) getting colored as comments.
When the user is typing a long text and --breaklonglines is in effect,
then any leading comment or quoting characters are automatically added
to each automatic new line.
This fulfills https://savannah.gnu.org/bugs/?56042.
Requested-by: Sébastien Desreux <seb@h-k.fr>
The check mistakenly prevented the user from copying a region that
ended at EOF. Removing the check also gives the user a way to clear
the cutbuffer (with M-A M-6 or ^6 M-6, for example).
This fixes https://savannah.gnu.org/bugs/?56563.
Reported-by: Liu Hao <lh_mouse@126.com>
Make display_string() report back (via a global variable) whether the
just converted string has room to spare within the allotted span, so
that draw_row() can avoid trying to clear the remainder when there is
nothing to clear.
This fixes https://savannah.gnu.org/bugs/?56562.
Bug existed since commit 699cacf7 from three days ago.
If the edit window consists of a single row, then the do_down() call
has already brought the desired line or chunk into view -- no attempt
should then be made to scroll the screen further.
This fixes https://savannah.gnu.org/bugs/?56553.
Bug existed since version 2.9.6, commit 0d9080a2.
It is a waste of time to first fully clear a row when right afterward
text will be written to it (for most of the row, on average). So...
just clear the part of the row after the written text. Curses has the
perfect function for this: clrtoeol().
The edit window has been fully cleared just before the list-drawing
loop has started, so there is no need to wipe anything. Only for the
highlighting bar all its characters need to be drawn with the correct
attributes.
Where the row needs to be filled with spaces with the attributes that
were set (title bar, prompt bar, and browser highlight), use printw().
But when the row needs to be actually cleared, use the much faster
clrtoeol().
This reduces the time needed to clear a full row with 95 percent.
Since commit 7028adf2 from three days ago, also the color commands of
syntaxes that are defined in a main nanorc will get parsed during a
second pass, so it is perfectly possible to extend such syntaxes
later on in the same (or another) nanorc file.
'opensyntax' is relevant only during the first pass through all the
nanorc files (intros_only == TRUE) when it is checked that syntax
commands are grouped properly and not mixed with others. And
'lastcolor' is relevant only during the second pass of a specific
syntax, because only then the color commands are actually parsed.
Whenever, in an rcfile, a command is encountered that is not part of a
syntax definition, a currently open syntax should be closed, but only
after checking that the syntax contains at least one color command.
This fixes https://savannah.gnu.org/bugs/?56501.
Bug existed since version 2.3.3.
The 'color' commands of a syntax definition should not be allowed to
be interspersed with other, non-syntax commands.
This fixes https://savannah.gnu.org/bugs/?56498.
Bug existed since before version 2.6.0.
As 'extendsyntax' commands are no longer interpreted immediately when
the rcfiles are read, there is no need to set 'opensyntax' to FALSE
after interpreting such a command -- for a single syntax they are all
interpreted in a row.
An included file can contain multiple syntaxes. If reading would stop
as soon as a command different from 'syntax' and 'header' and 'magic'
is found, any later syntaxes would not be seen. So each nanorc file
needs to be fully scanned -- it's just the interpretation of all the
color commands that we want to delay until the syntax gets actually
used.
This fixes https://savannah.gnu.org/bugs/?56478.
Bug existed since commit cba9d8d0 from a month ago.
Also, don't use mblen() directly, to not get stuck when it returns -1,
which it will when running a non-UTF-8 build in a UTF-8 locale.
This fixes https://savannah.gnu.org/bugs/?56472.
Bug existed since commit cd094822 from yesterday.
The majority of characters in the files that get edited with nano will
be single-byte printable ASCII characters, so their case should come
first in the main loop of display_string().
In addition, the function was used just once, had a weird return value,
and now some more code can be excluded from a non-UTF8 build.
Make use of the fact that any single-byte character always occupies
just one column, and call the costly mbtowc() and wcwidth() only for
characters that actually are multibyte.
Instead of calling in twenty places parse_mbchar(pointer, NULL, NULL),
use a simpler and faster char_length(pointer). This saves pushing two
unneeded parameters onto the stack, avoids two needless ifs, and elides
an intermediate variable.
Its main purpose will follow in a later commit: to speed up searching.
This function is used in get_totsize(), so speed is important.
There is no reason why the length of the string must limited to a
certain size -- that is just a leftover from the function merge in
commit ba2e6f43 from a year ago.
The use of a double dash (for an option name or as sentence separator)
is too common to allow it to be seen always as a comment introducer.
Users of Lua and Postgres will have to redefine 'quotestr' themselves
if they want to be able to rewrap block comments with ^J.
The other characters that were added in commit c5a72103 (!, %, and ;)
are less problematic because they tend to be glued to the end of words,
so they are unlikely to appear at the start of a line.
This fixes https://savannah.gnu.org/bugs/?56462,
and fixes https://savannah.gnu.org/bugs/?56461.
Bug existed since version 4.0, commit c5a72103.
There is no need to make a copy of the line, because if there are some
bytes that are moved, they are always moved toward the left -- the line
can only shrink, never expand.
When squeezing excess spaces from a line has proved unsuccessful, we
have already copied all of its data, so it hardly makes a difference
whether we free the old or the new data. Choose to free always the
old data, so that we can simplify things.
Instead of saying that string parameters should be enclosed in
double quotes, just show the quotes in the relevant commands.
Also, rename the parameters, to better fit the subsequent description.
This "holder" information is needed for every cut and paste and other
block operation. Instead of allocating and freeing it for every such
operation, just have the six elements as static variables. This saves
a little churn, and saves having to declare a type that is used just
once. Plus, the access to these variables will be a little quicker.
When a syntax gets parsed, store the compiled color regexes right away,
instead of compiling them a second time in color_update().
This addresses https://savannah.gnu.org/bugs/?56432.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The /etc/nanorc file should not define any syntax directly (and
preferably not include any either, to not slow startup down with
syntaxes the user is never going to use), and if the ~/.nanorc file
defines a syntax directly, there is no need to use 'extendsyntax':
the command can be added to the syntax itself -- it would be better
even: it keeps things together.
Extending a syntax will be rather rare, so the amount of memory it
takes up will be minimal. It's not worth the trouble to free this
memory -- it only takes time. Plus: we don't bother to free the
memory of a syntax that gets fully redefined either.
When an included file has just been fully parsed, 'lastcolor' is still
pointing at the last color regex that was added to the list -- no need
to refind the end of this list.
Add a temporary boolean for this, because isendwin() returns TRUE
only when curses mode has actually been started with initscr() and
then exited with endwin().
The sphere, the holder, is everything *around* the partition;
it was confusing to call this holder type 'partition'.
Also correct and improve some comments.
There is no need to save, clear, and restore the mark when counting
words, lines and characters, because partitioning and unpartitioning
the buffer does not use the mark nor affect it.
Now M-D will report 0 lines instead of 1 line for an empty buffer, and
will match the output of 'wc --lines' as long the file is a POSIX file.
This fixes https://savannah.gnu.org/bugs/?56054.
Bug existed since before version 2.1.10.
For this one quick switch back and forth there is no need to report
anything on the status bar nor to update colors and such. In this
case, those things are just a waste of time.
The extra things that close_buffer() did are only needed and useful
when manually closing a buffer, so move them there. The other three
calls of close_buffer() only need to get rid of the current buffer
(making the preceding buffer the new current one) and nothing else.
When a help-text buffer is closed while exiting from the help viewer,
the rest of the exit code takes care that the preceding buffer gets
displayed properly. And when a help-text buffer is closed because a
SIGWINCH occurred, doing anything for the preceding buffer is a waste
of time because a new help-text buffer will be opened and displayed
instantly.
This avoids the substantial overhead of first writing and then reading a
temporary file, and in the bargain removes two possible failure points.
This fulfills https://savannah.gnu.org/bugs/?56371.
Closing a buffer automatically switches to the next buffer. But for
the help-text buffer this is not the desired behavior, so each closing
needs to be followed by a switch to the preceding buffer.
This fixes https://savannah.gnu.org/bugs/?56411.
The previous commit makes that the terminal's state is only resaved
when standard input is actually reconnected to the terminal, and
leaves it unchanged otherwise. Apparently this is enough to fix
https://savannah.gnu.org/bugs/?56394.
When after reading a file we are not in curses mode, it means we have
read data from standard input, either from the keyboard or from a pipe.
In the latter case, we first need to reconnect standard input to the tty.
And in both cases, we then need to reenter curses mode before being able
to display the number of lines that were read (or an error message).
So, move the reconnecting code from scoop_stdin() to its own function,
and call this function from read_file() when needed.
This fixes https://savannah.gnu.org/bugs/?56310.
Bug existed since version 2.1.8 when reading from stdin was introduced.
For some reason a SIGWINCH or SIGINT "corrupts" the current state of
the terminal, and magically validates the state that was saved first.
This fixes https://savannah.gnu.org/bugs/?56394 properly.
The user will understand that changing the state of the terminal
while inputting data into nano is not the same as changing this
state before nano has started or after nano has exited.
This fixes https://savannah.gnu.org/bugs/?56394.
Bug existed since version 2.4.2.
Either this enabling is not needed at all when the original terminal
state has been restored, or it will be needed in the tiny version too.
Also condense some comments.
If the rest of nano is correct, then these checks are superfluous and
only slow the loops down. But if there is some incorrect code, then
let nano crash on dereferencing NULL so we can find and fix the bug.
No one ever reported seeing the message that was removed in commit
c039aaad one month ago, so most likely the code is correct and nano
never calls line_from_number() with a non-existent line number.
The 'quiet' parameter is only used when opening a help-text tempfile
or a spell-checked tempfile, and these files necessarily exist, so
'quiet' will never be checked for them. But in the weird case that
the help-text tempfile could not be opened, it is not a problem that
"New File" gets printed to the status bar because nano will crash
shortly afterwards. And when the spell-checked tempfile could not
be opened, a "Not Found" message is appropriate, but nano will crash
in this case too.
For both an integrated and an external spell check, fake the Shift key
being held so that (when the cursor is moved by a changed length of a
word) a Shift-selected region is not unexpectedly cancelled.
This fixes https://savannah.gnu.org/bugs/?56365.
Don't bother checking for an error from sigaction(), because the only
things it could error out for is when it is passed an invalid signal
(which SIGINT isn't) or oldaction/newaction would point to memory that
is outside of nano's control (which is obviously not the case).
Also, the setup of signal handlers during startup does not check for
errors, so why do it here?
If functions deeper down would put up some message on the status bar,
it should not be cleared. The chance that messages from a spell-check
program stay onscreen is minute: the edit window is fully refreshed,
the status bar is fully drawn, and the help lines (if there are any)
are redrawn. Only the title bar is not refreshed, but the chance that
an error message has spilled onto the top row... And anyway, the
spell checker should not print any error messages at all.
When parsing an included syntax file, stop reading when a command other
than 'syntax', 'header' or 'magic' is encountered. The syntax file is
fully parsed the first time that a file needs it. Each 'extendsyntax'
command is stored for unloaded syntaxes and applied after the syntax
is loaded.
Closing a buffer does not unload the syntax, even if no longer used by
another buffer.
This addresses https://savannah.gnu.org/bugs/?54928.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
This is needed to implement the demand loading of syntax files, as any
errors that these files may contain would otherwise overwrite things on
the screen and the messages wouldn't be on the terminal when nano exits.
It also allows nano to start up on a Linux console when there are errors.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
When the data is fed to nano through a pipe, it is pointless to print
this message as it can be seen only after nano has exited.
This addresses https://savannah.gnu.org/bugs/?56348.
The blank filename should not give any match, but maybe the header line
or the magic finds a fitting syntax.
This fixes https://savannah.gnu.org/bugs/?56344.
Trying to append does not work on a fifo, and we'd like to be able to
open a fifo again. Also, the append test causes a close event for the
given file at the moment of opening it, which makes using 'inotify' for
waiting for this file to be closed useless.
Commit f8f90272 added the append test, but the original request
(https://lists.gnu.org/archive/html/info-nano/2009-05/msg00000.html
by Damien Joldersma) asked only for a warning when the user did not
have enough privileges to write to the file.
So, drop the append test and just check the access bits.
This fixes https://bugs.debian.org/583196
and fixes https://savannah.gnu.org/bugs/?29312.
The original requests (https://bugs.debian.org/551717 by Paul Wise,
and https://savannah.gnu.org/bugs/?45383 by Mike Frysinger) asked
only that specifying a directory instead of a file name should not
open a new buffer. But commit 98ffb642 excluded everything that was
not a normal file. This avoids a hang when the user accidentally
tries to open a pipe or a socket, but also prevents any user from
doing so on purpose. And opening a fifo can be useful when wanting
to handle sensitive data that shouldn't be stored on disk.
This prepares the fix for https://bugs.debian.org/583196.
When wanting to exit after having modified a buffer by mistake, I don't
want to politely answer a question by typing precisely an unmodified N,
I want to give a command: ^N, meaning *No!*. Or seen another way: I
don't want to be obliged to let go of the Ctrl key before typing N.
When at startup --tempfile was used, the user can discard a modified
buffer with ^O ^Q. It would be nice when (without --tempfile) ^X ^Q
would work too.
Also, compute the required space for the keystrokes more tightly:
most of those characters are plain ASCII, so that means 17 bytes
for 17 cells, and at most one of those characters is a three-byte
arrow, which means 2 bytes extra. Adding the two newlines at the
end, the needed room besides the description is 21 bytes.
Fall back to using the words "Left", "Right", "Up", and "Down",
instead of graphical arrows.
This fixes https://savannah.gnu.org/bugs/?56313.
Bug was left to exist since the Alt+arrow keys were introduced,
in version 2.8.7, commit 1cc030f7.
If the cursor is near the bottom row when softwrap gets switched on, the
screen should scroll just the amount needed to keep the cursor onscreen.
This fixes https://savannah.gnu.org/bugs/?56317.
Bug existed since softwrapping was introduced in version 2.1.11.
The quotes of an empty string ('' or "") should be colored just like
those of a non-empty string, because otherwise the text *between* two
empty strings on the same line gets colored.
Add an extra rule to discolor triple quotes again to not make them
look like valid by themselves.
Also, remove six superfluous backslashes.
This addresses https://savannah.gnu.org/patch/?9801.
Reported-by: Ryan Westlund <rlwestlund@gmail.com>
The integrated spell checker does not use regular expressions, and
'refresh_needed' is set to TRUE anyway, so the tidy_up_after_search()
call there is effectively a no-op.
The 'keep_cutbuffer' variable becomes FALSE whenever there is cursor
movement or there was a marked region. Use this variable to simplify
the condition for creating a new ZAP undo item. But then typing the
'zap' shortcut should not cause the variable to be set to FALSE.
This fixes the first part of https://savannah.gnu.org/bugs/?56261.
Bug existed since zapping was introduced, in version 3.2.
After the previous change, a copy command will break a chain of cut
commands, so there is no need any more to verify that the line number
hasn't changed.
When 'last_action' has a specific value, then necessarily there must
exist a corresponding current undo item.
(The condition is already absent in do_deletion(), for the BACK and DEL
undo items, and it works fine there.)
The cut and copy operations (^K and M-6) are different operations and
one should not add to the cutbuffer created by the other.
This fixes https://savannah.gnu.org/bugs/?56251.
Bug existed since version 3.0, commit 71f85937.
The lines from the cutbuffer will be renumbered when it matters: when
they get pasted.
The only place that used the numbering of (a copy of) the cutbuffer
(the updating of an undo item) already iterates through its lines.
Just add a counter there instead of making use of the line numbers.
All extractions are done into the cutbuffer, so it is pointless to pass
'cutbuffer' and 'cutbottom' in and back out as parameters all the time.
Just use those global variables directly.
Also, rename the function as there is no longer a buffer among its
parameters.
The 'cutbottom' variable is only ever used when cutting or copying
consecutive lines: for appending the current line to the already
existing lines in the cutbuffer. As soon as some other operation
is performed, 'cutbottom' becomes irrelevant, it could be set to
anything, it doesn't matter: the pasting of the cutbuffer does not
use the value of 'cutbottom', nor does any other operation.
The line numbers don't matter for the cutbuffer itself, but they matter
for the copy of the cutbuffer that is stored in an undo item.
This reverts commit 14140d52 from two hours ago.
This fixes https://savannah.gnu.org/bugs/?56245.
After extracting a line or region, the current line is always the one
where renumbering should start. And when ingrafting a buffer, it is
always the first ingrafted line where renumbering should start. The
'top_save' variable was indirectly getting set to those lines.
Also, renumber immediately after unpartitioning the file buffer, before
doing anything else.
Just like for deleting a word to the left, the mark should be ignored
also when deleting a word to the right.
This fixes https://savannah.gnu.org/bugs/?56241.
It doesn't matter whether the grafted text contains a newline or not.
It only matters whether the mark was before or after the cursor. When
it was after the cursor, the mark needs to be set to the bottom line of
the grafted text and its x coordinate needs adjustment; and when it was
before the cursor, the mark just needs to be set to the top line of the
grafted text.
Avoiding this leak is more trouble than it's worth: invocation_error()
will be called seldomly, and when it is called, the user will probably
quickly exit from nano to fix things.
Also declare the speller functions as const again, so they don't give
the impression that their result can be freed.
Suggested-by: Brand Huntsman <alpha@qzx.com>
Now you can have a look elsewhere in the buffer (and even delete
or paste stuff there) and when you return to the original line
and continue typing, any spillover from automatic hard-wrapping
will spill over onto the same line it spilled over to before.
You can even switch to a different buffer and return and continue
typing, and stuff will still spill over to the same line.
In the bargain, this gets rid of a bit of flag-resetting code
that was run for many keystrokes, in most cases needlessly.
This addresses https://savannah.gnu.org/bugs/?56189.
When automatic hard-wrapping causes some piece of a line to be pushed
to the next line, then a separating space needs to be added at the tail
of this piece only when this piece actually gets prepended.
This fixes https://savannah.gnu.org/bugs/?56185.
Bug existed since version 2.9.2, commit 29f7654a.
When typing a space causes both the succeeding word and the cursor to
be pushed to the next line, then this space (and any contiguous ones)
does need to be snipped (when --trimblanks is in effect).
This fixes https://savannah.gnu.org/bugs/?56180.
Bug existed since version 2.9.3, commit 91073be4.
Fuzzy strings don't contribute anything to the translations that the
users get to see. They are useful only for translators, but translators
fetch or receive their PO files from the TP. For nano, fuzzy strings
just bloat the distribution tarball.
These obsolete strings contribute nothing to the translations that the
users get to see. They are somewhat useful only for translators. But
as nano is registered at the Translation Project, translators fetch or
receive their PO file from there (or they keep their own archive), so
these obsolete strings are not getting lost. But for nano, they just
burden the distribution tarball.
Do the same as in the previous commit: re-evaluate the start of the
viewport when lines that are located above this viewport may have
changed. This is relevant when softwrap is on.
When only the trailing chunk of a line is displayed on the top row of
the screen, and the unindenting of this line leads to a reduction in
the number of chunks, then the starting point of the viewport needs
to be re-evaluated. For simplicity, do this always when something is
unindented.
This fixes https://savannah.gnu.org/bugs/?56102.
Reported-by: Devin Hussey <husseydevin@gmail.com>
Bug existed since around version 2.9.2.
All other options are off by default and can only be switched *on*
(either by a command-line option or a nanorc setting) -- there are
no command-line options to switch them off again. Except for the
--breaklonglines/--nowrap pair. So these need special handling.
This fixes https://savannah.gnu.org/bugs/?56119.
Reported-by: Sébastien Desreux <seb@h-k.fr>
Bug existed since version 4.0, commit 4d40bea5.
When the file starts with one or more blank lines, the first paragraph
doesn't start on line 1.
This fixes https://savannah.gnu.org/bugs/?56117.
Bug existed since version 4.0, commit ac8bd2a2.
It is still possible to use --jumpyscrolling on the command line or
'set jumpyscrolling' in a nanorc file, but a user will have to restart
nano when they decide they want chunky instead of smooth scrolling,
a decision that should be rather rare.
This frees up the M-S keystroke to be reused for toggling softwrap.
The error messages from gnulib need to be included into nano's POT file
so that those messages get translated when nano is built on a platform
where the modules that contain the messages get used.
This fixes https://savannah.gnu.org/bugs/?56107.
Bug existed since gnulib support was added in version 2.8.0.
The relevant modules were added by commits 3deec435 and 272345cc.
For relatively inexperienced users (as most users of nano probably are)
it is far better that nano produces POSIX text files by default, where
each line ends with a newline character. This means that these files
will "print" properly (not gluing the next prompt at the end of the
last line), tools will see and process each line of them, and, while
editing, adding text at the end is easier.
This addresses https://savannah.gnu.org/bugs/?55997.
Reported-by: Ralph Corderoy <ralph@inputplus.co.uk>
Instead of doing a check every time round the loop when it is useful
only the first time, duplicate a bit a code and do the check and its
related action beforehand.
Also, improve some comments.
Also, find_bracket_match() is only called when there is a bracket under
the cursor, so stepping forward will never go beyond the end-of-line,
so the central loop does not need to check for that.
Also, improve a comment and shorten another, change a 'for' to a 'while'
(as the end point is not known), and rename a parameter from a single
letter to a word.
Some of these directives are now colored in their entirety, while for
a few others it's still just the keyword itself that is colored.
Signed-off-by: Liu Hao <lh_mouse@126.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The reading order must be predictable, otherwise things might get
colored differently from system to system.
This fixes https://savannah.gnu.org/bugs/?56012.
Otherwise the user could do something like
^R^X sed -i 's/a/surprise!/g' name-of-current-file <Enter>
and the file being viewed would be modified anyway.
The word "buffer" in relation to undo has been confusing to translators.
Also, drop the exclamation mark, as there is nothing important or urgent
about these messages.
The keystrokes are recognized and acted upon, but they are not visible
in the menu nor in the help text, and they cannot be rebound. They are
there just to avoid frustrating the muscle memory of long-time users.
This fixes https://savannah.gnu.org/bugs/?56002.
Reported-by: Peter Zwegat <peterzwegat@yopmail.com>
Because somehow something goes wrong when SIGWINCHes are handled while
reading from a pipe.
This fixes https://savannah.gnu.org/bugs/?56011.
Bug existed since version 2.4.2, commit 75d64e67.
Some commands can take a little while to execute; showing just the prompt
during that time could give the impression that nothing is happening.
This addresses https://savannah.gnu.org/bugs/?56041.
The lack of initialization caused a nasty bug on some targets (such as
ARMv7) which would make it so that ^S would just say "Cancelled".
While x86 (both 64 and 32 bits) seems to initialize 'response' to zero or
a positive number, ARM does not, and there is usually a negative value in
its place, which triggers the 'if (response < 0)' check and, as a result,
the code says "Cancelled".
This fixes https://savannah.gnu.org/bugs/?56023.
Reported-by: Devin Hussey <husseydevin@gmail.com>
Bug existed since version 4.0, commit 0f9d60a3.
Signed-off-by: Devin Hussey <husseydevin@gmail.com>
When nano was configured with --enable-tiny --enable-speller, the
block_sigwinch() function should be available, to mask SIGWINCHes
during a spell check.
The blocking is needed only during the wait(), so unblock SIGWINCH
again right after the wait() -- also to have the unblocking before
a possible error exit.
Somehow a SIGWINCH pushes nano past the wait() in do_alt_speller(),
even though the external spelling program hasn't finished.
This fixes https://savannah.gnu.org/bugs/?56010
by reverting commit 1f39f60b.
Bug existed since version 3.2.
Also because most of nano has meanwhile been written by other people
than Chris. And because authorship is meta-information, irrelevant
for knowing how to operate nano.
Since commit 4c6ec637 from about half a year ago, the 'action' parameter
of update_undo() is unused. Verify that this parameter matches the type
of the item at the top of the undo stack, so that in another half year
the parameter can be safely removed.
When the mark is off, initialize not just 'bot_x' but also 'top_x'.
This fixes https://savannah.gnu.org/bugs/?55898.
Bug existed since the justifying of a marked region was introduced,
four days ago, with commit f7f5514e.
When there is a dash among the files on the command line, nano will read
data from standard input, which means that the latter is not connected to
a terminal and thus cannot be recognized as a Linux VT until nano has
finished reading the input and has reconnected the input source to the
terminal.
The first probe for a Linux VT is kept in place for now, so that nano
can stop when there are errors in an rcfile while running on a VT.
(This stopping will not work when data is read from standard input,
of course, but that is a smaller fish.)
This fixes https://savannah.gnu.org/bugs/?55912.
Reported-by: Enrico Mioso <mrkiko.rs@gmail.com>
Bug existed since the recognition of modified cursor keys on a Linux
console was introduced, in version 2.6.3, commit 290d278f.
This matches Pico's behavior. However, Pico doesn't add the quoting +
indentation to the line in which the selection ends, but this is wrong,
so nano does add it. Also, Pico doesn't account for partial quoting +
indentation at the start or end of a selection, but this is wrong, so
nano does.
Unlike a regular paragraph, marked text may have different quotes and
more than two types of indentation. Handle this by replacing deviant
quotes with the quote of the first line, and deviant indentation with
the indentation of the second line.
This is modelled after Pico's behavior. However, Pico won't do anything
if you do a full-justify while the mark is on. But this is unnecessarily
limiting, so, when the mark is on, nano will handle a full-justify and a
plain justify the same.
This currently does not handle the lead (quoting + indentation) in
justified selections, does not put mid-line justified selections onto
separate lines, and does not strip whitespace after the lead in justified
selections, the latter two of which Pico does. These behaviors are
forthcoming.
concat_paragraph() concatenates a paragraph into a single line, and
rewrap_paragraph() rewraps that line into multiple lines again.
These two will be needed when the justifying of marked text is added.
Instead of passing 'quote_len' to these functions, calculate it directly
in them.
This will be needed when the justifying of marked text is added. When
unmarked text is justified, it is a single paragraph and by definition
has a uniform quoting part. But marked text may be a jumble of lines
that have different quoting parts.
Option -J (--guidestripe) takes a column number as argument and then
shows a vertical, colored bar over the entire height of the buffer,
to aid the user in regulating the width of the text when the terminal
is wider than this desired width.
This fulfills https://bugs.debian.org/916392.
Requested-by: Arturo Borrero González <arturo@debian.org>
And fulfills https://savannah.gnu.org/bugs/?55315.
Requested-by: Bryan Christ <bryan.christ@gmail.com>
When the right half of a two-column character gets overwritten by the
">" continuation character, then represent its left half as "[" also
when spotlighting a replacement candidate. Achieve this by calling
display_string() in the overshooting case with 'isprompt' set to TRUE,
which also makes this function reserve space for the ">" continuation
character so spotlight() doesn't need to do this any more.
This fixes https://savannah.gnu.org/bugs/?55679.
Improved-by: Benno Schulenberg <bensberg@telfort.nl>
The change in commit edc0d628 was flawed. The old logic covered
every case but one: having reached the end of 'buf' but 'column'
still having overshot the screen width. Now cover this latter
case too.
This fixes https://savannah.gnu.org/bugs/?55638 properly,
allowing the next commit to fix another buglet.
Condensed-by: Benno Schulenberg <bensberg@telfort.nl>
In this way, for single-width characters, one can see what character is
ahead of the cursor before actually moving the cursor to that position,
and, for double-width characters, the cursor never sits on a placeholder
but always shows the character that is actually there.
This addresses https://savannah.gnu.org/bugs/?55716.
In the tiny version the feature toggles are absent, so most of the
Meta-key combinations do nothing, and when --with-slang was used, the
<Ctrl+Left/Right> keystrokes do not work (as they produce truncated
escape sequences under Slang), and the <Ctrl+Space> and <Alt+Space>
keystrokes are awkward to type and make no sense. So... use some
of the free Meta combinations to jump a word to the left or right,
since these functions *are* present in the tiny version.
The reload_positions_if_needed() routine can free the existing
'position_history' and allocate a new one. Using the old one,
from before the reload, could lead to a crash.
This fixes https://savannah.gnu.org/bugs/?55792.
Reported-by: Enrico Mioso <mrkiko.rs@gmail.com>
Bug existed since the reloading of the position-history file was
introduced, a year and a half ago, in commit bfc53f30.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
That is: keep nibbling off characters until a character is eaten that
takes up at least one column.
This fixes https://savannah.gnu.org/bugs/?55759.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Bug existed since version 2.8.0, commit 5283acdc.
On small terminals (80 columns or so), ^S and ^Q would be in
the last position of the help lines. But some terminals might
intercept ^S and stop all output (until ^Q is pressed), which
could be unexpected and frustrating. So, rearrange things for
the tiny version so that ^S appears only on very wide terminals.
Also, having two keystrokes for saving the current buffer
(^O and ^S) in the two help lines is wasteful, more so as
in the tiny version there are no ^G help texts.
So, show the more useful M-Q and M-W instead.
This addresses https://bugs.debian.org/915017.
Reported-by: Steve McIntyre <steve@einval.com>
If these two command-line options would override an rcfile setting of
their counterpart new option, the user might come to expect being able
to do this also in the future. But these old options will be obsoleted
at some moment, so... better start ignoring them right now.
The start-of-paragraph and end-of-paragraph seeking functions are only
vaguely related to searching, and have nothing to do with replacing --
the functions make more sense in the Goto-Line menu.
Also, the Goto-Line menu is much less crowded, so the functions are
more likely to be noticed there. Furthermore, this makes harmless a
typo that I sometimes make: typing ^W again when I've already done so.
Jumping to the first or last line of the buffer doesn't have anything
to do with searching, so these functions shouldn't be present in the
search menus. They make perfect sense in the Goto-Line menu, though.
To make it obvious that they are not actual characters in the file.
The default highlighting is in reverse video, but this can be changed
to bold by using --bold or 'set boldtext'.
This fulfills https://savannah.gnu.org/bugs/?55571.
The angular brackets look a bit like arrows and thus hint much more
at the idea of continuation than a dollar sign.
With-help-from: David Lawrence Ramsey <pooka109@gmail.com>
When the screen's edge leaves just one column for a two-column
character, then show its left half as "[" and its right half as "]".
(They used to be shown as ">" and "<", but these characters will be
repurposed in the next commit.)
This addresses https://savannah.gnu.org/bugs/?55657.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
The get_history_older_void() and get_history_newer_void() functions
are mere names, they don't actually do anything. So... don't bother
to execute them, so the 'finished' variable doesn't have to be reset
after calling them.
Also, normalize the order of those two empty functions.
When doing replacements or fixing misspelled words, and edit_refresh()
is called to highlight the relevant word, then the current menu can be
anything from MREPLACEWITH, MYESNO, MSPELL, or MMAIN. Make sure it is
always set to the latter just before calling edit_refresh(), so that
display_string() will use the full length and the word gets properly
highlighted.
This fixes https://savannah.gnu.org/bugs/?55680.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Bug was introduced by the previous commit, 56181896.
It needs to be trimmed and substituted with a single-width placeholder
to prevent the continuation character ">" from getting pushed to the
next row.
Also, use the correct width for the answer so that the continuation
character is only displayed when the answer does not fit any more.
This fixes https://savannah.gnu.org/bugs/?55620.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Original-patch-by: David Lawrence Ramsey <pooka109@gmail.com>
When a line ends with a two-column character, and this character straddles
the edit window's edge, then, although we've reached the end of 'buf', we
have exceeded the 'beyond' column and this two-column character needs to
be trimmed from the 'converted' string, otherwise it would get printed on
the next row.
This fixes https://savannah.gnu.org/bugs/?55638.
Bug existed since version 2.8.0, commit 5283acdc.
Also, enable smooth scrolling by default, and don't waste the row
directly below the title bar. The use of the latter also serves
as a small visual reminder that this nano is different.
This addresses https://savannah.gnu.org/bugs/?55067.
This signals our break from trying to be as compatible with Pico as
possible. We were already incompatible with modern Pico in the -n
and -W options, and in several character-set and color options, so
ignoring those five options brought us very little.
Anyway, soon some of those options will be reused and will have the
effect of making nano look and behave more like Pico.
Using the cursor keys for movement-related functions makes more sense
than using them for jumping to the previous or next occurrence of the
search string.
(For searching another occurrence backward the M-Q binding has become
available, while M-W will search another occurrence always forward.)
Now also comment blocks in Fortran, Lisp, Lua, Postgres, and TeX
can be rewrapped with ^J.
This partially addresses https://savannah.gnu.org/bugs/?55435.
Kind-of-requested-by: David Griffith <dave@661.org>
After a series of escapes, also <Shift+Meta+letter> should be recognized
as a command keystroke, not just <Meta+letter>.
This fixes https://savannah.gnu.org/bugs/?55442.
Bug existed since the ignoring of <Escape>s before a valid command
keystroke was introduced in version 3.0, commit ecc9211a.
When the user switches backups on later (with M-B in the ^O menu),
the specified folder should have been checked for validity.
This fixes https://savannah.gnu.org/bugs/?55423.
Bug existed since the check for a valid backup directory was introduced
in version 2.8.7, commit 751e7f0f.
The reduced file size should be stored not just when joining two lines
but also when simply a character in the middle of a line is deleted.
This fixes https://savannah.gnu.org/bugs/?55352.
Bug existed since version 2.5.0, commit 66e21416.
All tested systems (FreeBSD, NetBSD, OpenBSD, Alpine, and Ubuntu)
support the GNU-style word boundaries (\< and \>), either natively
or through using the regex module from gnulib.
If this change breaks regexes containing \< or \> on your system,
please report a bug: https://savannah.gnu.org/bugs/?group=nano
This addresses https://savannah.gnu.org/bugs/?55207.
Reuse the WAS_FINAL_LINE flag to signal a cut that added a magicline,
for both a marked cut and cut-to-eof.
This fixes https://savannah.gnu.org/bugs/?55305.
It's not just about the numeric keypad, but about the interpretation
of all editing keys (arrows, Home, End, PageUp, PageDown, Insert, and
Delete), of the escape sequences that they produce.
When using --raw, ncurses does not catch and convert any mouse event,
and thus the coordinates of a mouse click would get inserted into the
buffer as seemingly random characters. So, let --rawsequences override
and disable --mouse, to prevent the accidental entering of junk.
This fixes https://savannah.gnu.org/bugs/?55303.
To better describe what it does, and to have full contrast with the
--rebinddelete option: the latter can now be shortened to --rebind
without getting a conflict, and --rawsequences can be abbreviated
to simply --raw and still make sense.
When the terminfo selected by TERM does not match the terminal and
the <Delete> key behaves the same as <Backspace> (deleting leftward)
or the <Backspace> key behaves the same as <Delete> (deleting without
moving the cursor), then using just -d or --rebinddelete should make
the deviant key behave correctly again without affecting the other.
ASCII code BS should always do a backspace, also on systems where the
"^H" string gets redirected (for rebinding purposes) to KEY_BACKSPACE.
This fixes https://savannah.gnu.org/bugs/?55247.
Reported-by: Norton Warner <nortonwarner@gmail.com>
When not unbinding it from its earlier function (in the same menu),
it would result in showing the keystroke twice in the help text.
This fixes https://savannah.gnu.org/bugs/?55239.
Bug was introduced a month ago, by commit f81d174f.
The direct call was a leftover of the old unjustify mechanism.
Also, move two statements to the end of the do_justify() routine,
since that is their place in comparable routines.
Suggested-by: David Lawrence Ramsey <pooka109@gmail.com>
When multiple buffers are open, the edit window says "Close" for ^X
instead of "Exit" (when one buffer is open). In the help viewer ^X
says "Close". Apparently the idea is that ^X should say "Exit" only
when pressing ^X leads to exiting from nano. Pressing ^X in the file
browser does not exit from nano, so make it say "Close" instead.
(The help viewer says "Close" since version 2.8.6, commit 934a2192.)
When using --preserve, ^S and ^Q are "eaten" by the terminal and
do not reach nano: they have no effect in nano, so the help lines
and the help texts should not mention these shortcuts.
Also, to keep the help lines in the help viewer neatly arranged,
^L is not bound there when --preserve is used.
Not stepping beyond the last line of the paragraph means that the
length of the paragraph is always the difference in line numbers
(between first and last line of the paragraph) plus one.
When leaving the mark on while justifying and then undoing the
justification, things are likely to get messed up. My applying
David's patches only partially caused this breakage.
This fixes https://savannah.gnu.org/bugs/?55074.
Only the first search for a paragraph needs to check whether we're
currently in the middle of a paragraph. When the 'while' loop for
a full justify is executed, all calls of find_paragraph() start
either on the first line of a paragraph or between two paragraphs.
To find a paragraph, what needs to be done is:
a) When not in a paragraph, move forward until we find one, if any.
b) When in a paragraph but not at its start, move back to its start.
c) Move forward to the end of the paragraph, if any.
When, in the 'while' loop for a full justify, 'filebot_inpar' becomes
TRUE, it means that EOF has been reached and find_paragraph() should
not be called again. To allow 'filebot_inpar' to convey this meaning,
it should not be set to TRUE elsewhere, so another boolean is needed
for setting the correct length of the final line of the cutbuffer.
This fixes https://savannah.gnu.org/bugs/?55086.
The removal of the x-coordinate handling affected this. Reshuffle things
so that we can check for it after we have moved (the same way we check for
it at the beginning of the function before we move) without having to set
'quote_len' and 'par_len' unnecessarily.
Also, adjust some comments accordingly.
Move detecting the final line of the paragraph to find_paragraph(),
since a paragraph of which the final line is the last line of the
buffer will still be that way after being justified.
Also, move all x-coordinate handling to do_justify(), since it only
applies to the current buffer.
Move a few references to the current buffer to do_justify(). Also,
the check for being at the end of the buffer needs to be done after the
first paragraph is found, so that the existing behavior of finding an
initial paragraph regardless of cursor position is preserved.
The functions do_para_begin() and do_para_end() can now move through any
buffer, while the functions do_para_begin_void() and do_para_end_void()
operate on the current buffer. The latter function also returns TRUE
if the last line in the buffer is part of the paragraph.
Remove the handling of 'edittop', 'totsize', and the mark, to make the
function more general, which is needed to make it undoable eventually.
This breaks the function somewhat. Fixes for this are forthcoming.
The function assumes that it works on the current buffer by handling
'totsize' and the mark. Remove this handling to make the function
more general, which is needed to make it undoable eventually.
This breaks the function somewhat. Fixes for this are forthcoming.
The new binding will be put at the head of the list and thus will
be the one that is found -- the old binding will never be seen, so
rubbing it out is just a waste of time.
Further down, the <Backspace> key is bound to do_page_up() for MHELP
and MBROWSER, so this earlier binding should exclude MBROWSER.
This partially fixes https://savannah.gnu.org/bugs/?54978.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Bug existed since version 2.9.2, commit 8581e702.
Set the Meta flag only for the regular Meta keystrokes: "M-" plus a
printable ASCII character. The special keycodes are unique and do
not need any extra flags to differentiate them.
This works for xterm, rxvt, Eterm, Konsole, and xfce4-terminal, which
generate "Esc [ 3 ; 3 ~", but not for urxvt, which generates one of
its double-escape sequences, "Esc Esc [ 3 ~".
Using --zap or -Z on the command line, or 'set zap' in a nanorc file,
makes the <Bsp> and <Del> keys erase selected text (a marked region)
as they do in some other editors, and without affecting the cutbuffer.
This fulfills https://savannah.gnu.org/bugs/?54837.
Requested-by: Liu Hao <lh_mouse@126.com>
Signed-off-by: Brand Huntsman <alpha@qzx.com>
This function allows the user to "make space": annihilating lines or
regions while keeping intact for pasting the stuff in the cutbuffer
that was cut or copied earlier.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
Return immediately to editing mode when there are no messages for
the original file and the user does not wish to open any of the
included files that do have messages.
Also, reword the message that the linter gives then, and leave it
on the status bar (just like when Cancel is pressed).
The bindings for F1 to F12 are there for compatibility with Pico.
But Pico does not know anything about F13 to F16; for unknown reasons
they were added to nano. They seem hardly useful: normal keyboards
do not have the F13 to F16 keys, and very few people know that they
can "produce" those keys by holding Shift with F1 to F4. But typing
Shift plus F1 to F4 are just as "hard" as, for example, M-G and M-W,
so why anyone would want to use the first ones...? Especially since
many other functions of nano can only be accessed through Meta and
Control combinations.
Furthermore, F13 to F15 haven't been shown in the help texts since
version 2.3.3, so for more than four years no new user will have
learned about those keystrokes.
The rare user who wants these strange bindings can easily make them
herself.
The help lines will help differentiate this mode from normal editing
mode, and will tell the user how to jump to other messages.
This is a third step to address https://savannah.gnu.org/bugs/?54714.
When --view is used without --ignorercfiles, the user could view
other files anyway if they had 'set multibuffer' in their nanorc.
So, just make this the default when --view is used, also because
"multibuffer" cannot be toggled once nano is running in view mode.
When the viewing of other files in view mode should not be allowed,
one should now additionally use --restricted.
The 'wrap_at' variable, removed in commit e90b7cf4, is actually needed
to store the original value of the --fill option when it is negative.
Otherwise, changing the screen width will not update the wrapping point
properly.
This fixes https://savannah.gnu.org/bugs/?54861.
Reported-by: Brand Huntsman <alpha@qzx.com>
The ^P and ^N keystrokes for Older and Newer are relevant to searching
and should be visible in the help lines. FullJustify, paragraph jumps,
and top/tail jumping are there only for compatibility with Pico but
don't make any sense there, so it's no problem if they are pushed out
of view.
Rename not only the bindable functions, but more importantly reword the
tags that are shown for ^P and ^N in the help lines: "Older" / "Newer",
because these are clearer and not awkward abbreviations.
When using --view --multibuffer --restricted, it is the latter option
that forbids reading in another file, so that is what the status bar
should say.
This fixes https://savannah.gnu.org/bugs/?54824.
Bug existed since version 2.9.5, commit 8b8c6bb8.
When something is spotlighted, it should survive a refresh of
the screen and an excursion to a help text, so the spotlight
should get painted whenever the edit window is drawn.
This fully fixes https://savannah.gnu.org/bugs/?54721.
It would result in having both <Delete> and <Backspace> behaving as
Backspace, which seems senseless -- unless the <Delete> key produces
ASCII DEL and --rebinddelete is needed to make it behave as Delete.
In the latter case it would make more sense if --rebinddelete made
both rebindings: ASCII DEL to Delete and KEY_DC to Backspace, like
it used to be in the distant past, before commit 79a33bb3.
Ask ncurses for the codes for the Shift+arrow keys, so that also
<Shift+Up> and <Shift+Down> can be recognized, for which ncurses
doesn't have standard codes.
This fixes https://savannah.gnu.org/bugs/?54790.
Reported-by: Javier Valencia <javiervalencia80@gmail.com>
Move the unsetting of some options further down, to prevent the user's
nanorc enabling things that are not permitted in restricted mode.
Also, in restricted mode, suppress error messages about functions not
being present in the requested menus, so that a nanorc that is valid in
normal mode does not cause unnecessary messages when using --restricted.
This fulfills https://savannah.gnu.org/bugs/?54732.
Requested-by: Mark Webb-Johnson <mark@webb-johnson.net>
The new function, justify_paragraph(), takes a quote length and a
paragraph length (which it should get from find_paragraph()), and
runs the paragraph at (current, current_x) through justify_format().
Move some fragments out of the justifying loop, and adjust/clarify comments
to account for the changes. This will allow some of the code to be cleaned
up and simplified in the next commits.
This allows running the speller (default binding: ^T) also on files for
which a linter has been defined. This makes it possible to spell check
comment blocks in source files, for example.
This fulfills https://savannah.gnu.org/bugs/?54711.
Requested-by: Mike Frysinger <vapier@gentoo.org>
Only for BACK and DEL was the first call to update_undo() -- all other
types of action would call add_undo() first, so for them the action in
update_undo() would never be different, but the line number might have
changed (like for ENTER and INSERT), so for them exceptions needed to
be made, which was wasteful.
This addresses https://savannah.gnu.org/bugs/?54728.
The binding was made only to have *something* bound by default to the
'cutwordleft' function. But now that <Ctrl+Shift+Delete> is available
*and* visible in the help text, the M-| binding is superfluous.
When using the internal spell checker, the message gets overwritten
immediately by "Creating misspelled word list...", and when using
the external spell checker, nano immediately exits from curses mode
and thus the message disappears (when in a terminal emulator) or it
soon gets wiped by the spell checker (when on a Linux console), thus
creating a little flash on the bottom row, which we can do without.
In the past, SIGWINCHes were responded to immediately (which was madness),
but since commit 75d64e67 all a SIGWINCH does is set a flag so that, when
the time comes to update the screen, nano knows the dimensions may have
changed. The mentioned commit removed most blockings and unblockings of
SIGWINCH, but not this one.
Assume that 'print' and 'exec' are statements when they are followed
by whitespace, and are functions otherwise. This does not highlight
"print'x'" nor "print{x}", but these statements are poor style.
Signed-off-by: Benjamin Mintz <bmintz@protonmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
So that the user can do 'bind ^H cutwordleft all' in their nanorc
to make ^H (and sometimes also <Ctrl+Backspace>) delete the word
to the left of the cursor while <Backspace> continues to delete
just one character.
As the statusbar() function will write the position directly to the
terminal when not in curses mode, the final part of this position
message will seem to be after the prompt when exiting from nano.
The cursor position will get written correctly to the status bar
anyway, because returning from suspension enters a fake key into
the keyboard buffer, and this key elicits an update of the display.
This fixes https://savannah.gnu.org/bugs/?54639.
Reported-by: Lauri Kasanen <cand@gmx.com>
Bug existed since version 2.4.2, commit 75d64e67.
Most of these toggles just change the appearance of things, and
all of them are harmless -- none of them modify the contents of
the buffer.
This fixes https://savannah.gnu.org/bugs/?54650.
Reported-by: Liu Hao <lh_mouse@126.com>
Bug existed since version 2.9.4, commit 54103d8e.
(The offending commit meant in the previous commit was 60f1090d.
My mistake.)
When curses gives no code for Ctrl+Shift+Delete, do not fall back
to KEY_BACKSPACE, because then ^H and/or <Backspace> get bound to
'cutwordleft'.
This fixes https://savannah.gnu.org/bugs/?54642.
Bug was introduced with version 3.0, commit e6429e78.
That is, wait with deleting words until they start under cursor,
so the user can see which word is goin to be eaten, and join lines
only when the cursor already sits at the edge of a line.
On FreeBSD and NetBSD (when reached through ssh from a Linux machine)
this has the absurd effect of making <Ctrl+Backspace> do a 'cutwordleft'
by default, out of the box, without needing any rebindings. Weird, but
wonderful, because the ideal behavior.
Also ensure that <Shift+Delete> always does a Backspace.
This makes that we have the following set of "congruent" keys:
<Tab> moves text to the right,
<Shift+Tab> moves text to the left,
<Delete> "eats" a character to the right,
<Shift+Delete> "eats" a character to the left,
<Ctrl+Delete> "eats" a word to the right,
<Shift+Ctrl+Delete> "eats" a word to the left.
Also, don't partially color "..." as an operator, because it isn't,
and color also the unary operator "#".
Signed-off-by: Mark-Weston <markweston@cock.li>
Adding "[abc]*" does not restrict the recognized header line in any way.
Also, improve the header-line regex for shell scripts, because it should
not match "barunscript" (for example).
If find_paragraph() detects that we're not in a paragraph, it moves
forward a paragraph and then backward to that paragraph's beginning.
Make it check whether we're in a paragraph before moving backward
(since there might not *be* any more paragraphs), to prevent going
forth-and-back and never reaching the end of the buffer.
This fixes https://savannah.gnu.org/bugs/?54573.
These are available in the menus where they are relevant: the Write-Out
and the Insert menu, respectively. Having them duplicated in the main
menu is inconsistent and eats precious keystrokes. (Sorry, Chris.)
When 'inhelp' is true, there are at least two buffers open: an
edit buffer and the help-text buffer.
And bottombars() already does a full refresh of the bottom window.
And restore the cursor to this position when redoing the cut+insert.
Also remove two unneeded conditions.
This fully fixes https://savannah.gnu.org/bugs/?54466.
When piping the buffer (or the marked region) to an external command,
we should wait not only for the external command to terminate but also
for the data-sending process, so that it will release its resources.
This fixes https://savannah.gnu.org/bugs/?54499.
With-help-from: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
When undoing/redoing an alternate spell check (of the entire file
or of a backwards marked region), put the cursor back where it was
when the spell check was invoked/finished.
This fixes https://savannah.gnu.org/bugs/?54466.
On a Linux VT, refuse to start when there are errors in a nanorc file,
so that the messages no longer get overwritten -- which prevented the
user from seeing and reading them.
This fixes https://savannah.gnu.org/bugs/?54442.
Since the last version, the user can filter an entire buffer through
an external command. This external command can also be a formatting
program, so there is no longer any need for this specific and special
formatter command.
(In the Search and Replace menus Cancel is not essential. And in the
Goto Line menu Cancel is not needed at all: a simple <Enter> after an
empty answer works fine.)
This fixes the second part of https://savannah.gnu.org/bugs/?54447.
There are at least three other ways to achieve the thing that it did:
^End, M-/, and ^W^V. No need to have a fourth way by default.
For symmetry, also unassign the corresponding binding for M-|.
The 'cutwordright' function has gotten ^Delete as its default binding,
so the 'cutwordleft' function needs a default binding too -- also to
keep the items on the two help lines nicely paired. M-| was chosen
because it is close to the Backspace key on many keyboard layouts.
Print routines are not asynchronous-safe.
But... the only reason the call of kill() could return an error code
is when the relevant process has already terminated -- which is not
a problem, because that was the goal of calling kill().
This fixes https://savannah.gnu.org/bugs/?54409.
Reported-by: Daniel Kozovsky <dkozovsk@redhat.com>
As the help viewer is almost a normal buffer, commands that make sense
-- like searching backwards, and searching the previous occurrence --
should work in the help viewer too.
In addition, show all Search commands prominently in the help lines of
the help viewer, so that users are likely to notice them and will maybe
infer that they work in the editor itself too.
This fixes https://savannah.gnu.org/bugs/?54368.
With-help-from: David Lawrence Ramsey <pooka109@gmail.com>
Put "Where Was" in its place, to make the symmetry of ^W/M-W/^Q/M-Q
somewhat clearer. Also, conditionally reshuffle "Save File", to try
and keep menu items nicely paired.
Bind the until-now unbound function 'cutwordright' to <Ctrl+Delete>.
The complementary function, 'cutwordleft', is not bound by default
because on many terminals the keystroke <Ctrl+Backspace> generates
^H -- the canonical ASCII backspace character. We cannot change the
existing action of ^H without upsetting some users.
Signed-off-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
To match the documentation and to match what the nanorc.nanorc
colors as valid.
In theory it would be possible to allow rebinding also F17...F63,
but nano does not recognize escape sequences for these high-order
function keys. As no one ever complained about unknown sequences
when pressing function keys, I am guessing that no one has these
high-order keys, or at least that no one uses them.
This fixes https://savannah.gnu.org/bugs/?54332.
Instead of being entirely silent when ^] is hit after whitespace
or punctuation, report what is lacking -- similar to M-] saying
"Not a bracket" when the cursor is not sitting on a bracket.
This makes the ^] keystroke more discoverable.
This makes things symmetrical: ^W starts a forward search, ^Q starts
a backward search, M-W searches the next occurrence forward, and M-Q
searches the next occurrence backward.
The Tabs-To-Spaces toggle is moved to M-O, and thus the More-Space
toggle is no longer bound by default.
When using option -K on an xterm-like terminal, pressing <Shift+Del>,
<Alt+Del>, or <Ctrl+Del> would enter "2~", "3~", or "5~", respectively,
into the buffer. Now it will just report an "Unknown sequence".
The crawl needs at least five rows to be perceived as a crawl, and
the widest line is 31 characters (ignoring translations, which might
be even longer). Formerly, when only two or three rows were available,
nothing was shown at all, which was puzzling. So, better do the credits
only when there is room enough for them, and print a message otherwise.
When switching to a different buffer, don't just show its name but
also the number of lines it contains. This is useful extra info.
Then use this same message when at startup multiple files are opened
and (after reading them all) we switch back to the first buffer.
(This loses, when multiple files are opened, the information about
format conversion that nano still shows when a single file is opened,
but... this bug has shown that people don't really look at this line
anyway, so... let it be. The info can still be seen when writing out
the file with ^O.)
This addresses https://savannah.gnu.org/bugs/?54047.
Just like an <Esc> before a Ctrl+letter keystroke is ignored, an <Esc>
before an Alt+letter keystroke should be ignored too -- it should not
be interpreted as if the user had typed <Esc> <Esc> letter.
This fixes https://savannah.gnu.org/bugs/?54301.
Even when we don't act on most of these combinations, at least eat up
the whole sequence so the unknown keystroke doesn't enter things like
"3~" into the buffer.
This fixes https://savannah.gnu.org/bugs/?54291.
Unlike glibc, which in getc() locks the file only when it is needed,
FreeBSD and Bionic libc will always lock the file, causing a massive
slowdown, as the system has to create and destroy a mutex each time
getc() is called.
Avoid that massive overhead by locking the file before starting to read
and unlocking it after reading is complete, and using getc_unlocked() to
read each byte. This makes reading on FreeBSD/macOS and Android anywhere
from 2 to 6 times faster, and on glibc roughly seventy percent faster.
This partially addresses https://savannah.gnu.org/bugs/?50406.
Signed-off-by: Devin Hussey <husseydevin@gmail.com>
Also, consistently refer to Latin letters and ASCII characters
where needed, and document more accepted characters.
This addresses https://savannah.gnu.org/bugs/?54071.
The 'statusbar_x' variable does not refer to a position in the status
bar, but to a position in the answer that is currently being typed at
the prompt. So... let's call it 'typing_x', for lots of contrast.
The Alt key together with Shift is a special workaround for when
Shift+PgUp and Shift+PgDn don't work on the user's terminal. But
probably it is more common to use the Ctrl key together with Shift
to select larger pieces of text. So mention this possibility.
And in the bargain get rid of some duplicate code.
This makes a binary without UTF-8 support slightly slower, but that's
not important -- it is more than fast enough anyway. Important is that
the most used and longest code path, the UTF-8 case, becomes faster.
Note that 'is_cntrl_mbchar()' will fall back to 'is_cntrl_char()' for
a non-UTF-8 build, so the deleted piece of code really was equivalent
with the remaining piece for that case.
Take our cue from undoing/redoing line joins: when they take place on
the magicline without --nonewlines, they produce undo/redo items that
don't do anything to the text, but still position the cursor properly.
Reshuffle a bit of code so that we can do the same for magicline cuts.
This fixes https://savannah.gnu.org/bugs/?54032.
Again, if the most significant bit of a UTF-8 byte is zero, it means
the character is a single byte and we can skip the call of mblen(),
*and* if the character is one byte it also occupies just one column,
because all ASCII characters are single-column characters -- apart
from control codes.
This partially addresses https://savannah.gnu.org/bugs/?51491.
For UTF-8, if the most significant bit of a byte is zero, it means the
character is just a single byte and we can skip the call of mblen().
For files consisting of pure ASCII bytes (between 0x00 and 0x7F), this
change reduces the counting time of mbstrlen() by ninety six percent.
This partially addresses https://savannah.gnu.org/bugs/?50406.
When mbtowc() is never called with anything less than MAXCHARLEN as
the length parameter, it will apparently not get confused and will
not need to be reset.
The variable 'last_action' is set at the end of these functions,
serving to prevent a fresh action from being merged with an older
action further down on the stack. Setting 'last_action' before
exiting from undo()/redo() makes no sense.
Also adjust a sideways related old Changelog item.
The macro stuff, however, is basically my code: I told him exactly
how to do it, and I changed most of the patch before applying it.
Also, put myself in second place, as I've just about overtaken David
in the duration of maintainership.
Otherwise the first line of a multiline /*...*/-comment would be
seen as quoted and thus *not* as the first line of a paragraph.
In the code, use "/{2}" to prevent the remainder of the line
getting colored as a comment.
The paragraph-aware indenting is needed only when automatic long-line
wrapping is on (that is, when not using 'nowrap': when writing prose).
When writing code, the user most likely uses --nowrap, which will make
nano indent a new line always to the same amount as the preceding line
-- when --autoindent is in effect, of course.
The only time that feedback about the number of lines written is *not*
wanted is when writing a temporary file.
This fixes https://savannah.gnu.org/bugs/?54025.
Plus one that automake recognizes: if. Color them only at the start
of a line. Also color all possible assignment sequences (surrounded
by spaces to not color the ones in shell fragments), and add some
comments.
When doing autoindentation, and the next line is not the start of
a new paragraph, then use the indentation of that line for the new
line, as it is more likely to have the desired indentation -- the
current line might be the start of the paragraph and thus could
have a deviant indentation.
Pico wraps at the last blank character before or on the target column;
if there is no such blank, then it will wrap at the first blank *after*
the target column -- when it can wrap, it will wrap. Nano should do
the same (and judging from the comments, it intended to do the same),
instead of turning the paragraph into a single unwrapped line.
This fixes https://savannah.gnu.org/bugs/?53986.
First step to the next buffer, and then iterate until we either
find a match or are back at the buffer where we started.
This fixes https://savannah.gnu.org/bugs/?53970.
Signed-off-by: Marco Diego Aurélio Mesquita <address@hidden>
The two help lines will be redrawn in main() only when the current
menu is not MMAIN. So, set it to MLINTER as soon as the help lines
are cleared, just before preparing to invoke the linter.
This fixes https://savannah.gnu.org/bugs/?53967.
Reported-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
Recognize not just "Makefile" but also "makefile" and "GNUmakefile".
And recognize these only when they are the full filenames, not when
they are the tail part of a longer name.
Signed-off-by: Cristian Caloghera <cristi.caloghera@gmail.com>
When executing a command in the current buffer and piping this buffer
(or marked region) to that command, then the cutting of the existing
text and the insertion of the new text should be undone and redone
together, as to the user they appear as a single operation.
With-help-from: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
In the past, the argument could be either a regex or a literal string,
so the wording was kind of vague. But nowadays we can count on having
regex support (through gnulib), so be more precise in the description.
Since version 2.8.0, nano will use (wnen needed) the regex routines
from gnulib, so mentioning the quotestr for when regex support is
lacking, has been obsolete and pointless for more than a year.
Also, remove some superfluous backslashes, use a non-breaking space
in the texinfo document, and order the regex consistently.
<ahref="#3.1">3.1. How do I install the RPM or DEB package?</a><br>
<ahref="#3.2">3.2. Compiling from source: WHAT THE HECK DO I DO NOW?</a><br>
<ahref="#3.3">3.3. Why does everything go into /usr/local?</a><br>
<ahref="#3.5">3.5. nano should automatically run strip on the binary when installing it!</a><br>
<ahref="#3.6">3.6. How can I make the executable smaller? This is too bloated!</a><br>
<ahref="#3.7">3.7. Tell me more about this multibuffer stuff!</a><br>
<ahref="#3.8">3.8. Tell me more about this verbatim input stuff!</a><br>
<ahref="#3.9a">3.9a. How do I make a .nanorc file that nano will read when I start it?</a><br>
<ahref="#3.9b">3.9b. How about in Win32?</a>
<ahref="#3.4">3.4. nano should automatically run strip on the binary when installing it!</a><br>
<ahref="#3.5">3.5. How can I make the executable smaller? This is too bloated!</a><br>
<ahref="#3.6">3.6. Tell me more about this multibuffer stuff!</a><br>
<ahref="#3.7">3.7. Tell me more about this verbatim input stuff!</a><br>
<ahref="#3.8">3.8. How do I make a .nanorc file that nano will read when I start it?</a><br>
<ahref="#3.9">3.9. Why does my self-compiled nano not read /etc/nanorc?</a><br>
</p></blockquote>
<h3><ahref="#4">4. Running</a></h3>
<blockquote><p>
<ahref="#4.1">4.1. How do I open a file with a name beginning with '+' from the command line?</a><br>
<ahref="#4.2">4.2. Ack! My Backspace/Delete/Enter/Meta/double bucky key doesn't seem to work! What can I do?</a><br>
<ahref="#4.3">4.3. Ack! My numeric keypad's keys don't work properly when NumLock is off! What can I do?</a><br>
<ahref="#4.4">4.4. Ack! When I hold down a Meta key combination for a while, the character of the held key gets inserted now and then. What gives?</a><br>
<ahref="#4.5">4.5. How do I type the F13-F16 keys listed in the help viewer? My keyboard only has F1-F12!</a><br>
<ahref="#4.6">4.6. nano crashes when I type <insert keystrokes here>!</a><br>
<ahref="#4.7">4.7. nano crashes when I resize my window. How can I fix that?</a><br>
<ahref="#4.8a">4.8a. With what keystroke can I paste text from the clipboard into nano?</a><br>
<ahref="#4.8b">4.8b. When I paste text into a document, each line gets indented further than the last. Why? And how can I stop this?</a><br>
<ahref="#4.8c">4.8c. When I paste from Windows into a remote nano, nano rewraps the lines. What gives?<a><br>
<ahref="#4.9">4.9. I've compiled nano with color support, but I don't see any color when I run it!</a><br>
<ahref="#4.10">4.10. How do I make nano my default editor (in Pine, mutt, etc.)?</a><br>
<ahref="#4.11">4.11. How do I select text for or paste text from the clipboard in an X terminal when I'm running nano in one and nano's mouse support is turned on?</a><br>
<ahref="#4.12">4.12. On startup I get a message that says "Detected a legacy nano history file". Now older nano versions can't find my search history!</a>
<ahref="#4.4">4.4. With what keystroke can I paste text from the clipboard into nano?</a><br>
<ahref="#4.5">4.5. How do I select text for or paste text from the clipboard when nano's mouse support is turned on?</a><br>
<ahref="#4.6">4.6. When I paste text into a document, each line gets indented further than the last. Why? And how can I stop this?</a><br>
<ahref="#4.7">4.7. When I paste from Windows into a remote nano, nano rewraps the lines. What gives?<a><br>
<ahref="#4.8">4.8. I've compiled nano with color support, but I don't see any color when I run it!</a><br>
<ahref="#4.9">4.9. How do I make nano my default editor (in Pine, mutt, etc.)?</a><br>
</p></blockquote>
<h3><ahref="#5">5. Internationalization</a></h3>
<blockquote><p>
@@ -77,13 +75,13 @@
<h1><aname="1"></a>1. General</h1>
<h3><aname="1.1"></a>1.1. What is GNU nano?</h3>
<blockquote><p>GNU nano is designed to be a free replacement for the Pico text editor, part of the Pine email suite from <ahref="http://www.washington.edu/pine/">The University of Washington</a>. It aims to "emulate Pico as closely as possible and then include extra functionality".</p></blockquote>
<blockquote><p>GNU nano was designed to be a free replacement for the Pico text editor, part of the Pine email suite from <ahref="http://www.washington.edu/pine/">The University of Washington</a>. It aimed to "emulate Pico as closely as is reasonable and then include extra functionality".</p></blockquote>
<h3><aname="1.2"></a>1.2. What is the history behind nano?</h3>
<blockquote><p>Funny you should ask!</p>
<p><b>In the beginning...</b></p>
<p>For years Pine was THE program used to read email on a Unix system. The Pico text editor is the portion of the program one would use to compose his or her mail messages. Many beginners to Unix flocked to Pico and Pine because of their well organized, easy to use interfaces. With the proliferation of GNU/Linux in the mid to late 90's, many University students became intimately familiar with the strengths (and weaknesses) of Pine and Pico.</p>
<p><b>Then came Debian...</b></p>
<p>The <ahref="http://www.debian.org/">Debian GNU/Linux</a> distribution, known for its strict standards in distributing truly "free" software (i.e. software with no restrictions on redistribution), would not include a binary package for Pine or Pico. Many people had a serious dilemma: they loved these programs, but the versions available at the time were not truly free software in the <ahref="http://www.gnu.org/philosophy/free-sw.html">GNU</a> sense of the word.</p>
<p>The <ahref="https://www.debian.org/">Debian GNU/Linux</a> distribution, known for its strict standards in distributing truly "free" software (i.e. software with no restrictions on redistribution), would not include a binary package for Pine or Pico. Many people had a serious dilemma: they loved these programs, but the versions available at the time were not truly free software in the <ahref="https://www.gnu.org/philosophy/free-sw.html">GNU</a> sense of the word.</p>
<p><b>The event...</b></p>
<p>It was in late 1999 when Chris Allegretta (our hero) was yet again complaining to himself about the less-than-perfect license Pico was distributed under, the 1000 makefiles that came with it and how just a few small improvements could make it the Best Editor in the World (TM). Having been a convert from Slackware to Debian, he missed having a simple binary package that included Pine and Pico, and had grown tired of downloading them himself.</p>
<p>Finally something snapped inside and Chris coded and hacked like a madman for many hours straight one weekend to make a (barely usable) Pico clone, at the time called TIP (Tip Isn't Pico). The program could not be invoked without a filename, could not save files, had no help text display, spell checker, and so forth. But over time it improved, and with the help of a few great coders it matured to the (hopefully) stable state it is in today.</p>
@@ -91,7 +89,7 @@
<h3><aname="1.3"></a>1.3. Why the name change from TIP?</h3>
<blockquote><p>On January 10, 2000, TIP was officially renamed to nano because of a namespace conflict with another program called 'tip'. The original 'tip' program "establishes a full duplex terminal connection to a remote host", and was included with many older Unix systems (and newer ones like Solaris). The conflict was not noticed at first because there is no 'tip' utility included with most GNU/Linux distributions (where nano was developed).</p></blockquote>
<h3><aname="1.4"></a>1.4. What is the current version of nano?</h3>
<blockquote><p>The current version of nano <i>should</i> be <b>2.9.7</b>. Of course, you should always check the <ahref="https://nano-editor.org/">nano homepage</a> to see what the latest and greatest version is.</p></blockquote>
<blockquote><p>The current version of nano <i>should</i> be <b>5.0</b>. Of course, you should always check the <ahref="https://nano-editor.org/">nano homepage</a> to see what the latest and greatest version is.</p></blockquote>
<h3><aname="1.5"></a>1.5. I want to read the man page without having to download the program!</h3>
<p>You can also have a look at the <ahref="ftp://ftp.debian.org/debian/pool/main/n/nano/">Package Pool</a> to see all the available binary and source packages.</p>
<p>You can also have a look at the <ahref="http://ftp.debian.org/debian/pool/main/n/nano/">Package Pool</a> to see all the available binary and source packages.</p>
</blockquote>
<h3><aname="2.4"></a>2.4. By GIT (for the brave).</h3>
<blockquote><p>For the 'bleeding edge' current version of nano, you can use GIT to download the current source code. <b>Note:</b> believe it or not, by downloading code that has not yet stabilized into an official release, there could quite possibly be bugs, in fact the code may not even compile! Anyway, see <ahref="http://git.savannah.gnu.org/cgit/nano.git/tree/README.GIT">the nano GIT document</a> for info on anonymous GIT access to the nano source.</p></blockquote>
@@ -126,23 +124,23 @@
<h1><aname="3"></a>3. Installation and Configuration</h1>
<h3><aname="3.1"></a>3.1. How do I install the RPM or DEB package?</h3>
<blockquote><p>It's simple really! As root, type <b>rpm -Uvh nano-x.y.z-1.i386.rpm</b> if you have a RedHat-ish system or <b>dpkg -i nano_x.y.z-1.deb</b> if you have a Debian-ish system, where <b>x.y.z</b> is the release of nano. There are other programs to install packages, and if you wish to use those, knock yourself out.</p></blockquote>
<blockquote><p>It's simple really! As root, type <b>rpm -Uvh nano-x.y-1*.rpm</b> if you have a RedHat-ish system or <b>dpkg -i nano_x.y-1*.deb</b> if you have a Debian-ish system, where <b>x.y</b> is the version number of nano. There are other programs to install packages, and if you wish to use those, knock yourself out.</p></blockquote>
<h3><aname="3.2"></a>3.2. Compiling from source: WHAT THE HECK DO I DO NOW?</h3>
<blockquote><p>Okay, take a deep breath, this really isn't hard. Unpack the nano source with a command like:</p>
<p><b>tar -xvf nano-x.y.z.tar.gz</b></p>
<p><b>tar -xvf nano-x.y.tar.gz</b></p>
<p>Then you need to run <b>configure</b> with any options you might want (if any).</p>
<p>The average case is this:</p>
<p><b>cd nano-x.y.z/</b><br>
<p><b>cd nano-x.y/</b><br>
<b>./configure</b><br>
<b>make</b><br>
<b>make install</b> (as root, of course)</p></blockquote>
<h3><aname="3.3"></a>3.3. Why does everything go into /usr/local?</h3>
<blockquote><p>Well, that's what the <b>configure</b> script defaults to. If you wish to change this, simply do this:</p>
<p><b>./configure --prefix=/usr</b></p>
<p>to put nano into /usr/bin when you run <b>make install</b>.</p></blockquote>
<h3><aname="3.5"></a>3.5. nano should automatically run strip on the binary when installing it!</h3>
<blockquote><p>Actually, it does, but you have to use <b>make install-strip</b>. The default make install does not, and will not, run strip automatically.</p></blockquote>
<h3><aname="3.6"></a>3.6. How can I make the executable smaller? This is too bloated!</h3>
<p>This will put nano into /usr/bin when you run <b>make install</b>.</p></blockquote>
<h3><aname="3.4"></a>3.4. nano should automatically run strip on the binary when installing it!</h3>
<blockquote><p>It does when you use <b>make install-strip</b>. The default <b>make install</b> does not, and will not, run strip automatically.</p></blockquote>
<h3><aname="3.5"></a>3.5. How can I make the executable smaller? This is too bloated!</h3>
<blockquote><p>Actually, there are several parts of the editor that can be disabled. You can pass arguments to the <b>configure</b> script that disable certain features. Here's a brief list:</p>
<pre>
<b>--disable-browser</b> Disable the built-in file browser
@@ -162,54 +160,47 @@
<b>--disable-tabcomp</b> Disable the tab-completion functions
<b>--disable-wordcomp</b> Disable the word-completion function
<b>--disable-wrapping</b> Disable all hard-wrapping of text</pre>
<p>There's also the <b>--enable-tiny</b> option which disables everything above, as well as some larger chunks of the program (like the marker code that you use with Control-^ to select text). Also, if you know you aren't going to be using other languages, you can use <b>--disable-nls</b> to disable internationalization and save a few K to a few dozen K depending on whether you have locale support on your system. And finally, there's always good old <b>strip</b> to strip all debugging code and code that exists in libraries on your system.</p>
<p>With <b>--disable-wrapping-as-root</b> you can disable any hard-wrapping by default when the user is root, useful to prevent accidentally changing long lines in system configuration files.</p>
<p>There's also the <b>--enable-tiny</b> option which disables everything above, as well as some larger chunks of the program (like the undo/redo code and the code for selecting text). Also, if you know you don't need other languages, you can use <b>--disable-nls</b> to disable internationalization and save a few kilobytes. And finally, there's always good old <b>strip</b> to remove all unneeded symbols.</p>
</blockquote>
<h3><aname="3.7"></a>3.7. Tell me more about this multibuffer stuff!</h3>
<h3><aname="3.6"></a>3.6. Tell me more about this multibuffer stuff!</h3>
<blockquote><p>To use multiple file buffers, you must not have configured nano with <b>--disable-multibuffer</b> nor with <b>--enable-tiny</b> (use <b>nano -V</b> to check the compilation options). Then when you want to insert a file into its own buffer instead of into the current file, just hit <b>Meta-F</b> after typing <b>^R</b>. If you always want files to be loaded into their own buffers, use the <b>-F</b> or <b>--multibuffer</b> flag when you invoke nano, or add <b>set multibuffer</b> to your .nanorc file.</p>
<p>You can move between the buffers you have open with the <b>Meta-<</b> and <b>Meta-></b> keys, or more easily without holding Shift: <b>Meta-,</b> and <b>Meta-.</b> (clear as mud, right? =-). When you have more than one buffer open, the ^X shortcut will say "Close", instead of "Exit".</p></blockquote>
<h3><aname="3.8"></a>3.8. Tell me more about this verbatim input stuff!</h3>
<h3><aname="3.7"></a>3.7. Tell me more about this verbatim input stuff!</h3>
<blockquote><p>When you want to insert a literal character into the file you're editing, such as a control character that nano usually treats as a command, first press <b>Meta-V</b> (if you're not at a prompt, you'll get the message "Verbatim Input" on the status bar), then press the key(s) that generate the character you want.</p>
<p>Alternatively, if Unicode support is enabled (see section <ahref="#5.3">5.3</a>), you can press <b>Meta-V</b> and then type a six-digit hexadecimal code (from 000000 to 10FFFF, case-insensitive), and the character with the corresponding value will be inserted. The status bar will change to "Unicode Input: ......" when you do this.</p></blockquote>
<h3><aname="3.9a"></a>3.9a. How do I make a .nanorc file that will be read when I start nano?</h3>
<blockquote><p>It's not hard at all! But, your nano must <b>not</b> have been compiled with <b>--disable-nanorc</b>. Then simply copy the <b>sample.nanorc</b> that came with the nano source or your nano package (most likely in /usr/doc/nano) to .nanorc in your home directory. If you didn't get one, the syntax of the file is simple. Flags are turned on and off by using the words <b>set</b> and <b>unset</b>plus the long option name for the feature. For example, "set nowrap" or "set smarthome".</p></blockquote>
<h3><aname="3.9b"></a>3.9b. How about in Win32?</h3>
<blockquote><p>If you're using the official nano .zip file and have extracted all the files, you should take the file nano.rc and place it somewhere on your Win32 system (for example, if you have write permission to do so, at the top of C:\). Then you must create an Environment variable called HOME which points to the directory where you put nano.rc. In Windows XP, you can get to Environment variables by right-clicking "My Computer" either on the desktop or in the Start Menu, and selecting Properties. This should bring up the System Properties panel. Then click the Advanced Tab, and there should be a button called Environment Variables. Click that to bring up the Environment Variables section. Now, under User Variables you should be able to click the New button, and make a new Variables Name called HOME, with the Variable Value of whatever path you copied nano.rc into (just the directory name; don't add nano.rc onto the end).</p>
<p>We're still working on documentation for enabling syntax highlighting on Win32; please bear with us.</p>
<p>Note that the nano.rc file must remain Unix-formatted in order for nano to understand it. In other words, you should probably use only nano to edit its config file. Other programs like Wordpad and Notepad will convert the file to DOS format when saving, and the latter does not even properly read Unix-formatted files to begin with.</p></blockquote>
<h3><aname="3.8"></a>3.8. How do I make a .nanorc file that will be read when I start nano?</h3>
<blockquote><p>It's not hard at all! Simply copy the <b>sample.nanorc</b> from the doc/ directory in the nano source package (or from /usr/doc/nano on your system) to <b>.nanorc</b> in your home directory, and then edit it. If you didn't get a sample nanorc, the syntax of the file is simple: features are turned on and off by using the words <b>set</b> and <b>unset</b>followed by the long option name of the feature (see <b>man nanorc</b> for the full list of options). For example, "set quickblank" or "set smarthome". Of course, for this to work, your nano must <b>not</b> have been compiled with <b>--disable-nanorc</b>.</p></blockquote>
<h3><aname="3.9"></a>3.9. Why does my self-compiled nano not read /etc/nanorc?</h3>
<blockquote><p>By default (see <ahref="#3.3">3.3</a>), nano gets installed into /usr/local. This also means that, at startup, nano will read <b>/usr/local/etc/nanorc</b> instead of <b>/etc/nanorc</b>. You can make a symlink from the former to the latter if you want your self-compiled nano to read the same nanorc as the system-installed nano. Or you can configure your nano to overwrite the system nano (again, see <ahref="#3.3">3.3</a>).</p></blockquote>
<hrwidth="100%">
<h1><aname="4"></a>4. Running</h1>
<h3><aname="4.1"></a>4.1. How do I open a file with a name beginning with '+' from the command line?</h3>
<blockquote><p>If a command-line option that begins with '+' is followed by another option, the former is always treated as a starting line and column number, and the latter is always treated as a filename. If a command-line option that begins with '+' isn't followed by another option, it's always treated as a filename. Examples:</p>
<p>To open '+filename.txt' starting on line 1: <b>nano +filename.txt</b><br>
<blockquote><p>If a command-line argument that begins with '+' is followed by another argument, the former is always treated as a starting line (plus column number), and the latter always as a filename. If a command-line argument that begins with '+' isn't followed by another argument, it's treated as a filename. Examples:</p>
<p>To open '+filename.txt': <b>nano +filename.txt</b><br>
To open '+filename.txt' starting on line 10: <b>nano +10 +filename.txt</b><br>
To open '+filename.txt' starting on line 1, column 20: <b>nano +,20 +filename.txt</b><br>
To open '+filename.txt' starting on line 10, column 20: <b>nano +10,20 +filename.txt</b><br>
To open '+filename.txt' starting on line 1 and 'filename.txt' starting on line 40 (if nano has been compiled with multibuffer support): <b>nano +1 +filename.txt +40 filename.txt</b></p></blockquote>
To open '+filename.txt' starting on line 1 and 'filename.txt' starting on line 40: <b>nano +1 +filename.txt +40 filename.txt</b></p></blockquote>
<h3><aname="4.2"></a>4.2. Ack! My Backspace/Delete/Enter/Meta/double bucky key doesn't seem to work! What can I do?</h3>
<blockquote><p>Try setting your $TERM variable to 'vt100'. nano doesn't yet support every term entry under the sun.</p>
<p>Bourne shell users (bash and sh): <b>export TERM=vt100</b><br>
C Shell users (tcsh and csh): <b>setenv TERM vt100</b></p></blockquote>
<h3><aname="4.3"></a>4.3. Ack! My numeric keypad's keys don't work properly when NumLock is off! What can I do?</h3>
<blockquote><p>You can use the <b>-K</b> or <b>--rebindkeypad</b> option on the command line, or add the line <b>set rebindkeypad</b> to your .nanorc. However, nano's mouse support won't work properly if you do any of these things.</p></blockquote>
<h3><aname="4.4"></a>4.4. Ack! When I hold down a Meta key combination for a while, the character of the held key gets inserted now and then. What gives?</h3>
<blockquote><p>This was a bug in how nano handled consecutive escape sequences. It should be fixed since version 2.6.0.</p></blockquote>
<h3><aname="4.5"></a>4.5. How do I type the F13-F16 keys listed in the help viewer? My keyboard only has F1-F12!</h3>
<blockquote><p>It depends on the terminal type you're using. On some terminals, such as the FreeBSD console, xterm, konsole, and gnome-terminal, Shift-F1 to Shift-F4 will generate F13 to F16. On other terminals, such as the Linux console, rxvt, and Eterm, Shift-F3 to Shift-F6 will generate F13 to F16.</p></blockquote>
<h3><aname="4.6"></a>4.6. nano crashes when I type <insert keystrokes here>!</h3>
<blockquote><p>If you aren't trying some bizarre keystroke combination with some bizarre $TERM entry, chances are you have found a bug. You are welcome to submit it to the <ahref="mailto:nano-devel@gnu.org">nano-devel</a> list or in the <ahref="https://savannah.gnu.org/bugs/?group=nano">bug tracker</a> on Savannah.</p></blockquote>
<h3><aname="4.7"></a>4.7. nano crashes when I resize my window. How can I fix that?</h3>
<blockquote><p>Older versions of nano had this problem. Please upgrade to version 2.7.0 or newer.</p></blockquote>
<h3><aname="4.8a"></a>4.8a. With what keystroke can I paste text from the clipboard into nano?</h3>
<blockquote><p>You can use the <b>-K</b> or <b>--rawsequences</b> option on the command line, or add the line <b>set rawsequences</b> to your .nanorc. However, nano's mouse support will be disabled if you do any of these things.</p></blockquote>
<h3><aname="4.4"></a>4.4. With what keystroke can I paste text from the clipboard into nano?</h3>
<blockquote><p>In most desktop environments <b>Shift+Insert</b> will paste the contents of the clipboard.</p></blockquote>
<h3><aname="4.8b"></a>4.8b. When I paste text into a document, each line gets indented further than the last. Why? And how can I stop this?</h3>
<blockquote><p>You have the <i>autoindent</i> feature turned on. Hit <b>Meta-I</b> to turn it off, paste your text, and then hit <b>Meta-I</b> again to turn it back on.</p></blockquote>
<h3><aname="4.8c"></a>4.8c. When I paste from Windows into a remote nano, nano rewraps the lines. What gives?</h3>
<blockquote><p>When pasting from Windows, in some situations linefeeds are sent instead of carriage returns (Enters). And linefeeds are<b>^J</b>s, which make nano justify (rewrap) the current paragraph. To prevent these linefeeds from causing these unwanted justifications, add this line to your .nanorc on the remote Linux box: <b>unbind ^J main</b> or <b>bind ^J enter main</b>, depending on whether the paste contains CR + LF or only LF.</p></blockquote>
<h3><aname="4.9"></a>4.9. I've compiled nano with color support, but I don't see any color when I run it!</h3>
<blockquote><p>If you want nano to actually use color, you have to specify the color configurations you want it to use in your .nanorc. Several example configurations are in the <b>syntax/</b> subdirectory of the nano source, which are normally installed to <b>/usr/local/share/nano/</b>. To enable all of them, uncomment the line <b># include "/usr/local/share/nano/*.nanorc"</b> in your nanorc. See also section <ahref="#3.9a">3.9a</a>.</p></blockquote>
<h3><aname="4.10"></a>4.10. How do I make nano my default editor (in Pine, mutt, etc.)?</h3>
<h3><aname="4.5"></a>4.5. How do I select text for or paste text from the clipboard when nano's mouse support is turned on?</h3>
<blockquote><p>Try holding down the Shift key and selecting or pasting the text as you normally would.</p></blockquote>
<h3><aname="4.6"></a>4.6. When I paste text into a document, each line gets indented further than the last. Why? And how can I stop this?</h3>
<blockquote><p>You have the <i>autoindent</i> feature turned on. Hit<b>Meta-I</b> to turn it off, paste your text, and then hit <b>Meta-I</b> again to turn it back on.</p>
<p><i>Update:</i> Since version 4.8, nano will suppress auto-indentation during a paste, so you no longer need to toggle it off and on manually.</p></blockquote>
<h3><aname="4.7"></a>4.7. When I paste from Windows into a remote nano, nano rewraps the lines. What gives?</h3>
<blockquote><p>When pasting from Windows, in some situations linefeeds are sent instead of carriage returns (Enters). And linefeeds are <b>^J</b>s, which make nano justify (rewrap) the current paragraph. To prevent these linefeeds from causing these unwanted justifications, add this line to your .nanorc on the remote Linux box: <b>unbind ^J main</b> or <b>bind ^J enter main</b>, depending on whether the paste contains CR + LF or only LF.</p>
<p><i>Update:</i> Since version 4.8, nano will ignore linefeed characters in a paste, so you no longer need the above workaround.</p></blockquote>
<h3><aname="4.8"></a>4.8. I've compiled nano with color support, but I don't see any color when I run it!</h3>
<blockquote><p>If you want nano to actually use color, you have to specify the color configurations you want it to use in your .nanorc. Several example configurations are in the <b>syntax/</b> subdirectory of the nano source, which are normally installed to <b>/usr/local/share/nano/</b>. To enable all of them, uncomment the line <b># include "/usr/local/share/nano/*.nanorc"</b> in your nanorc. See also section <ahref="#3.9">3.9</a>.</p></blockquote>
<h3><aname="4.9"></a>4.9. How do I make nano my default editor (in Pine, mutt, etc.)?</h3>
<blockquote><p>You need to make nano your $EDITOR. If you want this to be saved, you should put a line like this in your <b>.bashrc</b> if you use bash (or <b>.zshrc</b> if you believe in zsh):</p>
<p><b>export EDITOR=/usr/local/bin/nano</b></p>
<p>or, if you use tcsh, put this in your <b>.cshrc</b> file:</p>
@@ -220,21 +211,15 @@
<b>[ ] enable-alternate-editor-implicitly</b></p>
<p>Then exit (<b>E</b>) and select Yes (<b>Y</b>).</p>
<p>If you're a mutt user, you should see an effect immediately the next time you log in. No further configuration is needed. However, if you want to let people know you use nano to compose your email messages, you can put a line like this in your <b>.muttrc</b>:</p>
<p><b>my_hdr X-Composer: nanox.y.z</b></p>
<p>Again, replace x.y.z with the version of nano you use.</p></blockquote>
<h3><aname="4.11"></a>4.11. How do I select text for or paste text from the clipboard in an X terminal when I'm running nano in one and nano's mouse support is turned on?</h3>
<blockquote><p>Try holding down the Shift key and selecting or pasting the text as you normally would.</p></blockquote>
<h3><aname="4.12"></a>4.12. On startup I get a message that says "Detected a legacy nano history file". Now older nano versions can't find my search history!</h3>
<blockquote><p>In nano 2.3.0, cursor-position history was introduced, and both history files now reside in a .nano subdirectory in your home directory. A newer nano will move an existing search-history file to this new location so it can continue to be used. This means that if you then try and use an earlier version of nano, it will be unable to see your current search history. To fix this, run the following command:</p>
<p>The "migration service" (moving the search-history file to its new location) has been deleted from nano in late 2017, since version 2.9.0. The search-history and position-history files will now be looked for first in ~/.nano/ and, when not found there, then in ~/.local/share/nano/.</p></blockquote>
<p><b>my_hdr X-Composer: nano-x.y</b></p>
<p>Again, replace x.y with the version of nano you use.</p></blockquote>
<hrwidth="100%">
<h1><aname="5"></a>5. Internationalization</h1>
<h3><aname="5.1"></a>5.1. There's no translation for my language!</h3>
<blockquote><p>In June 2001, GNU nano entered the <ahref="http://translationproject.org/html/welcome.html">Translation Project</a> and since then, translations should be managed from there.</p>
<p>If there isn't a translation for your language, you could ask <ahref="http://translationproject.org/team/">your language team</a> to translate nano, or better still, join that team and do it yourself. Joining a team is easy. You just need to ask the team leader to add you, and then send a <ahref="http://translationproject.org/disclaim.txt">translation disclaimer to the FSF</a> (this is necessary as nano is an official GNU package, but it does <b>not</b> mean that you transfer the rights of your work to the FSF, it's just so the FSF can legally manage them).</p>
<p>In any case, translating nano is easy. Just grab the latest <b>nano.pot</b> file listed on <ahref="http://translationproject.org/domain/nano.html">nano's page</a> at the TP, and translate each <b>msgid</b> line into your native language on the <b>msgstr</b> line. When you're done, you should send it to the TP's central PO-file repository.</p></blockquote>
<blockquote><p>In June 2001, GNU nano entered the <ahref="https://translationproject.org/html/welcome.html">Translation Project</a> and since then, translations should be managed from there.</p>
<p>If there isn't a translation for your language, you could ask <ahref="https://translationproject.org/team/">your language team</a> to translate nano, or better still, join that team and do it yourself. Joining a team is easy. You just need to ask the team leader to add you, and then send a <ahref="https://translationproject.org/disclaim.txt">translation disclaimer to the FSF</a> (this is necessary as nano is an official GNU package, but it does <b>not</b> mean that you transfer the rights of your work to the FSF, it's just so the FSF can legally manage them).</p>
<p>In any case, translating nano is easy. Just grab the latest <b>nano.pot</b> file listed on <ahref="https://translationproject.org/domain/nano.html">nano's page</a> at the TP, and translate each <b>msgid</b> line into your native language on the <b>msgstr</b> line. When you're done, you should send it to the TP's central PO-file repository.</p></blockquote>
<h3><aname="5.2"></a>5.2. I don't like the translation for <x> in my language. How can I fix it?</h3>
<blockquote><p>The best way is to send an e-mail with your suggested corrections to the team's mailing list. The address is mentioned in the <code>Language-Team:</code> field in the relevant PO file. The team leader or the assigned translator can then make the changes reach the nano-devel list.</p></blockquote>
<h3><aname="5.3"></a>5.3. What is the status of Unicode support?</h3>
@@ -243,12 +228,11 @@
<h1><aname="6"></a>6. Advocacy and Licensing</h1>
<h3><aname="6.1"></a>6.1. Why should I use nano instead of Pico?</h3>
<blockquote><p>There are many reasons to use nano instead of Pico. A more complete list can be found at the <ahref="https://nano-editor.org/">nano homepage</a>.</p></blockquote>
<blockquote><p>If you want features like undo/redo, syntax highlighting, line numbers, soft-wrapping, opening multiple files at once, an interface localized to your language, or search and replace with support for regular expressions, then you want nano.</p></blockquote>
<h3><aname="6.2"></a>6.2. Why should I use Pico instead of nano?</h3>
<blockquote><p>Again, check out the <ahref="https://nano-editor.org/">nano homepage</a> for a good summary of reasons. It really is a matter of personal preference as to which editor you should use. If you're the type of person who likes using the original version of a program, then Pico is the editor for you. If you don't mind sacrificing mailer integration with Pine, and are looking for a few more features, as well as a 'better' license in terms of adding your own changes, nano is the way to go.</p>
<p>Note that the last of these no longer applies to the new version of Pine, <ahref="http://www.washington.edu/alpine/">Alpine</a>, which is under the Apache License, version 2.0.</p></blockquote>
<blockquote><p>If you use your editor only to write emails or other texts and have no need for the above-mentioned features, then Pico will do fine for you.</p></blockquote>
<h3><aname="6.3"></a>6.3. What is so bad about the older Pine license?</h3>
<blockquote><p>The U of W license for older versions of Pine and Pico is not considered truly Free Software according to both the Free Software Foundation and the <ahref="http://www.debian.org/social_contract#guidelines">Debian Free Software Guidelines</a>. The main problem regards the limitations on distributing derived works: according to UW, you can distribute their software, and you can modify it, but you can not do both, i.e. distribute modified binaries.</p></blockquote>
<blockquote><p>The U of W license for older versions of Pine and Pico is not considered truly Free Software according to both the Free Software Foundation and the <ahref="https://www.debian.org/social_contract#guidelines">Debian Free Software Guidelines</a>. The main problem regards the limitations on distributing derived works: according to UW, you can distribute their software, and you can modify it, but you can not do both, i.e. distribute modified binaries.</p></blockquote>
<h3><aname="6.4"></a>6.4. Okay, well, what mail program should I use then?</h3>
<blockquote><p>If you are looking to use a Free Software program similar to Pine, and Emacs is not your thing, you should definitely take a look at <ahref="http://www.mutt.org/">mutt</a>. It is a full-screen, console based mail program that actually has a lot more flexibility than Pine, but has a keymap included in the distribution that allows you to use the same keystrokes as Pine would to send and receive mail. It's also under the GNU General Public License, version 2.0.</p>
<p>Of course, due to the license change you can now use the <ahref="http://www.washington.edu/alpine/">Alpine distribution</a> of PINE as it is now considered Free Software, but you would be sacrificing many of nano's features to do so.</p></blockquote>
@@ -256,10 +240,10 @@
<h1><aname="7"></a>7. Miscellaneous</h1>
<h3><aname="7.1"></a>7.1. Where can I ask questions or send suggestions?</h3>
<blockquote><p>There are three mailing lists for nano hosted at <ahref="http://savannah.gnu.org/">Savannah</a>: info-nano, help-nano and nano-devel. info-nano is a very low traffic list where new versions of nano are announced (surprise!). help-nano is for getting help with the editor without needing to hear all of the development issues surrounding it. nano-devel is a normally low, sometimes high traffic list for discussing the present and future development of nano. Here are links to where you can sign up for a given list:</p>
<blockquote><p>There are three mailing lists for nano hosted at <ahref="https://savannah.gnu.org/">Savannah</a>: info-nano, help-nano and nano-devel. info-nano is a very low traffic list where new versions of nano are announced (surprise!). help-nano is for getting help with the editor without needing to hear all of the development issues surrounding it. nano-devel is a normally low, sometimes high traffic list for discussing the present and future development of nano. Here are links to where you can sign up for a given list:</p>
<h3><aname="7.2"></a>7.3. How do I submit a bug report or patch?</h3>
<blockquote>
<p>The best way to submit bugs is through the <ahref="https://savannah.gnu.org/bugs/?group=nano">Savannah bug tracker</a>, as you can check whether the bug you are reporting has already been submitted, and it makes it easier for the maintainers to keep track of them.
color red "\<(as|case|of|class|data|default|deriving|do|forall|foreign|hiding|if|then|else|import|infix(l|r)?|instance|let|in|mdo|module|newtype|qualified|type|where)\>"
# Various symbols
color cyan "\||@|!|:|_|~|=|\\|;|\(\)|,|\[|\]|\{|\}"
# Operators
color magenta "==|/=|&&|\|\||<|>|<=|>="
# More symbols
color cyan "->|<-|=>"
color magenta "\.|\$"
# Data constructors
color magenta "\<(True|False|Nothing|Just|Left|Right|LT|EQ|GT)\>"
# Data classes
color magenta "\<(Bounded|Data|Enum|Eq|Floating|Fractional|Functor|Integral|Monad|MonadPlus|Num|Ord|Read|Real|RealFloat|RealFrac|Show|Typeable)\>"
# Special keyword
color brightred "undefined"
# Strings
color yellow ""([^\"]|\\.)*""
# Characters
color brightyellow "'([^\']|\\.)'"
# Comments
color green "--.*"
color green start="\{-" end="-\}"
# Trailing whitespace
color ,green "[[:space:]]+$"
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
