For installing and using nano, those two Changelogs are useless,
and for inspecting the history of nano, 'git log' is much better.
Only the most recent Changelog is somewhat useful for some users,
for walking in some detail through the changes that were made in
the last few versions.
This will not work for the deviant escape sequences for F1 to F5
on the Linux console nor for Alt+arrow on urxvt and such, but...
I can't be bothered to handle those too.
This fixes https://savannah.gnu.org/bugs/?58929.
Bug existed since commit be203832 from earlier today.
During verbatim input at most four integers are produced (the longest
possible unicode sequence), so use the value 999 to indicate a special
condition (a screen resize) that should not enter anything into the
buffer AND should not produce any error message or beep.
This fixes https://savannah.gnu.org/bugs/?58923.
Bug existed since version 5.0, commit 5899181a.
When Unicode Input has started (by typing 0 or 1 at the Verbatim Input
"prompt"), and something is typed that is not a hexadecimal digit, then
don't try to enter this character into the buffer but simply report it
as invalid and ignore it. Because most likely the user mistyped and
actually meant to enter a valid hex digit.
This fixes https://savannah.gnu.org/bugs/?58927.
The bug was old -- it existed since at least version 2.0.6.
Just like <Ctrl+Down> goes to the end of the buffer when after the
cursor there are only blank lines.
This fixes https://savannah.gnu.org/bugs/?58921.
Bug existed since version 2.6.2, since <Ctrl+Up/Down> were introduced.
The correct sequences begin with "Esc [" instead. I cannot find in the
histories of VTE and Gnome Terminal when these sequences were corrected.
Also exclude a bug check from the tiny version.
When we get an ESC from the keyboard, it might be the start of an
escape sequence, but the keyboard routines will need a little time
(tens of microseconds, probably) to get these codes to ncurses.
So, when doing verbatim input, pause a moment after an ESC.
This completes the fix for https://savannah.gnu.org/bugs/?58909.
Always interpret ESC followed by BS or DEL as <Alt+Backspace>.
This fixes https://savannah.gnu.org/bugs/?58910.
Bug existed since commit 40b03162 from one week ago,
since M-Bsp was hard-bound to deleting a word backwards.
(This could lead to unwanted behavior when the user wants to enter
a literal escape character (0x1B) while the input is somehow getting
stalled, because then a command keystroke after the M-V <Esc> would
get inserted verbatim too, instead of getting acted upon. But that
is a small price to pay for getting the correct behavior for both
M-V M-Bsp and M-V M-Enter.)
This fixes https://savannah.gnu.org/bugs/?58909.
Bug existed since version 2.6.3, commit 08c51cfd,
but also occurred erratically beforehand.
After commit 59bbc0b8 from five days ago (that made a divergent pipe
failure to be treated in the same way as the other two), this became
possible without having two different pipe-failure messages.
The user had better avoid using the keystroke in a macro, but
when typing directly at a responsive machine there is no problem,
M-[ is a perfectly valid and recognizable keystroke.
This fulfills https://savannah.gnu.org/bugs/?58820.
The make_new_node() function initializes 'extrarows' to a bad value
on purpose, to catch cases like this one where it doesn't get updated
properly.
This fixes https://savannah.gnu.org/bugs/?58890.
Reported-by: Jerry Kindall <kindall@gmail.com>
Bug existed since version 5.0, since the indicator was introduced.
More generally, after invoking the formatter, the entire buffer should
be cut (to be replaced with the reformatted text) and not just the part
before the mark, because then everything after it would be duplicated.
This fixes https://savannah.gnu.org/bugs/?58879.
Bug existed since version 4.9, commit 19517fc5.
When compiling with GCC 10.1.0 and -O2 -Wall, the strncpy() call
in measured_copy() produced two stringop-truncation warnings.
This addresses https://savannah.gnu.org/bugs/?58861.
Signed-off-by: Michalis Kokologiannakis <michalis@mpi-sws.org>
Between an endwin() and a doupdate() there should be no calls of
statusline() or statusbar() -- these two functions may be called
only when in curses mode.
This fixes https://savannah.gnu.org/bugs/?58868.
Bug existed since version 4.3, commit 57390cff.
If forking fails, we must first return to curses mode before we can show
an error message on the status bar. (This additionally requires storing
the error number, because doupdate() apparently sets it to zero.)
This fixes https://savannah.gnu.org/bugs/?58864.
Bug existed since version 4.8, commit 61197563.
It jars a bit that it is <Ctrl+Delete> that deletes a word rightward
and <Alt+Backspace> that deletes a word leftward. But it's good to
also have a two-key keystroke bound by default to 'chopwordleft',
and not just the three-key <Ctrl+Shift+Delete>.
This fulfills https://savannah.gnu.org/bugs/?58709.
Requested-by: Axel Scheepers <axel.scheepers76+gnu@gmail.com>
While ignoring permission errors from fchmod() and fchown() is okay
(since normal users are not always privileged to make such changes),
ignoring also more serious errors (like EIO) is not ideal.
Signed-off-by: Michalis Kokologiannakis <michalis@mpi-sws.org>
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.
If the edit window consists of a single row, then the do_up() call has
already brought the desired line into view -- which means that trying
to scroll then (when already on the first line of the file) would fail.
This fixes https://savannah.gnu.org/bugs/?53891.
Letters in other scripts than English often consist of multiple bytes.
When in a UTF-8 locale, correctly gather these bytes from the input and
put them together as the single letter that they are, before comparing
this letter against the translated "Yy", "Nn" and "Aa" strings.
The tiny version contains much less code, so is less likely
to crash. And the users most likely use it for very simple
and short editing jobs, making the chance of a crash still
smaller. So the handler would just be bloat.
When 'afterends' is set and Ctrl+Right or Shift+Ctrl+Right is pressed,
nano will stop at the ends of words instead of their beginnings.
Signed-off-by: Mark-Weston <markweston@cock.li>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Upon a segmentation fault or an abort signal, instead of crashing,
losing all changes, and leaving the terminal in curses mode, nano
now calls die(), to save any changed buffers and to restore the
terminal to a usable state.
For the remote chance that nano segfaults in die(), the handler for
SIGSEGV and for SIGABRT is reset to its default value as soon as the
signal fires, to prevent a crash-handler loop.
Since a core dump is usually more helpful for debugging, the crash
handler is not included in a debug build.
This addresses https://savannah.gnu.org/patch/?9623.
Signed-off-by: Devin Hussey <husseydevin@gmail.com>
Also, add a period after the "Read nn lines" message, and
don't let the next shell prompt overwrite this message.
This addresses https://savannah.gnu.org/bugs/?53779.
This makes the names of these bindable functions equal to the names of
their corresponding options -- like for all the other toggles that have
a corresponding option.
Set the NO_NEWLINES flag to achieve this. And move the saving and
restoring of the global flags to the main speller routine, so the
flags aren't saved and restored for each internal spell fix.
This fixes https://savannah.gnu.org/bugs/?53742.
Acked-by: David Lawrence Ramsey <pooka109@gmail.com>
When the cursor is on the top or bottom line of the edit window, and
an <Up> or <Down> pushes the cursor offscreen, then use edit_scroll()
to bring it back into view, instead of using edit_redraw(), because
the latter would redraw *every row* on the screen, which is a waste
of time.
This addresses https://savannah.gnu.org/bugs/?53562.
Reported-by: Devin Hussey <husseydevin@gmail.com>
Bug existed since commit 30fc197b (a month ago) which changed the
type of 'i' from int to size_t, causing the comparison to do the
wrong thing when 'threshold' is negative.
This fixes https://savannah.gnu.org/bugs/?53722.
Reported-by: Devin Hussey <husseydevin@gmail.com>
The formatter or linter might have changed in the meantime -- when
the filename was changed to have a different extension, for example.
This fixes https://savannah.gnu.org/bugs/?53716.
When the keyboard buffer is empty, return a value that is not equivalent
to <Ctrl+Space>, so that typing a bunch of these while searching is going
on will not result in some of them getting executed afterward.
Indenting/unindenting always happens in a single contiguous block.
Lines that cannot or should not be indented or unindented do not
need to remembered separately as it follows from their content.
That is, do not fall back to the default background color when the
name for the background color is invalid, but reject the entire
color command, just like for an invalid foreground color.
In the preceding commit, open_buffer() was changed so that it gets
told whether to load into a new buffer or not, so it is no longer
needed to convey this information through a flag.
This fixes a regression introduced by commit 54103d8e: a crash that
can be triggered by running 'nano --restrict' and pressing <Insert>.
This addresses https://bugzilla.redhat.com/1558532.
When the file has just been read, it is in the state that it has
on disk, so there is nothing to undo.
This fixes https://savannah.gnu.org/bugs/?53387.
When the cursor is on the first or last row of the edit window, and
thus Scroll-Down or Scroll-Up would push it offscreen, first move
the cursor away from the edge row and then scroll.
This fixes https://savannah.gnu.org/bugs/?53376.
As, since commit 0e30177d, the scrollup and scrolldown commands
no longer intend to move the cursor, they should not be seen as
movement functions.
Also, it is not guaranteed that functions are ordered in the same
way in the binary as in the source code, so an ordered comparison
of function pointers will not always work.
This fixes https://savannah.gnu.org/bugs/?53333.
When just scrolling and the cursor does not need to change position
(that is: it is not on the first or last row of the edit window),
then edit_scroll() has handled everything and there is no need to
additionally redraw anything or update 'placewewant'.
Instead of keeping the cursor in the same spot on the screen,
let the cursor move with the text (whenever possible).
This makes these functions behave the same as in Vim and Emacs.
Help texts are shown without any line numbers, so the full width
of the screen should be used to display the text.
This fixes https://savannah.gnu.org/bugs/?53308.
First the two that add something (ADD, ENTER), then the three that
delete something (BACK, DEL, JOIN), and then the one that changes
something (REPLACE). Then the SPLITs, CUT, PASTE, and INSERT, and
then the INDENTs and COMMENTs, when they exist.
For cuts, pastes, and inserts, the lines have already been renumbered;
for indents, comments, and replacements, the line numbers cannot have
changed. (And anyway, variable 'f' is not set for those cases.)
Only when lines get split (ENTER) or fused together (JOIN) do the later
lines need to be renumbered. This mirrors what is done for do_redo().
The 'f' variable is used only in the ADD, BACK, DEL, ENTER, JOIN, and
REPLACE undo/redo cases. So, avoid making a somewhat costly call when
it is entirely superfluous. Rearrange the undo types to make checking
for the above six types easier.
This assumes that all movement functions are located together,
starting with to_first_line() and ending with do_right().
This fixes https://savannah.gnu.org/bugs/?53195.
Reported-by: Brand Huntsman <alpha@qzx.com>
The implant() function itself cannot be bound to anything, so it
is not in the linked list of functions -- trying to find it would
lead to a NULL pointer, and thus to a segfault.
This fixes https://savannah.gnu.org/bugs/?53233.
Instead of always calling sctofunc(), it is now only called when
in view mode OR when (after the keystroke's function has been run)
no need for a refresh has been established yet.
Commit bb667beb removed do_gotolinecolumn_void() from the MWHEREIS
menu (replacing it with the empty flip_goto() function), so there
is no longer any need to check for this one special case.
The slash is easier to read than the underscore (which almost
disappears at the bottom of the screen), and easier to type
(no Shift needed on a US keyboard), and it kind of harmonizes
with the ^\ for Replace and the M-/ for End-of-buffer.
When using --smooth or 'set smooth', the screen should scroll the
minimum amount needed to get the cursor back into view. (The only
exceptions are search, undo, and redo -- when there the cursor goes
offscreen, the cursor line is centered.)
This change brings the behavior of pressing <Enter> on the bottom
row into line with, for example, pasting a single line. See also
http://lists.gnu.org/archive/html/nano-devel/2018-02/msg00027.html.
When 'refresh_needed' is already TRUE, there is no need any more
to check whether it should be set.
[Those first two calls are leftovers from before the time that
reset_multis() morphed into check_the_multis().]
When characters are added via Verbatim Input or by pressing <Tab>,
the prepend flag should be retained, just like when characters are
typed directly.
This fixes https://savannah.gnu.org/bugs/?52956.
When copying a string, source and destination may not be equal --
complain loudly when they are, instead of failing to free memory.
Also, instead of freeing the destination string and then allocating
it afresh, just reallocate it -- that should be slightly quicker.
When doing for example: ^W xx ^R ^C ^W, the "xx" would again be shown
after the prompt. This is wrong -- when starting a new search, the
current answer should be empty.
Reported-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
Instead of weaving back and forth between do_search()/do_replace() and
search_init() every time that one of the options is toggled, just keep
looping in the latter function until the user presses <Enter>.
The weaving for the do_gotolinecolumn() function remains, but is
shortened to involve only search_init().
In this way a single keystroke can produce a fragment of text or a
series of commands, or a mix of the two. It is like a prerecorded
macro.
This fulfills https://savannah.gnu.org/bugs/?52931.
When a fragment of help text does not contain any whitespace that
we can wrap at, just advance the pointer, because returning zero
would mean we stay forever at the same place: nano would hang.
Instead of assuming that the entire contents of the keybuffer are an
escape sequence (even if this is far longer than any escape sequence
can be), remove from the keybuffer only those integers that actually
constituted a sequence, valid or invalid.
This fixes https://savannah.gnu.org/bugs/?48659.
Trimming trailing spaces is good, but we should not trim the space
(or tab or other blank) that the user just typed and that caused the
hard-wrapping to occur.
This fixes https://savannah.gnu.org/bugs/?52948.
Reported-by: Andreas Schamanek <schamane@fam.tuwien.ac.at>
The verbosity "hid" the really relevant information:
filename, line number, and the error message.
Valid values and other details can be found in the manual pages.
When the palette is getting initialized, it is too late to send any
error messages about the rcfile options to standard error.
This fixes https://savannah.gnu.org/bugs/?52871.
Reported-by: Brand Huntsman <alpha@qzx.com>
Signed-off-by: Brand Huntsman <alpha@qzx.com>
When we're just searching, we do want to report the occurrence at
the cursor (after coming full circle) as a match, so that we can
mention that this is the only occurrence. When replacing, we do
not want to replace this match twice.
This fixes https://savannah.gnu.org/bugs/?52888.
There shouldn't be two separate variables (but with the same name) that
count the number of digits seen. Fuse them into a single static var.
This fixes https://savannah.gnu.org/bugs/?52863.
The tabsize can vary by configuring editor or viewer, but
the text has some kind of intended alignment.
Also, change the indentation a bit, to make things line up
more neatly.
The fragment "\<\." can never match anything because \< matches the
beginning of a word but "." is not a word character.
Replace \< with \B (the empty string not at the edge of a word).
Signed-off-by: Tom Levy <tomlevy93@gmail.com>
The list now includes all the Lua 5.3 functions listed on
https://www.lua.org/manual/5.3/#index.
Also, remove the coloring of just the library name, so that
only known library functions get highlighted.
Signed-off-by: Tom Levy <tomlevy93@gmail.com>
Since a "0x" by itself is invalid. Also add word boundaries, so that
e.g. "00x1" (which is invalid) does not get partial highlighting.
Also remove some redundant backslashes from the strings regex.
Signed-off-by: Tom Levy <tomlevy93@gmail.com>
Each leading tab is converted to two tabs, and any leading four spaces
is converted to one tab. The intended tab size (for keeping most lines
within 80 columns) is now four.
When unindenting/uncommenting affected the bottom line of the marked
region, keep affecting this line also during subsequent consecutive
indenting/commenting.
This fixes https://savannah.gnu.org/bugs/?52718.
Functions such as "io.close" should only be highlighted when the
package name ("io") is a word by itself, otherwise code such as
"fooio.close" gets unexpected partial highlighting.
Signed-off-by: Tom Levy <tomlevy93@gmail.com>
Also, remove the coloring of special single-quoted strings as they
get recolored by the subsequent general string-coloring command.
And remove the coloring of all-uppercase words, as other editors
do not color those either.
If the marked region ends at the start of a line, do not include that
line in the indenting/undenting or commenting/uncommenting. This is
closer to what the eye would expect.
Unset the "Modified" marker only at the point where the file was last
saved -- if there is such a point, because it can be missing when the
undo stack was discarded.
This fixes https://savannah.gnu.org/bugs/?52689.
Reported-by: Liu Hao <lh_mouse@126.com>
Original-idea-by: Brand Huntsman <alpha@qzx.com>
The function get_keycode() should never return zero -- it should
return either the code from ncurses or the given fallback code.
This fixes https://savannah.gnu.org/bugs/?52682.
When the mark is on, instead of letting a <Tab> simply insert a Tab
character at the cursor position, let it indent the marked region.
Original-idea-by: Chris Allegretta <chrisa@asty.org>
And also allow it when lines are only partially indented.
This makes it possible to equalize the indentations of (accidentally)
unevenly indented lines: by first fully unindenting a group of lines,
and then reindenting them to the desired amount.
Suggested-by: Liu Hao <lh_mouse@126.com>
In this way we can delete things on the current line with ^K (after
Shift-selecting some text) without nano misdetecting a line change,
This fully fixes https://savannah.gnu.org/bugs/?52576.
Only when the cursor has moved off of the currrent line do we stop
prepending wrapped words to the next line.
This partially fixes https://savannah.gnu.org/bugs/?52576.
It's better to color some invalid things as if valid than the other
way around. So, as strings can validly contain any number of double
quotes, just accept *anything* between the delimiting double quotes
and demand that the closing quote is followed by whitespace or EOL.
When the WAS_FINAL_LINE flag is relevant (when NO_NEWLINES isn't set),
the only way for 'current' to be equal to 'filebot' is when 'current_x'
is zero.
When some or all edits have been undone, and the user starts to make
new edits, the old part of the undo stack is discarded, but this does
not mean that the undo stack doesn't go back to the very beginning.
This really fixes https://savannah.gnu.org/bugs/?52504.
On a freshly installed system, or for a new user, the default
XDG data directory may not exist yet. So, create it when not.
Reported-by: Brand Huntsman <alpha@qzx.com>
The softmark is now only cancelled when the cursor is moved without
Shift being held, not for things like ^L (Refresh), ^C (Position),
or ^G (Help).
This addresses https://savannah.gnu.org/bugs/?52470.
When a file is closed with the cursor on line 1, column 1, this
position is not recorded in file-positions history file -- if a
record for the file existed, it is deleted. In the latter case
the history file needs to be saved, so that other instances of
nano will know about the deletion.
This fixes https://savannah.gnu.org/bugs/?52505.
The pointer not being NULL is enough indication that the mark is set.
Also, rename the pointer from 'mark_begin' to simply 'mark', since
the former is kind of pleonastic.
Because the highlighting hinders the display of affected lines,
and, more importantly, only the highlighted part would be written
if the file was modified and the user answers yes to the "Save?"
prompt.
This fixes https://savannah.gnu.org/bugs/?52474.
Since file-5.10 (end of 2011), libmagic identifies a C file in most
cases as "C source" instead of as "C program". Nano's magic strings
for some other files didn't match any more what file-5.32 currently
produces, either. So, they have been adjusted, new ones added, and
old ones deleted.
This fixes https://savannah.gnu.org/bugs/?52445.
Adding the obscure A_PROTECT attribute to every color prevents an
occasional miscoloring of the first few rows on the screen -- when
ncurses is version 6.0 and dates from before October 17, 2015.
Original-idea-by: Brand Huntsman <alpha@qzx.com>
Tested-by: Brand Huntsman <alpha@qzx.com>
This fixes https://savannah.gnu.org/bugs/?52182.
When there are no help lines, there won't be any call to update the
actual contents of the bottom window, so... do it immediately after
blanking the row.
This fixes https://savannah.gnu.org/bugs/?52377.
Whenever a buffer is closed, check whether the positions file on disk
was modified, and if so, reload it. Then update the position for the
closed buffer and write out the positions file to disk.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The function get_key_buffer() assumes waiting_mode = TRUE, but stdin
can be in non-blocking mode when a program (before nano) turned stdin
to non-blocking mode and did not change it back (possibly because it
crashed). So, explicitly set stdin to blocking mode at startup.
Signed-off-by: Lion Yang <lion@aosc.io>
When not finding a .nanorc file in the user's home directory, nano will
look for a nanorc file in $XDG_CONFIG_HOME and in the ~/.config/nano/
fallback directory. And when not finding a .nano/ subdir in the user's
home directory, nano will look for (or create) the history files in
$XDG_DATA_HOME or in the ~/.local/share/nano/ fallback directory.
This is a partial implementation of the XDG Base Directory Specification:
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html,
for the purpose of reducing the clutter in a user's home directory, and
to make it easier to back up just the configuration files.
Signed-off-by: Simon Ochsenreither <simon@ochsenreither.de>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
If the user uses a single version of nano, they have no need for
--quiet. If they do sometimes use an older version and don't want
to see the warnings, they can use 2>/dev/null (they could make an
alias for that and put it before the call of nano).
Initialize 'breaking_col' to what it needs to be when the current chunk
consists of only a tab -- a tab that spreads across both start and end
of the chunk -- so that the last 'if' can move into the preceding one,
which allows the elision of 'char_len'.
In the tiny version, do_prompt() will now have an extra NULL
parameter, which will cost maybe twenty extra bytes of code.
That is acceptable when it saves thirty lines in the source.
The key sequence ^R ^X M-F <Enter> would cause nano to abort, because
it would try to add an empty string to a history list. (Furthermore,
simply don't execute an empty command, because it is pointless.)
Reported-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
After any replacements were made, the "not found" message is pointless
because it will be overwritten rightaway by "Replaced xx occurrences".
The message is confusing and annoying when using speech output.
This partially fixes https://savannah.gnu.org/bugs/?52282.
Reported-by: Chime Hart <chime@hubert-humphrey.com>
List "browser", "pageup" and "pagedown" in the manuals; the first
because it matches "speller", and the latter two because they are
what these functions are commonly known by. The names "tofiles",
"prevpage" and "nextpage" are now undocumented, but they are still
recognized by the code, as they match the tags for these functions.
Most people who make use of 'do_findprevious' and 'do_findnext'
will not make use of 'do_search' (the default binding of M-W),
so for them it is superfluous to remember the state of the
Backwards toggle in the Search menu. For the people that do
mix the usage of Alt+Up/Down with M-W, it means that M-W will
always search in the same direction as the last search. It is
a small change in behavior.
Allow the user to record and run a single macro. The default binding
for starting and stopping the recording is M-: (Alt + colon) and for
running the macro M-; (Alt + semicolon).
This fulfills https://savannah.gnu.org/bugs/?50314.
Requested-by: Peter Passchier <peter@passchier.net>
Signed-off-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
^S will be the first thing people will try for saving a file,
and ^Q is somewhat mnemonic because it is to the left of ^W:
it searches backward.
Make these keystrokes available also in the tiny version.
Before writing a file out, nano should check that the file on disk
hasn't been modified since it was read -- not only for the normal
"Write Out" action (^O), but also for "Save File" (future ^S) and
for "Save and Exit" (^X when --tempfile is used).
When writing fails and --tempfile is in effect, don't go on to prompt
for a file name; instead let the user decide what she wants to do.
This fixes https://savannah.gnu.org/bugs/?51040.
Signed-off-by: Viorel Bota <botaviorel@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Date and version are updated to match each release, so the user does
not have to wonder whether the man page really describes the binary.
Also remove a bit of superfluous markup.
When we've landed on a tab and we are moving down and the tab starts
before the current chunk, then push the index forward -- otherwise we
would not advance. When instead we're moving up and the end of the
preceding row is on the same tab as the target column AND the end of
the current row is not on that same tab, then there is some character
on this row that we can put the cursor on, so push the index forward
-- otherwise we would skip a usable row.
This fixes https://savannah.gnu.org/bugs/?52125
and fixes https://savannah.gnu.org/bugs/?52139.
The recent migration of the history routines forgot to add the new
file to the list of files from which strings should be extracted.
This fixes https://savannah.gnu.org/bugs/?52122.
In atblanks mode, if a softwrapped chunk ends with a double-width space
character (say, Unicode 003000, Ideographic Space), and that would put
half of the character past the edge of the screen, break before it.
This fixes https://savannah.gnu.org/bugs/?51671.
The basic idea is that the cursor is always off, except when it needs
to be on: when waiting for text input, and in a few other cases: when
something was searched and found in the help viewer, and in the file
browser when option -g is in effect.
This fixes https://savannah.gnu.org/bugs/?51923.
Reported-by: Mike Frysinger <vapier@gentoo.org>
When reducing the search string to at most half the screen width,
it should employ its width in columns, not its length in bytes.
Also adjust the type of a variable.
This fixes http://savannah.gnu.org/bugs/?52057.
The functions to read and write history files will not even be called
when the home directory is missing, so there is no need to check for
that eventuality again.
Populating the search, replace, and execute lists makes use of the
function update_history() which sets history_changed to TRUE, which
meant that the search_history file would always get written even if
nothing had changed.
When multiple files were open and [x/n] was being shown in the title
bar, don't show nano's name and version number when just one buffer
remains open, but show [1/1] instead. It is less surprising.
When multiple buffers are open, replace nano's name and version number
with an indication how many buffers are open preceded by the sequence
number of the current buffer.
Signed-off-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
This is modeled after the comment/uncomment code. Each line's
individual indent is saved in the string array of the undo
group structure.
This fixes http://savannah.gnu.org/bugs/?46860.
The function does not contain any comment-specific code, so it can
be used to handle any kind of multiline undo item.
Also, extend the undo group structure to contain an array of strings,
one for each line in the group. When indent/unindent is hooked up to
the undo/redo code, this will allow the latter to restore the exact
original indents.
Also, remove an unneeded null_at() -- the null byte has been copied,
and reallocating the string would recover very little memory.
Also, call charmove() without using the & operator.
This is modeled after the undo/redo code for commenting. do_indent() now
calls indent_a_line() on each line it covers. The latter function will
eventually be used by the undo/redo code.
When moving the cursor to the top-left corner, it is not necessary
to compute leftedge because firstcolumn IS the relevant leftedge.
Reported-by: Jordi Mallach <jordi@debian.org>
When the screen is narrower than a tab is wide, the cursor does not need
to be on the first/last line of the window before an <Up>/<Down> could
need to scroll the screen.
This fixes http://savannah.gnu.org/bugs/?51776.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Check the column number, not the character index, when suppressing the
line number on chunks other than the first, since the index can be zero
when in fact we're on a later chunk.
This fixes https://savannah.gnu.org/bugs/index.php?51790.
Using do_up() and do_end() when the user types <Left> at the start of
a line, and do_down() and do_home() when typing <Right> at line's end
can be problematic when tabs are wider than the screen, because those
functions convert indexes to columns and back again twice, thus causing
inaccuracies. Therefore, simply adjust current and current_x directly,
and then redraw the screen.
This fixes https://savannah.gnu.org/bugs/index.php?51778.
The preceding 'for' loop has already established that all the lines are
either unindentable or composed of only blanks. So if now a line cannot
be unindented, it means it is fully blank, so it can be simply skipped.
This fixes https://savannah.gnu.org/bugs/?51760.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Also, only unindent when all selected lines can be unindented,
which means that the relative indentation will be preserved.
For this purpose, it ignores empty lines and lines consisting
of only whitespace.
When unindenting is not possible, a message is shown.
This fixes https://savannah.gnu.org/bugs/?47684.
Instead of inserting the extra whitespace after the current indentation
of a line, add it to the start of the line. This causes a fixed amount
of visual whitespace to be added regardless of whether --tabstospaces
is used or not.
This fixes http://savannah.gnu.org/bugs/?51438,
and its ancestor https://savannah.gnu.org/bugs/?51408.
So that these functions have bindings by default, and easy bindings.
Add them to the help viewer too, so that searching backward becomes
possible there.
Tabs are of variable length depending on position, so allow them
to be displayed partially on one chunk and partially on another.
This fixes http://savannah.gnu.org/bugs/?51621.
Adding text plus whitespace while the cursor is at or near the topleft
corner of the edit window can cause a change in the preceding chunk,
throwing firstcolumn out of alignment. Catch this special case.
This fixes http://savannah.gnu.org/bugs/?51743.
It would be horrible if the user expects to find numbered backups
of all the files that were changed but they are NOT there because
the config file contains a typo or the relevant directory was moved
or renamed or something. So... if the specified backup directory
is not usable, nano should complain and simply not start up.
Discarding (in commit 6f9bb53b) the cap on the number of chunks to
move backwards had as an unforeseen side effect that the screen can
fail to scroll when the cursor is somehow pushed offscreen.
Fix this by setting the target row (for smooth scrolling) always to
the bottom row of the edit window when nano notices that the cursor
has gone offscreen.
This fixes https://savannah.gnu.org/bugs/?51676.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
The succeeding character was needed to avoid miscolorings due to nano
getting confused about starts and ends. But since commit 7ef5c532,
nano should be getting the starts and ends always right, so... undo
"temporary" commit 7b2ea405 from two years ago.
This addresses https://savannah.gnu.org/bugs/?51526.
Reported-by: <exodus6395@googlemail.com>
The new option 'set selectedcolor' applies to marked text, to the
currently selected file in the file browser, and to the highlighted
match during interactive search-and-replace.
Include the shortcut for 'Uncut' into most menus, and add an uncut
function for the status bar, so that it becomes possible to paste
the first line of the cutbuffer at any text-input prompt.
This fulfills https://savannah.gnu.org/bugs/?48501.
Requested-by: Benno Schulenberg <bensberg@telfort.nl>
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Assume that a linter line that contains an actual error message or
warning includes a colon followed by a space -- something that that
opening message from a modern gcc lacks.
Human column numbers are one-based, whereas x positions are zero-based.
Converting from the one to the other involves subtracting one. But when
the linter message does not provide a column number, the latter defaults
to zero. Catch that case and change the number to one.
This fixes https://savannah.gnu.org/bugs/?51550.
Commit 28beb3f added the 'forreal' parameter to prevent spotlight() from
placing the cursor wrongly due to an invalid placewewant. However, since
the variable-width softwrap overhaul (specifically, since commit 8490f4a),
place_the_cursor() no longer checks placewewant, so the parameter is no
longer needed.
Furthermore, dropping 'forreal' and thus always setting current_y won't
affect the operation of spotlight(), since the only functions that use
spotlight() (do_replace_loop() and do_int_spell_fix()) both call
edit_refresh() beforehand, which means that current_y will already
have been set to the value it will be set to again.
The function place_the_cursor() assumes that the viewport is up to date,
i.e., that current is in range of edittop. When uncutting or inserting,
however, place_the_cursor() gets called on the out-of-date viewport
first, and then a screen refresh is scheduled (which would put the
viewport up to date). This is backwards: the refresh should come before
the cursor placement, and the only reason it works anyway is because the
cap on the number of chunks to move backward papers over the problem by
keeping current_y in screen range regardless.
Fix this properly by simply setting current_y to the bottom row of the
screen instead of calling place_the_cursor(). This value of current_y
is only ever used when in smooth scrolling mode and the insertion (or
paste) pushed the cursor offscreen. In other situations, this value is
overridden when place_the_cursor() gets called after a screen refresh.
After that fix, the cap on the number of chunks to move backward is no
longer needed.
When not using --smooth (nor 'set smooth'), and a line near or beyond
the end-of-file is addressed with the + command-line argument, then
center the cursor, just like Pico does -- so in the default mode,
nano is again more like Pico.
This partially addresses https://savannah.gnu.org/bugs/?51489.
Counting the added number of rows is only relevant when inserting
a file into the current buffer. So don't waste time counting when
it's not needed.
This fixes https://savannah.gnu.org/bugs/?51479.
Since commit 8490f4ac, get_edge_and_target() depends on an up-to-date
current_x. So: make sure current_x is updated when we move to the
top left of the screen to start a non-smooth PageUp or PageDown.
This fixes https://savannah.gnu.org/bugs/?51480.
For some reason, when returning from suspension, SLang will produce
either a clipped error code (0xFF instead of 0xFFFF, when returning
from an externally induced suspension), or it will clip the code of
first subsequent keystroke to a single byte (when returning from a
normal, in-editor suspension: ^Z).
Side-step this by ignoring the clipped error code, and by using an
undefined control code as the first fake keystroke. Ignoring the
clipped error code is not possible when using a single-byte locale,
otherwise the user would not be able to type the character with
code 0xFF (although it could still be entered with Esc Esc 255).
This fixes https://savannah.gnu.org/bugs/?51477.
The help lines need to be redrawn one step after a justification
(whether it has been undone or not, to replace "Unjustify" with
"Uncut" again for ^U), and after switching buffers (to update a
possibly changed tag for ^T).
This fixes https://savannah.gnu.org/bugs/?51455.
The parameter 'cols', that indicates how many columns to indent or
unindent, is changed to be always positive, so the check for being
negative can go. And it could never be zero anyway.
This should eliminate all cases where the newline is pushed off the edge
of the screen in non-atblanks softwrap mode. Also, it allows the use of
the last column of the screen in atblanks softwrap mode when a piece of
text does not contain any blanks.
This avoids the unreachable end-of-line reported on the mailing list:
http://lists.gnu.org/archive/html/nano-devel/2017-06/msg00011.html.
Extend get_softwrap_breakpoint() to break softwrapped lines on
whitespace when a flag is set. This flag is controlled by the new
rcfile option "atblanks". The '>' characters marking two-column
characters at the edge of the screen are disabled when it's on.
If get_softwrap_breakpoint() can't find whitespace in screen range, it
will break the line on the screen edge. (In this case, a blank can be
on the last column of the screen, but text can't, so that a blank on the
last column doesn't become invisible and possibly break the display.)
This fulfills https://savannah.gnu.org/bugs/index.php?49959.
Requested-by: Nicholas Boel <axxisd@gmail.com>
spotlight() now displays softwrapped lines chunk by chunk instead of all
at once. Since softwrapped lines are no longer of constant width, the
latter approach would fail if softwrapping breaks the spotlighted text.
Instead of taking a string, spotlight() now takes the starting and ending
columns of that string. Also, its handling of softwrapped lines is now
split off into a separate function, spotlight_softwrapped().
get_chunk_row() and get_chunk_leftedge() now become wrappers around
get_chunk(); the latter is only used directly in place_the_cursor()
when we need to get both the row and the leftedge. get_chunk() now
uses the proper formula to implement varying chunk width.
Since chunk width now varies, place_the_cursor() sets the x position
relative to the leftedge in a different way that works regardless
of chunk width, update_softwrapped_line() loops until it gets all
softwrap breakpoints instead of calculating the full length in
advance and getting one full row at a time, the chunk iterators
now count leftedges instead of rows, and fix_firstcolumn() does a
full recalculation of the chunk that firstcolumn is on instead of
simply shifting it back.
Also, in update_softwrapped_line(), when a line's softwrap breakpoint
is before the last column of the edit window, a ">" is now added to
the end of it.
The workaround in place_the_cursor() for when two-column characters
straddle the edge of the screen is removed, as it's no longer needed
now that chunks end before such characters.
Furthermore, do_home() and do_end() use xplustabs() instead of
placewewant again when calculating the leftedge, since placewewant
refers to a column that may or may not be available (if it's not,
the cursor will be placed wrongly). Make get_edge_and_target() use
xplustabs() instead of placewewant for the same reason; this also lets
us simplify get_edge_and_target(), since xplustabs() will never be
greater than strlenpt(). Finally, since do_end() now has to calculate
rightedge as well as rightedge_x, use the former to implement the same
time-saving optimizations as in do_home().
The cursor is not yet adjusted when we try to go directly to a column
past the end of a softwrap breakpoint, and placewewant handling in the
vertical movement code is not yet adjusted for varying chunk lengths,
but fixes for these are forthcoming.
This fixes https://savannah.gnu.org/bugs/?49440.
get_chunk_row() replaces the formula "column / editwincols".
get_chunk_leftedge() replaces "(column / editwincols) * editwincols".
get_last_chunk_row() replaces "strlenpt() / editwincols".
get_last_chunk_leftedge() replaces "(strlenpt() / editwincols) * editwincols".
This prepares us for any changes in those formulas, and for more such
functions later.
The new function find_softwrap_breakpoint() returns the column number
of the last position in screen range where we can wrap the given text
without breaking a two-column character in half (as was done until now).
The returned column number is the leftedge of the next softwrapped chunk.
If the end of the text is reached while searching for a wrapping point,
the parameter end_of_line is set to TRUE.
The new function get_chunk() uses find_softwrap_breakpoint() to find the
row and leftedge corresponding to a given column of a given line.
Eradicate the need for backslashes, so that the start of the nanorc
manual becomes true, where it says that quotes inside strings don't
need to be escaped. In the bargain achieve that the empty string
always switches commenting off.
This fixes https://savannah.gnu.org/bugs/?51370,
and fixes https://savannah.gnu.org/bugs/?51394.
This avoids some warnings when compiled with -pedantic:
ISO C forbids comparison of ‘void *’ with function pointer
ISO C forbids empty initializer braces
When the active syntax contains a comment command that specifies the
empty string, this should override the default comment of "#" and
should disable the Meta-3 keystroke.
To achieve this, the comment string is now set by default to "#" for
all syntaxes, so that it will be set when no comment command is given
(including for the "none" syntax), and is unset only by explicitly
specifying «comment ""» in a syntax file.
This fixes https://savannah.gnu.org/bugs/?51355.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
When also --nohelp is active and the terminal is so narrow that the
message that --constantshow displays on the bottom row does not fit,
this causes the cursor to be pushed "offscreen". Some terminal
emulators don't handle this case correctly, and leave the cursor
in an invisible or mistaken position. Compensate for this by
moving the cursor back to the start of the row.
This fixes https://savannah.gnu.org/bugs/?51335.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
The extra variable is not needed, because when having read from
standard input, the filename will simply be empty. It will not
be empty for any other file that was read.
The dash doesn't have to be the first non-option argument: it can
be anywhere among the filenames -- there can even be multiple ones
(but don't mention this explicitly).
Negative arguments of 'fill' are bright green since a few commits.
So now color all valid numeric arguments in that same style -- the
yellow was hard to see on a dark background anyway.
Also, color a zero tabsize as invalid.
A recent change (8dffb00f) removed this ability. This change restores
it, and also allows reading from standard input multiple times -- maybe
not useful, but it works.
Also when a dash is the first "file" mentioned on the command line,
nano should show this buffer at startup and not the next.
This fixes https://savannah.gnu.org/bugs/?51207.
In the tiny version, Ctrl+Left and Ctrl+Right are available only
in the editor itself and in the file browser.
This fixes https://savannah.gnu.org/bugs/?51173.
The old praxis of calling total_refresh() upon a SIGCONT was confusing,
because the screen would look as if nano had returned from suspension,
but in fact the shell was still active.
Instead of calling total_refresh(), put a no-op key into ncurses' buffer,
so that, when nano actually does return out of suspension (through 'fg'),
this key will be read and discarded, upon which nano will go sit and wait
for the next key, just before which it calls doupdate(). The latter is
all we need to get the entire screen restored.
This also fixes https://savannah.gnu.org/bugs/?51131 for "tiny".
When receiving a SIGCONT, don't call regenerate_screen() directly
but act as if a SIGWINCH occurred. Also insert a dummy key, and
thus let the relevant input routine redraw the relevant subwindows.
Use KEY_F0 as the dummy key, as both Ncurses and Slang know it, and
it should normally do nothing at all.
This fixes https://savannah.gnu.org/bugs/?51124.
When we are in the file browser, browser_refresh() will take care of
redrawing the title bar and the file list, so total_refresh() should
leave those two subwindows alone in that case.
This fixes https://savannah.gnu.org/bugs/?51147.
Achieve this by making the suppression flag global, so that we can
just reset it instead of making an improper call of do_cursorpos().
This fixes the secondary part of https://savannah.gnu.org/bugs/?51134.
It is no longer necessary to assign up() and down() separately for
the help viewer because by now the movement keys have been sorted
in order of ascending stride also in the main menu.
The two string definitions are relocated just to reduce the number
of #ifdefs.
Most of the keywords listed on the following URL are now highlighted:
http://php.net/manual/en/reserved.keywords.php
Also color single-quoted strings, and require that //-type comments
are preceded by whitespace or are alone on a line.
With-feedback-from: M <taur@mail.com>
When spotlighting the string to be replaced, placewewant isn't valid,
so tell place_the_cursor() to ignore its value to avoid the cursor
getting mistakenly placed at the beginning of the next row.
This fixes https://savannah.gnu.org/bugs/?50997.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
When the column given in gotoline() is beyond the last available
column in the row of the last chunk, then set placewewant to the
actual end of the chunk, to prevent surprising jumps to the left
when moving up or down from there.
This fixes https://savannah.gnu.org/bugs/?50995.
Whenever 'make' is run, it should check whether the revision has
changed, and if so, it should update src/revision.h.
This portable FORCE mechanism should have been the replacement for
the phony target that was removed in a33a4f00, five commits ago.
This fixes https://savannah.gnu.org/bugs/?50956 in a better way.
Instead of always stepping back four bytes and then tentatively
moving forward again (which is wasteful when most codes are just
one or two bytes long), inspect the preceding bytes one by one
and begin the move forward at the first valid starter byte.
This reduces the backwards searching time by close to 40 percent.
Also when toggling the help lines back on or the extra editing space
back off, keep the cursor near the bottom of the screen if it /was/
there, instead of centering it -- if smooth scrolling is on, that is.
This supplements the fix for https://savannah.gnu.org/bugs/?50933.
When the editing space gets narrower, either by toggling line numbers on
or making nano's window smaller, and when the cursor is near the bottom,
it can be pushed offscreen. In that case, don't get it back onscreen by
centering the current line but by putting it on the bottom row. This
makes for a smoother experience.
This fixes http://savannah.gnu.org/bugs/?50933.
And hide the cursor again as soon as the user scrolls.
Achieve this through making the 'didfind' variable global.
Also, remove a superfluous call of wnoutrefresh(), as bottombars()
already does that.
This fixes https://savannah.gnu.org/bugs/?50918.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
The bottomwin has just been refreshed by update_the_statusbar(),
and it should not be the responsibility of the prompt routines
to keep the edit window up to date, as they don't write anything
there.
Things have morphed over time and display_buffer() no longer actually
displays the buffer -- it just displays the title bar, precalculates
the multiline color info, and schedules a refresh of the edit window.
If the length of the haystack is smaller than the length of the needle,
this means that also the length of the tail will be smaller -- because
pointer will be bigger than or equal to haystack -- so the pointer gets
readjusted to be a needle length before the end of the haystack, which
means that it ends up /before/ the haystack: thus the while loop will
never run.
On average, this saves some 200 nanoseconds per line.
This avoids https://savannah.gnu.org/bugs/?49912 while at the same time
avoiding to draw the edit window twice in a row -- the first drawing
would use a wrong margin, which results in a visible and irritating
shift left or right of the content upon the second drawing.
This fixes https://savannah.gnu.org/bugs/?50877.
We should measure the length of each /translated/ shortcut description,
not of the original English one.
This fixes https://savannah.gnu.org/bugs/?50899.
An iterator should not be called "start_col", because it is only the
starting column at the very beginning.
Also, start_col (after the rename) can never be /larger/ than column.
Since the help text is searchable, an <End> would go to the end of the
text but would leave a blank line above the statusbar -- a blank line
that wasn't there before, and that is not reached when simply holding
down <Down> all the way from the top.
When nano has multiple files open, closing a help buffer should
not switch to the next buffer in the ring but to the preceding one,
because it was from there that the help screen was invoked.
However, prefer moving the starting point of the text backwards over
moving it forward, so that of the same paragraph more text is shown
instead of less. But scroll an empty line out of view -- no text is
"lost" then.
Allow the user to search in a help text with ^W and M-W.
Achieve this by not writing the help text directly to the screen
but first writing it to a temporary file and then opening this file
in a new buffer, and treating it specially: the normal file-reading
feedback is suppressed, the titlebar shows the headline of the text,
the cursor is hidden, and the menu is limited to just the up and down
movements and searching.
This fulfills https://savannah.gnu.org/bugs/?28994.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Call something a buffer when it refers to a linked list of linestructs,
and call something a linestruct when it is a struct that describes a
single line.
File formats, appending and prepending, and backups are not available
when --enable-tiny is used, so prevent all relevant pieces of code from
getting compiled. And correct two misspelled ENABLE_TINY to NANO_TINY.
The cursor needs to be placed in its proper spot in the edit window
/only/ when nano is about to accept input from the user and needs to
show where this input will go.
(This might cause a scrolling issue to appear, because reset_cursor()
does not just place the cursor, it also recomputes current_y, which
is used in several places to determine whether and how much to scroll.
If it so happens, we'll deal with that fallout later.)
This also groups ^I and ^M together, and cutwordleft and cutwordright
(when they are bound). It furthermore makes that less pairs are now
mixed and instead consist of either two Ctrl or two Meta combos. In
short: it looks better in the default config. The only sacrifice is
that Verbatim is now split off from the other "inserting" keys.
When the user chooses not to open a file that some message refers to,
remove all messages for that file from the linting results, so the user
does not get asked about that same file again.
This fixes https://savannah.gnu.org/bugs/?47130.
The interval 2013-2017 for the Free Software Foundation is valid
because in those years there were releases with changes by either
Chris or David, and the GNU maintainers guide advises to mention
a new year in all files of a package, not just in the ones that
actually changed, and be done with it for the rest of the year.
To make dynamic Home and End work properly when double-width characters
straddle a chunk boundary, use the spot where the cursor is really shown
instead of the "actual x" position of the current character, because the
latter might be on the preceding row.
This fixes https://savannah.gnu.org/bugs/?50737.
On some terminal emulators, Ctrl+Home and Ctrl+End produce special
keycodes, distinct from plain Home and End. Make the users of those
emulators (and of the Linux console) glad by making ^Home and ^End
do the obvious thing, and the combinations with Shift too.
When Enter is pressed while the cursor is exactly on the current
indent width, remove the blank characters on that line to avoid
creating a line that consists only of trailing whitespace.
(When Enter is pressed somewhere in the middle of the blanks,
however, the whitespace is preserved.)
Suggested-by: Florian Zeitz <florob@babelmonkeys.de>
When a multi-column character straddles a chunk boundary, and the
preferred column (placewewant) for the cursor is zero, cheat: show
the cursor not where the character starts but on the beginning of
the next row. This makes the cursor move smoothly in the leftmost
column of the screen when using <Up> and <Down> and such, instead
of jumping around.
In this way the scrolling logic won't get confused and the screen
will scroll properly when stepping beyond the top or bottom row.
This fixes https://savannah.gnu.org/bugs/?50687.
If we're using the bundled gnulib regex module, then assume REG_ENHANCED
is not supported (since gnulib doesn't support it).
This fixes https://savannah.gnu.org/bugs/?50714.
When UTF-8 is available, use actual arrows instead of untranslated words
to indicate the cursor keys. This was already done for the combinations
with Ctrl but not yet for the plain cursor keys.
The unshifted shortcuts are easier to type, and also less confusing in
my eyes. Putting them first means they get shown in the help lines,
and get listed first in the ^G help text.
(I would also like to put ^- first instead of ^_ (because the latter
is hard to see when using the default inverse video for shortcuts),
but on several terminal emulators Ctrl+- reduces the font size.)
Use futimens() instead of utime() to change the timestamps on a backup
file. Otherwise, a non-privileged user could create an arbitrary symlink
with the name of the backup file and in this way fool a privileged user
to call utime() on the attacker-chosen file.
Import the relevant gnulib module to make sure futimens() is available.
If we're using the bundled gnulib regex module, then assume word boundary
support is available to avoid issues with the regcomp test. This also
unifies the different code paths a bit.
This fixes https://savannah.gnu.org/bugs/?50705.
If edittop is partially offscreen before we scroll, and it gets
scrolled more offscreen, we do need to compensate for the chunks
between firstcolumn and leftedge -- that is: the chunks between
the top row and the cursor row.
This fixes https://savannah.gnu.org/bugs/?50691.
When a two-column character cannot be shown because it straddles the
boundary between two chunks of a line, show the '>' placeholder for
its left "half", and '<' for its right "half".
This mitigates https://savannah.gnu.org/bugs/?49440.
Remove some things we're never going to do: allowing to replace
newlines, a regression framework, characterset conversions, or
jumping to various screen lines.
The number of rows to draw shouldn't be compensated for the chunks
of edittop that are before firstcolumn, because they are offscreen.
This completes the fix for https://savannah.gnu.org/bugs/?50621.
There is no need to always increase nrows by 1 or 2 -- an increase
of 1 is only needed when the line that borders on the scrolled region
needs to redrawn too: when this line was horizontally scrolled or when
the mark is on.
This fixes https://savannah.gnu.org/bugs/?50621.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
The complementary test on current_y should only be done when doing
a scroll-only, because only then the prior line can be offscreen.
This fixes https://savannah.gnu.org/bugs/?50658.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
When scrolling backward, it is not just the bottom line of the screen
that doesn't need to be redrawn: also the line /before/ the top line
doesn't need a redraw. Mutatis mutandis for scrolling forward.
This fixes https://savannah.gnu.org/bugs/?50657.
When determining the leftedge of the current chunk, it is not simply
the leftedge that corresponds to the placewewant, but the leftedge that
corresponds to the minimum of the placewewant and the full line span.
This fixes https://savannah.gnu.org/bugs/?50653.
When typing PageUp or PageDOwn in non-smooth-scrolling mode, the cursor
should be placed at the start of the top line of the edit window. This
means that, when the line at edittop is partially scrolled offscreen,
the cursor should be placed at openfile->firstcolumn, not at zero.
This fixes https://savannah.gnu.org/bugs/?50645.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
The iswspace() was only used when iswblank() was missing. The latter
is now provided by gnulib, so it is always available, so iswspace()
is not used at all anymore.
Mention the ability to use <Tab> in the search history, the ability
to restore the cursor position when reopening a file, the ability to
read output of a command, and the lack of file-managing commands in
the file browser.
The "./" is a shorthand for "current working directory".
It is better to specify it, because it differs from what
Pico does: reading always from the user's home directory
no matter where the editor was started.
Only use the "from" thing when an operating directory is in effect,
because /only/ then the indicated directory can be something other
than "./".
Also, make it so that there is no space before the colon.
Put all the movement keys together, in order of ascending stride.
Also, move the Undo/Redo keystrokes further up, so that, when the
user has a somewhat wider terminal than the usual 80 characters,
these keystrokes will be shown -- they are far more interesting
than the ^Y and ^V ones, for which PgUp and PgDn can be used.
If the number of columns in the edit window changes (which currently
only happens in two places: in regenerate_screen(), called when the
window is resized; and in main(), when line numbering mode is toggled),
the display will break if we're in softwrap mode and firstcolumn is
nonzero. This is because the column width of softwrapped chunks has
changed, and firstcolumn is no longer the starting column of a chunk,
an assumption that all code using firstcolumn relies on.
To fix this problem, add a new function, ensure_firstcolumn_is_aligned(),
to adjust firstcolumn to the starting column of the chunk it's on, and
use it when the number of columns in the edit window changes.
(Note that this function uses the simplest possible fix, and could
probably be made more sophisticated.)
In do_replace(), replacing text may change firstcolumn if the next match
is offscreen, and replacing text after that will not change it back. In
order to keep the viewport unchanged, we have to save and restore not
just edittop, but firstcolumn as well.
In do_int_spell_fix(), spell-checking text may change firstcolumn if
the next match is offscreen, and spell-checking text after that will
not change it back. In order to keep the viewport unchanged, we have
to save and restore not just edittop, but firstcolumn as well.
In do_justify(), justifying text may change firstcolumn if the paragraph
ends offscreen, and unjustifying the text again will not change it back.
In order to keep the viewport unchanged, we have to save and restore not
just edittop, but firstcolumn as well.
Copying text involves first cutting it and then quickly pasting it back.
However, cutting the text may change firstcolumn if the mark is offscreen.
To keep the viewport unchanged, copy_text() has to save and restore not
just edittop, but firstcolumn as well.
Now that we can add text to the bottom right corner of the screen
without scrolling the full line onscreen, do_output() needs to refresh
the screen in that case, since it would put the cursor offscreen
otherwise. Accomplish this by borrowing logic from do_right().
In do_up() when scroll_only is TRUE, if we're at the top of the screen
in softwrap mode, it's not enough to check that edittop is on fileage.
We also need to check that firstcolumn is zero.
In do_up() when scroll_only is FALSE, if we're at the top of the screen
in softwrap mode, current_y should be zero. This is equivalent to how,
in do_down() when scroll_only is FALSE, current_y is (editwinrows - 1)
at the bottom of the screen in softwrap mode. Since edittop can now
be partially scrolled off the screen even when it takes up the entire
screen, checking for edittop's being equal to openfile->current->next
there no longer applies.
The new function, update_softwrapped_line(), is called from inside
update_line() when softwrap mode is on, so that existing calls remain
unchanged. It takes no index, instead displaying edittop from column
firstcolumn, and all other lines from column zero.
If current is on edittop, it's displayed using the edittop rules, but
this is not a problem: if current[current_x] is above edittop at column
firstcolumn, it's offscreen, and that should be handled before calling
update_line() anyway.
Together with the preceding bunch of changes,
this fixes https://savannah.gnu.org/bugs/?47667.
Make current_is_above_screen() check for current[current_x] being above
edittop at column firstcolumn, and make current_is_below_screen() start
counting down from edittop at column firstcolumn instead of edittop at
column zero. This means that both functions now account for softwrapped
chunks properly.
Actually enable scrolling edittop partially off the screen by making
edit_scroll() and adjust_viewport() use firstcolumn properly when
iterating through softwrapped chunks in softwrap mode, or lines in
non-softwrap mode.
In non-softwrap mode, firstcolumn should still always be zero, because
it's initially set to that, and because passing it through the iterators
will maintain it at that.
This fixes https://savannah.gnu.org/bugs/?49100.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
We want to be able to scroll the line at edittop partially off the
screen. For this to be possible, the new variable firstcolumn stores
the starting column of the viewport -- the starting column in the line
that edittop points to.
Since firstcolumn is used by go_back_chunks() and go_forward_chunks(),
it can't be completely #ifdefed out when NANO_TINY is set, but outside
of softwrap mode it should always be zero.
Currently firstcolumn is initialized to zero, reset to zero when
toggling softwrap mode off, and reset to zero when switching buffers
while softwrap mode is off. It's otherwise unused, but its uses are
forthcoming.
Since all lines can be partially scrolled off the screen now
(except for the top line of the edit window, which is forthcoming),
ensure_line_is_visible() is no longer needed.
Since all lines can be partially scrolled off the screen now
(except for edittop, which is forthcoming), the maxlines global
variable and its computation mechanism are no longer needed.
Use go_back_chunks() and go_forward_chunks() to move a screenful of
lines or chunks up or down, instead of using special computations in
the softwrap case.
Use go_back_chunks() and go_forward_chunks() in do_up() and do_down()
(instead of using a special and complicated computation in do_down())
so that they now properly move vertically to the previous/next chunk
in softwrap mode. This also means that do_left() and do_right() will
now properly move vertically at actual line boundaries.
Use the new "unclever" functionality of Home and End to make do_left()
and do_right() move properly to the end of the previous chunk or to the
start of the next chunk in softwrap mode when crossing a line boundary.
(Furthermore, doing Up plus End, or Down plus Home, does all needed
screen updates, which simplifies the code.)
The do_left() and do_right() functions don't yet properly move vertically
at line boundaries, but that will be fixed once do_up() and do_down() are
updated for softwrap mode, which is forthcoming.
This fixes https://savannah.gnu.org/bugs/?49384.
Add the parameter be_clever to both functions. When be_clever is FALSE,
smart home and dynamic home are disabled in do_home(), and dynamic end is
disabled in do_end(), so that these functions only move to the beginning
or end of the current line or chunk.
This simple home and end functionality is needed to improve do_left()
and do_right()'s horizontal behavior with softwrapped chunks, which is
forthcoming.
Make do_end() more useful in softwrap mode: let it move to the end of the
current chunk instead of the end of the line; only when already at the end
of a chunk, let it move to the end of the line. This is "dynamic end".
Make do_home() more useful in softwrap mode: let it move to the beginning
of the current chunk instead of to the beginning of the whole line; only
when already at the beginning of a chunk, let it move to the beginning of
the line. This is called "dynamic home'.
The above rules are ignored when --smarthome is in effect and the cursor
is somewhere in the leading whitespace of a line -- then the cursor is
moved to the first non-whitespace character of the line.
These improvements will eventually make do_home() and do_end() take
parameters. Since the global function lists can hold only functions
without parameters, preemptively add do_home_void() and do_end_void(),
and make the global function lists use them.
Use go_back_chunks() and go_forward_chunks() to move from the row
current_y is on to the row mouse_row is on. Now softwrap mode and
non-softwrap mode will behave the same way when we can scroll edittop
partially off the screen, which is forthcoming. Accordingly, remove
the call to ensure_line_is_visible(), as it no longer applies.
The old code did work, but it behaved differently between softwrap mode
(which counted down from edittop) and non-softwrap mode (which counted
up or down from current_y to take less time, and used a double loop to
keep current from going to NULL).
The new code counts up or down from current_y in both softwrap mode and
non-softwrap mode. In non-softwrap mode, it also avoids the double loop,
since go_back_chunks() and go_forward_chunks() keep the filestructs they
operate on from going to NULL.
Use go_back_chunks() to adjust edittop, instead of special casing
the computation of goal when softwrapping. Now softwrap mode and
non-softwrap mode will behave the same way when edittop can be
partially scrolled off the screen, which is forthcoming.
(Note that the top line of the screen can't be partially scrolled
yet, so we have to work around that for now.)
Use go_back_chunks() and go_forward_chunks() to adjust edittop and to
move up or down to the scrolled region before updating the rows there.
Now softwrap mode and non-softwrap mode will behave the same way when
we can scroll the top line of the screen partially off the screen,
which is forthcoming.
(Note that the top line of the screen can't be partially scrolled yet,
so we have to work around that for now.)
Not drawing a line on a row if we're on the top row and scrolled down,
or if we're on the bottom row and scrolled up, will only work properly
if the line on that row takes up only that row. The latter might not
be the case in softwrap mode: if the line occupies multiple chunks and
begins on that row -- in that case none of the chunks would be drawn.
Add the new functions current_is_above_screen() (which doesn't account
for softwrapped chunks yet, but will when we can scroll edittop partially
off the screen, which is forthcoming), current_is_below_screen() (which
determines whether current[current_x] is past the softwrapped chunk at
the bottom of the screen), and current_is_offscreen() (the union of the
previous two functions).
edit_redraw() and edit_refresh() now use current_is_offscreen() to check
whether they should adjust the viewport, and adjust_viewport() now uses
current_is_above_screen() to determine whether current is on or below
the screen in FLOWING mode.
Add the new function less_than_a_screenful() to accomplish this.
It uses go_back_chunks() to count the number of softwrapped chunks
between the end point and the starting point of the paste.
Now softwrap mode and non-softwrap mode behave the same way when
uncutting fewer than editwinrows rows of text. Accordingly, remove
the call to ensure_line_is_visible(), as it no longer applies.
Use go_forward_chunks() to count softwrapped chunks between the current
cursor position and the bottom of the file. Now softwrap mode and
non-softwrap mode behave the same way when moving to a line and column
non-interactively, instead of the former's always centering the screen.
These functions, go_back_chunks() and go_forward_chunks(), take a number
of softwrapped chunks (screen rows) to move, a pointer to a buffer, and
a location (specifically, a starting column of a softwrapped chunk). If
they move successfully, they will update the buffer pointer and location
to point to the beginning of the softwrapped chunk they moved to.
Since non-softwrap mode is effectively just a subset of softwrap mode
in which every line takes up one chunk, these functions also work in
non-softwrap mode. In this case, their starting column will always be
zero, as it would be in softwrap mode on a line that takes up one chunk.
Nothing uses these functions yet, but that is forthcoming.
Instead of redetermining the entire span of the converted string,
simply move one character left, and then bite it off to make place
for the trailing $.
If the last two columns of a row would be taken up by a double-width
character (and the line is longer than that), don't print it, because
it wouldn't leave any room for the $ character.
This fixes https://savannah.gnu.org/bugs/?50491.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
On a system with up-to-date GNU tools, this does not change
the size of nano's binary.
We start off with importing only a few modules, although we
don't yet delete the fallback logic for them.
The gettext-0.18.3 release was made in Jul 2013, while the 0.11.5
release was made in Aug 2002. Time to update :).
Also drop all the bundled gettext m4 files. When you run autogen.sh,
these will get copied in automatically for you.
The autoconf-2.69 release was made in Apr 2012.
The automake-1.14 release was made in Jun 2013.
Update the requirements so we know we can rely on macros/features
available in those versions.
The mark only needs to be off when calling replace_marked_buffer(),
because this indirectly calls ingraft_buffer(), which fiddles with
the end points if the mark is on.
Running strlenpt() on a string that takes up more than 80 columns
(the width of an average terminal) takes /more/ time than simply
converting an extra character (the one that will be overwritten
by the "$" at the edge of the terminal). So... just convert one
more character than necessary when the line is overlong. In the
most common case, however, the line will fit fully onscreen, and
we save a whole call of strlenpt().
Since we only need span columns of the string, stop scanning the string
as soon as we have that many columns, instead of scanning the string all
the way to the end. This speeds up the conversion of very long lines.
Replace partitioning with calls to extract_buffer() and ingraft_buffer().
In addition to pasting the unjustified text back into the buffer at
current[current_x], ingraft_buffer() also deals with renumbering and
updating totsize, so do_justify() doesn't need to do those anymore
when unjustifying.
With read_file() revamped, it now uses partition_filestruct() indirectly
via ingraft_buffer(), so we can't use partition_filestruct() to replace
marked text in the alternate spell checker anymore without segfaulting.
Add the new function replace_marked_buffer() to accomplish this instead.
Based on replace_buffer(), it uses extract_buffer() to throw away the
marked un-spell-checked text, and then uses read_file() to insert the
spell-checked text at the position where the mark was.
Accordingly, remove unneeded partitioning and related stuff from
do_alt_speller(). Besides pasting the file into the buffer at
current[current_x], ingraft_buffer() also deals with renumbering,
updating totsize, and handling a magicline, so do_alt_speller()
doesn't need to do those anymore.
Move buffer handling and '\r' stripping from read_line() to read_file(),
so that the file gets its format determined and gets stored in its own
buffer entirely in one function. Then use ingraft_buffer() to insert
this new buffer into the current one.
In addition to pasting the file at current[current_x], ingraft_buffer()
also deals with renumbering, the updating of totsize, and the handling
of a magicline, so read_file() doesn't need to do those anymore.
Note that all this makes read_file() depend on the position of
current[current_x] to know where to insert the file. Accordingly,
set current_x to zero in initialize_buffer_text() instead of in
make_new_buffer(), so that replace_buffer() keeps working properly.
Add its explanation as a separate paragraph.
Also: improve the argument of the --syntax option, as this is a <name>
and not merely a bundle of characters like the other <str> arguments.
In this last loop of break_line(), the pointer 'line' is one step ahead
of the index 'lastblank'. So the loop should first add the length of
the preceding character to 'lastblank' before determining the length
of the current character (and using this to advance 'line').
(There is something wrong in the last loop: line is one character ahead
of lastblank, but the current character length is added to both of them.
It thus assumes that all blank characters are the same number of bytes.
For spaces and tabs this works fine. But for more exotic blanks...)
Also, rename a parameter to be less cryptic, and remove an entire
condition because the relevant block will never be reached when
getting called from the help routines: if blank_loc is negative,
the function will have bailed out in the preceding if.
In softwrap mode, the entire line is onscreen, so the word is never
partially offscreen, so we always have enough columns to show it.
This fixes https://savannah.gnu.org/bugs/?50389.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Instead of allocating enough space to convert the entire passed string,
just allocate space for converting the part that will be converted --
that is: starting from start_index. This still allocates far too much
(if the passed string is very long and its tail part won't fit on the
screen), but it's better than before.
Cap the number of pauses when displaying ALERT messages, to avoid
making the user wait for ages when tens or hundreds of files were
specified on the command line.
This fixes https://savannah.gnu.org/bugs/?50362.
Reported-by: Mike Frysinger <vapier@gentoo.org>
When in softwrap mode, no "$" continuation characters are displayed,
so the code that reserves space for them should be skipped then.
This fixes https://savannah.gnu.org/bugs/?50335.
As a small service to the user, reject empty regex strings,
because an entirely empty regex simply doesn't make sense.
Inspired-by: Elia Geretto <elia.f.geretto@gmail.com>
When the marked region covers only a single line (or a part of it),
its new endpoint is not simply the length of the last line of the
spell-checked text, but instead the old endpoint plus the /change/
in length.
This fixes https://savannah.gnu.org/bugs/?50316.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
The previous code only directly refreshed the screen when the margin
changed due to toggling line numbering on. When the margin changed
due to toggling it off, it would indirectly refresh via do_toggle().
When replacements are made, nothing needs to be reset any more
(it was done insufficiently anyway). Just make sure the screen
is refreshed when all is done -- this may be superfluous when
doing interactive replacements, but not when replacing all.
When coloring a line, look only at the multidata of the preceding
line, and based on that determine what to seek in the current line.
This fixes https://savannah.gnu.org/bugs/?50292.
When painting a line, the multidata of the line /before/ it is valid
in most cases: it was determined just a moment ago. And it tells us
all we need to know: whether there is an unpaired start match before
the current line or not.
The only exception is when painting the first line of the screen:
the multidata of the line before it might be stale. So for the
first screen line we will always have to do some backtracking.
But that is left for later.
This fixes https://savannah.gnu.org/bugs/?50121.
If we're somewhere deep into the file and do a spell check, and the
first misspelled word happens to be right there, onscreen already,
then this word does not need to be centered -- it /should/ not be
centered. We should scroll only when necessary.
After the changes to the search routine, it is no longer necessary to
take one step back before starting a replacement session.
This fixes https://savannah.gnu.org/bugs/?50147.
Even when a match falls within the marked region, this does not mean
that it is a true match when already the whole file has been searched,
because then this is the second time we find this match.
This fixes https://savannah.gnu.org/bugs/?50158.
The spell fixer does not provide a beginning line, so the search routine
should then not try to refer to any data of this line. Also, since the
changes to the search routine there is no need any more to retreat one
step before starting to search for a misspelled word.
This fixes https://savannah.gnu.org/bugs/?50159.
That is: remove the special treatment of BOW anchors, and instead make
regexes match against the whole line instead of against an artificially
shortened one, because the latter method creates ghost matches: matches
at the starting point of the search that aren't really matches when seen
in the context of the whole line.
This fixes https://savannah.gnu.org/bugs/?50030.
When the tail of a match falls outside of the marked region,
it is in fact not a match and should not be replaced.
This fixes https://savannah.gnu.org/bugs/?50136.
When a replacement happens right at where the cursor sits, the position
of the cursor should not be adjusted, because the real cursor position
is between the current character and the preceding one: the place where
the cursor is shown is in fact right /after/ the insertion point.
This fixes https://savannah.gnu.org/bugs/?50134,
and fixes https://savannah.gnu.org/bugs/?50135.
Just assign the 'CNONE' value upfront, instead of figuring out
at the end of the line whether anything has been assigned yet.
Also, the old logic would leave unmarked a line that contains a
start match without any terminating end match. Not serious, but
not right.
Don't blithely overshoot the end of a line when both start regex and
end regex match an empty string. Overshooting would let the matching
run on into uncharted country and thus ultimately cause a segfault.
This fixes https://savannah.gnu.org/bugs/?50056.
Reported-by: Elia Geretto <elia.f.geretto@gmail.com>
During precalculation and in step_two, we begin looking for an end
match only after the full start match, not merely one byte beyond
its starting point. So do that too when searching backward for an
unpaired start match.
Also, index can never be zero here, because if the match was of length
zero, this piece of code will have been skipped by the preceding goto.
So we can always use REG_NOTBOL here.
(That goto is wrong, by the way: https://savannah.gnu.org/bugs/?50078,
but that will follow later.)
A search should start at the place of the cursor, not one step beyond,
so that the non-word boundary between the current character and the next
will be found. Starting one step beyond the current character, as was
done until now, would find the non-word boundary between the next and
the overnext character as the first one.
If the given line is out of range of editwinrows, we don't display it
at all, so we obviously don't display more than one line of it. Thus,
the return value in this case should be zero, not one.
(The mistake becomes visible when you go to the end of a very long line
of double-width characters: the $ will be shown on the right edge, even
though you're already at line's end.)
This reverts commit 16a7fd4b from yesterday.
When there is no end match after a start, it is pointless to look
for any more starts because also they will not have any end match,
so nothing will get painted -- just cut the loop short.
The tiny version can do regex searches nowadays, so the user might use
the \< and \> anchors in their regexes.
This fixes https://savannah.gnu.org/bugs/?50008.
The renamed variable 'index' is not the start of a match (as some comment
mistakenly said), but from where in the line we start looking for a next
match.
Also, use one more goto to allow unindenting a big piece of code, and
shortcircuit two while loops for two more small unindents.
The setting of current_y in copy_from_filestruct() also appears to be
a holdover from the days of a more-common STATIONARY scrolling mode.
do_cut_text() uses the above function when copying text (uncutting
text again right after cutting it). Since the text is effectively
the same afterward, current_y doesn't need to change.
do_uncut_text(), however, does need current_y up to date in one case:
when uncutting a full screen or less' worth of lines, focusing will be
FALSE, and it uses edit_refresh(), so it will use STATIONARY scrolling
mode then. Take a cue from do_insertfile() and call reset_cursor() to
get an updated current_y.
(Note that the check for a full screen or less' worth of lines uses
incorrect values when in softwrap mode, but that's a separate problem.)
undo_cut(), do_redo(), and backup_lines() do not need set current_y
because they all result in edit_refresh() with focusing = TRUE, so
they do a CENTERING scroll which does not need current_y.
It is the misuse of "x_" to mean a column position on screen, and the
misuse of "_col" to mean a character position in a string that causes
this confusion.
All these different "start"s and "end"s are confusing. Use instead
'from_x and 'till_x' to remember which part of the current line is
visible now on screen and is thus represented in 'converted'.
In order to determine the correct multidata for a line that doesn't
have such data yet, the whole line must be examined, not just the
part that fits within the screen width.
This fixes https://savannah.gnu.org/bugs/?49978.
A tag begins not merely with a "<" but it must be followed by an
ASCII alphabetic character or one of "/", "!" and "?".
Further, color all the valid attribute names in red.
That is: only extend the current Del or Backspace undo item when the
cursor is still (or again) at the same spot.
This fixes https://savannah.gnu.org/bugs/?50006.
If the system on which nano is configured does not have the 'makeinfo'
program installed, the prebuilt and packaged nano.info and nano.html
should nevertheless be installed.
Also, the TEXINFOS primary has built-in rules for generating HTML files
from the texinfo sources, so an explicit rule is not needed.
This indirectly addresses https://savannah.gnu.org/bugs/?49969.
Instead of setting openfile->current_y (and wrongly so), just call
reset_cursor() to recompute current_y and place the cursor on that
line (if it is not offscreen).
The search routine begins searching right after the cursor and behaves
as if the line starts there, which means that a beginning-of-word anchor
(\< or \b) will match there also when in fact the cursor is sitting in
the middle of a word. To prevent finding a false match, verify that
for a regex that starts with a BOW anchor the found match is actually
the start of a word.
This fixes https://savannah.gnu.org/bugs/?45630.
Since do_mouse() uses edit_redraw(), openfile->current_y will be
immediately recalculated, so there's no point in changing it now.
Use a temporary variable instead.
The value of sameline doesn't change, so it can be initialized to that.
Since i holds openfile->current_y, it should be ssize_t, not size_t.
And it's better to do the most significant part of a calculation first.
Many of the adjustments of the value of openfile->current_y appear to be
a holdover from the days when certain functions had to account for what
is now called STATIONARY scrolling mode, which depends on the value of
current_y. Remove these adjustement where they are superfluous.
do_para_begin(), do_para_end(), and do_bracket_match() update the screen
through edit_redraw(), which uses either CENTERING or FLOWING scrolling
mode, so their setting of current_y is redundant and useless, as it will
be ignored and then overridden by the next call to reset_cursor().
findnextstr() is called by go_looking() [which calls edit_redraw(), see
above], and by do_replace_loop() and do_int_spell_fix(), which both call
edit_refresh(), which in this case only uses CENTERING scrolling mode
since focusing is TRUE.
(Additionally, the adjustments of current_y in findnextstr() and
do_bracket_match() use incorrect values when in softwrap mode.)
find_paragraph() doesn't need to save or restore current_y, because it
doesn't do any screen updates. do_justify() calls edit_refresh() with
focusing set to TRUE, so it uses the CENTERING scrolling mode.
do_alt_speller() and do_formatter() do not need to save and restore
current_y, because they don't modify it in any way.
This addresses https://savannah.gnu.org/patch/?9197.
This makes nano's cursor behavior consistent across 1) typing text by
hand; 2) pasting in text with ^U; 3) inserting text from a file; and
4) redoing with M-E that same typing or pasting or inserting.
This fixes https://savannah.gnu.org/bugs/?49968.
There are just a handful of source files for the documentation --
it is wasteful and cumbersome to have these in separate directories.
Also: remove the French man pages -- they are too far out of date.
(And anyway, we should acquire a general framework for translating
the documentation.)
The warning is wrong when the user has just saved a buffer under a
new name. And when --quickblank is used, the warning most likely
gets cleared off before it is seen, and the user would just hear
the beep and be left wondering what happened.
This avoids https://savannah.gnu.org/bugs/?49875.
This disallows entering a verbatim ^J (0x0A) when typing text or
search terms, and disallows a verbatim ^@ (0x00) when typing a
filename. Nano beeps when the disallowed code is attempted.
This addresses https://savannah.gnu.org/bugs/?49897.
Also at the yes-no prompt, a 0x0A byte should be displayed as a ^J
instead of splitting the prompt bar in two and spreading it over
two lines.
This fixes https://savannah.gnu.org/bugs/?49934.
After a call to the Formatter or the Alternate spell checker, the data
on the undo stack could refer to line positions that don't exist any
more -- the chance is small, but it is there. So... throw the whole
undo stack away, to prevent undoing things wrongly or even crashing.
(Changes made with the internal spell checker can be undone and redone
without a problem -- nano keeps full track of those. But the changes
made with a formatter or an external spell checker happen in another
process, so nano has no record of them.)
This fixes https://savannah.gnu.org/bugs/?49920.
When using an external spell checker or formatter, the line with
the cursor might become shorter, which might result in the stored
cursor position being beyond the end-of-line. So, when restoring
the x position, make sure to limit it to the length of the line.
This fixes https://savannah.gnu.org/bugs/?49923.
In path names and file names, 0x0A means an embedded newline and
should be shown as ^J, but in anything related to the file's data,
0x0A is an encoded NUL and should be displayed as ^@.
So... switch mode at the two main entry points into the "file system"
(reading in a file, and writing out a file), and also when drawing the
titlebar. Switch back to the default mode in the main loop.
This fixes https://savannah.gnu.org/bugs/?49893.
Decode 0x0A bytes to 0x00 when saving the search history, and encode
them again when reading the file back in, to prevent nano from hanging
or aborting when encountering 0x00 on a line by itself.
After updating the color palette, the corresponding new window content
should be drawn immediately, before some other part of the code calls
doupdate(), to prevent the old content being shown in the new colors.
This fixes https://savannah.gnu.org/bugs/?49912.
Reported-by: Mike Frysinger <vapier@gentoo.org>
In nano 2.7.1 and 2.7.2, pressing Shift+Ctrl+Arrow on a Linux console
would behave as if Shift wasn't held. It got broken three months ago,
by commit 08cd197b, messing up the proper order of the checks.
This fixes https://savannah.gnu.org/bugs/?49906.
On some systems, typing ^C apparently results in a KEY_CANCEL in
the input stream, which gets hard-bound to the do_cancel function.
But in the main menu there is no Cancel function. So... in that
case, let it fall back to the plain old Ctrl-C code: 0x03.
Reported-by: Liam Gretton <liam.gretton@leicester.ac.uk>
A filename might contain spaces, so we can't look for the numbers
(the second and third elements) starting from the head of the line
-- we have to start at the tail and work backward.
This fixes https://savannah.gnu.org/bugs/?49879.
So they will not break a line in the positionlog file in two.
(Strangely, the reading in of such a log file already decodes
nulls back into newlines.)
This fixes https://savannah.gnu.org/bugs/?49877.
The byte 0x0A means 0x00 *only* when it is found in nano's internal
representation of a file's data, not when it occurs in a file name.
This fixes the second part of https://savannah.gnu.org/bugs/?49867.
Most full paths are needed only temporarily and will be freed within
milliseconds. Only 'full_operating_dir' and 'backup_dir' continue to
exist for the whole current session. Any partition, too, will soon be
unpartitioned, so the extra reallocation is just a waste of time.
That is: elide a second test from the most travelled path: a valid
character. This adds a second call of mblen() when parse_mbchar()
is called on a terminating zero, but that should never happen.
The fsfromline() function is mostly used by the undo functions, which
are not present in the tiny version. It is also used by the comment/
uncomment feature, but this feature cannot be enabled when --enable-tiny
is in effect.
Convert digits() to take a ssize_t instead of an int, since it's
used on ssize_t line numbers. And properly use the long modifier
when displaying a line number.
Also, conditionalize the digits() prototype.
An added magic linefeed should be removed again /before/ restoring
the x position, as the latter needs to be calculated from the real
last line of the region.
This fixes https://savannah.gnu.org/bugs/?49817.
Reported-by: Mike Frysinger <vapier@gentoo.org>
When wanting to debug something, it is far more useful
to temporarily insert lines like:
statusline(ALERT, "name = %i", variable);
It provides instant feedback, and it slows things down,
so you can kind of see what happens.
The functions read() and fwrite() take size_t, not ssize_t.
And line numbers in the file should be displayed as a long type instead
of an int, since the effective type of ssize_t is not int, but long.
(The variable 'pletion_line' is not conditionalized with this option, as
it would become messy. The compiler will probably be able to elide it.)
When using --enable-tiny, it is not possible to use --enable-wordcomp,
because the word completion function uses the undo system.
Executing the 'complete_a_word' function will search from the start
of the current buffer for entire words that begin with the fragment
that is before the cursor, and will complete this fragment to the
first word that is found. Each consecutive call of 'complete_a_word'
will search for the next matching word and will complete the fragment
to that. By default the function is bound to the ^] keystroke.
Signed-off-by: Sumedh Pendurkar <sumedh.pendurkar@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Modern VTE-based terminals now produce codes for those keys and
no longer swallow them when nano is active.
This addresses https://savannah.gnu.org/bugs/?49746.
Achieve this by reusing the code that gives feedback when trying to
save a buffer while using --tempfile and the file has no name yet.
This fixes https://savannah.gnu.org/bugs/?48622.
Also for Delete, End, PageUp and PageDown (on some terminals)
the last byte in the sequence needs to be checked.
This fixes https://savannah.gnu.org/bugs/?49710.
If it would, the returned file descriptor would make nano crash,
because the corresponding stream has not been opened. And when
returning zero instead (as the code did originally), nano would
open an empty buffer, although it claims to be reading the file.
In short: I think this is a leftover of an attempted fix of
https://savannah.gnu.org/bugs/?25297, from commit 2823c99.
We should avoid defining color schemes that are unreadable on common
white-on-black or black-on-white terminals. Change the black in the
autoconf error strings to brightred for that reason.
When probing symbols provided by ncurses, use the sublibs that pkg-config
reported in case they're needed (like when libtinfo is a sep library).
URL: https://savannah.gnu.org/bugs/?49614
- make version highlight less blindly greedy and conform to real versions
- move version matching before USE matching to avoid hitting USE flags
that look like versions
- change USE regex to match the Gentoo PMS
- extend arch match to include more keywords
- make category matching more restrictive to avoid false positives
- drop operators =< and => that Gentoo doesn't support
URL: https://savannah.gnu.org/bugs/?49569
Reported-by: Konstantin Shakhnov <kastian@mail.ru>
Otherwise the user can override a 'set nowrap' in /etc/nanorc only
via the command line.
This fixes https://savannah.gnu.org/bugs/?49593 reported by Shirish.
When giving a line number on the command line, do_gotolinecolumn() needs
to know the width of the screen to be able to (roughly) place the target
line in the center of the screen.
This fixes https://savannah.gnu.org/bugs/?49462.
It does not update anything -- it just picks a new point from
where to start displaying the buffer. All actual updating of
the screen is done by edit_refresh() and edit_redraw() and such.
It can be activated with --linenumbers on the command line or with
'set linenumbers' in a nanorc file, and it can be toggled with M-#.
Signed-off-by: Faissal Bensefia <faissaloo@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Returning a zero would mean returning a ^Space -- the keycode that
by default is bound to the Next-Word function. So, unbinding the
keys to which the modified Arrow keys are hard bound would cause
the latter ones to mysteriously jump to the next word.
This partially fixes https://savannah.gnu.org/bugs/?49058.
Add the keycodes and routines to allow the user to forego setting the
mark explicitly (with M-A / ^6) and instead quickly select a few words
or lines by holding down Shift together with the movement keys.
(Some combinations with Shift are swallowed by some terminal emulators.
To work around some of those, the combinations Shift+Alt+Left/Right work
as Shift+Home/End and Shift+Alt+Up/Down work as Shift+PageUp/PageDown.)
This also prevents the message from spilling into the help lines
when the terminal is less than four columns wide. (Not that one
can read anything then, but it looks better.)
Even when the edit window consists of just one or two lines, the PageUp
and PageDown functions (^Y and ^V) should continue to move the window.
This fixes https://savannah.gnu.org/bugs/?48805.
When using the default speller or the formatter, the placewewant is
remembered. So it should be remembered too when the user specifies
a different speller.
(This behavior was inadvertently lost last year, in commit 82d737e.)
It is quicker to do a handful of superfluous compares at the end of
each line than it is to compute and keep track of and compare the
remaining line length the whole time.
The typical line is some sixty characters long, the typical search
string ten characters -- with a shorter search string the speedup is
even higher: some fifteen percent. Only when the string is longer
than half the average line length does searching become slower with
this new method.
All this for a UTF-8 locale. For a C locale it makes no difference.
Now that mbstrncasecmp() does the right thing, there is no need any
more to verify that only a valid multibyte sequence was matched.
(See https://savannah.gnu.org/bugs/?45579 for a test case.)
Also, this will make it possible to search for invalid sequences.
(Currently it isn't possible to enter a search string with invalid
characters, but... a user might edit the search history file. And
if pasting at the prompt is implemented, it will be trivial to enter
invalid sequences if you have a file that contains them.)
Persisting might lead to count 'n' reaching zero, which would mean that
the needle has matched, which is wrong when one of the strings contains
an invalid or incomplete multibyte sequence.
That is: don't run towlower() on the two differing bytes when having
reached the end of one of the strings.
This fixes https://savannah.gnu.org/bugs/?48700.
In the bargain, don't do the conversion to lowercase twice.
Furthermore, persist when encountering invalid byte sequences --
until finding bytes that differ.
The needle is never part of the hay -- it is always a separate string.
(And even if needle and haystack were identical, the routine works fine,
the case does not need special treatment.)
When doing an <Up> on the top line, or a <Down> on the bottom line of
the edit window, the affected lines have already been redrawn by the
scrolling code, so there is no need to do that again.
(However, that does not prevent the second line (or the last-but-one
line) from being redrawn unnecessarily when using the M-- (or M-+)
command elsewhere on the screen and /that/ line is horizontally
scrolled. But we'll let that pass for now.)
For horizontal scrolling, it is not the /desired/ column position that
is relevant for determining whether a line needs to be redrawn after a
cursor movement, but the /actual/ column positions before and after.
This fixes https://savannah.gnu.org/bugs/?48627,
and fixes https://savannah.gnu.org/bugs/?48629.
Leave the rest of any escape sequence to be processed normally, which
should be possible because those characters are all in ASCII range.
This fixes https://savannah.gnu.org/bugs/?48318.
Also, when a key string does not denote a Ctrl nor Meta nor Function key,
there is no point in assigning a keycode, because plain characters cannot
be used as a function shortcut.
And hard-bind the keys Ctrl+Up and Ctrl+Down to these functions.
Unlike the paragraph-jumping code, these new functions disregard
any indentation, treating only blank lines as separators. They
also do an automatic smart home when that option is set.
This fulfills https://savannah.gnu.org/bugs/?48291.
Also, compose the coloring attributes during initialization
instead of every time when painting something.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Instead of referring to a window that might have been deleted by a
resize, just turn the keypad back on for the two windows from which
input might have been requested.
Also: don't insert KEY_WINCH as the verbatim keystroke.
This fixes https://savannah.gnu.org/bugs/?48532.
This allows the user to specify which other characters, besides the
default alphanumeric ones, should be considered as part of a word, so
that word operations like Ctrl+Left and Ctrl+Right will pass them by.
Using this option overrides the option --wordbounds.
This fulfills https://savannah.gnu.org/bugs/?47283.
When the user changes her mind after having pressed Esc, she cannot
unpress Esc, so do that for her by ignoring the escape code when
the subsequent keycode is outside of the normal printable range.
This restores the behavior from before nano-2.3.5 -- except that
Ctrl+Alt+key continues to report an unbound key.
This fixes https://savannah.gnu.org/bugs/?48459.
This prevents many keycode sequences from being misconstrued when a
command key plus other keystrokes accumulate in the input buffer.
This fixes https://savannah.gnu.org/bugs/?48395.
Add them so that <Esc> followed by <Home> will simply do "Home" instead of
reporting an unbound key. The same for <End>, <PageUp> and <PageDown>.
This restores the behavior from before nano-2.3.5.
It is easy to type beside the comma key and hit instead "m" or ".", so
accept also these as a separator between line and column number. And
when being generous anyway, also accept space, slash and semicolon.
This fulfills https://savannah.gnu.org/bugs/?48305.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Precalculation of the multiline color data can be cut short when the
user is impatient and starts typing. But this would drop the first
byte of whatever was typed -- not nice when it was just plain text,
but surprising and worse when the first keystroke was a command.
This fixes https://savannah.gnu.org/bugs/?48388.
When for a multiline syntax-coloring rule the starting regex matches at
the exact same spot as the ending regex, do a second round of resets, so
that reevaluation starts further back and gets a few more things right.
This mildly fixes https://savannah.gnu.org/bugs/?47420.
When we get a ^J as verbatim input, it is not possible to include it
into the file buffer or the prompt answer, because this would mean
adding an encoded null to the buffer or answer, and that is not what
the user intended. One option would have been to simply ignore a ^J
in verbatim input. But the choice has been made to act the same way
as when the ^J (0x0A) is found in the file data: start a new line.
That is the same response as to the Enter key, yes -- but the code
for the Enter key is ^M (0x0D), not ^J. So, to be more precise,
rename the relevant variable from 'got_enter' to 'got_newline'.
When the user tab-completed a name at the Go To Directory prompt, this
name will end in a slash. Remove this slash, so the name can be found
in the file list (where directory names don't include the final slash).
This fixes http://savannah.gnu.org/bugs/?48353.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Invalid multibyte sequences get depicted with the Replacement Character,
and unassigned codepoints are shown as if they were a space. Both have
a width of one.
Just allocate ample space up front and thus discard the delaying 'if' for
each and every character. In most cases this will allocate far too much,
but that hardly matters: it is freed again as soon as the line is printed.
Keystrokes are single integers (aided by the flags meta_key and
func_key) but in the input stream they can be encoded as escape
sequences (a series of bytes). Characters are values in byte
range, but in UTF-8 one character can consist of multiple bytes.
Also rename two variables, because the secondary input buffer
that they refer to contains only characters (mostly just one),
never any shortcuts; and there are too many "kbinput" already.
Also, other messages that are about --operatingdir don't use the term
"confined" either.
Suggested-by: Mario Blättermann <mario.blaettermann@gmail.com>
Don't make it the responsibility of the executed functions to restore
the list of shortcuts of the edit window. Just detect whether another
menu was displayed, and if so, redisplay the main menu.
The way to update nano.pot is to run 'make nano.pot-update' in the po
subdir. Updating a specific PO file is then done with 'make xx.po'.
(The script mistakenly included all leading comments, not just the
ones marked with "TRANSLATORS:".)
It sounded like an instigation to upgrade, or like a list of
instructions on how to upgrade. But it is merely a list of
noteworthy changes -- what other packages put in the NEWS file.
To add a character, one does not need to allocate twice its size.
And the amount to be moved does not depend on the size of the new
character; it just needs to include the terminating zero.
(This fixes in do_output() the same logical mistakes that were fixed
in do_statusbar_output() last February, in acf19bd and 7c0e433.)
Specifying an operating directory should either lead to a successfull
confinement, or nano should fail to start.
(Also: save the terminal settings as soon as possible, so that an early
die() will not restore uninitialized values.)
This fixes the first part of https://savannah.gnu.org/bugs/?47798 properly.
This fixes https://savannah.gnu.org/bugs/?48103.
(The fix is wasteful -- it should only discard the multidata if actually
the name *did* change, *and* if the applicable syntax changed.)
By moving the test for the only situation where do_comment() does nothing
(when only the magic line is selected) further up front, the add_undo()
can be called before the commenting/uncommenting starts and two variables
and an extra function are made unnecessary.
That is: don't mix the number of lines read with a warning about the
file being unwritable -- the former is just convenience information,
the latter is a must-see.
This fixes https://savannah.gnu.org/bugs/?48047.
When running in a non-UTF locale, and when strncasecmp() suffers from
the same defect as strncmp(), make sure not to pass a length with the
high bit set.
This reverts commit df8c3de from six years ago, which prevented a crash
on the Armel/Maemo platforms but causes nano to lose history items.
The strncmp() function on those platforms treats size_t numbers with
the high bit set as if they were zero. To avoid that, use a number
that cannot be seen as negative, as suggested by <alpha@qzx.com>.
This fixes https://savannah.gnu.org/bugs/?48048.
Tested-by: Tito Ragusa <farmatito@tiscali.it>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Store the file sizes from before and after the commenting/uncommenting
in the undo struct, so they can be restored when undoing or redoing.
This fixes https://savannah.gnu.org/bugs/?48062.
Signed-off-by: Mike Scalora <mike@scalora.org>
When opening a file that was edited before, and the remembered position
is near the end of the file, then don't center the target line but show
the last line of the file on the bottom line of the screen, thus showing
as much of the file content as possible.
This addresses https://savannah.gnu.org/bugs/?46243.
Instead of parsing every multibyte character twice, first with
parse_mbchar() and then with mbtowc(), just let mbtowc() do all
the work. This makes searching for a fixed string twice as fast.
This also gets rid of four variables and lots of memory allocations.
(And, more importantly: it stops nano messing up the internal state
of the multibyte-to-wide character conversion, and thus would make
the calls to mbtowc_reset() superfluous.)
This allows for commenting or uncommenting a line or a bunch of lines
with a single keystroke (default binding: M-3). The characters used
for commenting/uncommenting are specified by the active syntax file.
Reviewed-by: Benno Schulenberg <bensberg@justemail.net>
Signed-off-by: Mike Scalora <mike@scalora.org>
Move the initialization of the operating directory to after the
initialization of the screen, so that the above error can be shown.
This fixes the first part of https://savannah.gnu.org/bugs/?47798.
Between the first stat (that sets 'realexists') and the second stat
(directly after), the file might have disappeared, which would mean
that current_stat would be NULL. Prevent dereferencing this further
down.
Only when the user decides not to override an existing lockfile should
loading the corresponding file be skipped. Any failure to write the
lockfile should be ignored -- the file itself should be loaded anyway.
This fixes https://savannah.gnu.org/bugs/?47945.
Error messages about lock files should not get overwritten by purely
informational messages, only by alerting ones.
This fixes https://savannah.gnu.org/bugs/?47963.
The variable 'namecopy' has been passed to dirname(), so it is likely
to have been changed when it contains a slash. So, use a new variable
instead. Also, free the result of display_string().
This fixes https://savannah.gnu.org/bugs/?47956.
Having just opened a fresh buffer, 'openfile->next' will never be NULL,
because the list is circular.
Second, when compiled with --disable-nultibuffer, and deciding not to
override an existing lock, the 'return FALSE' should *not* be skipped,
because otherwise the named file will be opened after all.
This fixes an unreported bug.
Either the selected file was changed, or a file or directory was chosen
(and the Enter key virtually pressed), or a shortcut was executed. So,
just go and read the next key.
This fixes https://savannah.gnu.org/bugs/?47944.
If during startup there are multiple error messages, currently only the
last one remains and can be read. To improve on that, introduce a short
pause between error messages -- even if it's not enough to read them all,
at least the user will be aware that there are multiple ones.
This also causes a few error messages to beep that currently don't beep,
such as when a file is unwritable.
When doing a PageUp or PageDown in the browser, don't move the highlight
to the first line in the same column, but keep it in the same relative
position of the screen. If we're already on the first or last page,
move the highlight to the first or last line, but keep it in the same
column. If we're already on the first or last line, only then move it
to the first or last entry.
CONST_UPDATE is only relevant when in the main menu, not when in the
browser. So, check for that condition, instead of saving, changing,
and then restoring the setting.
There is no need to iterate through all the file names, as we already
know the length of the longest. From this it's easy to calculate how
many names fit on a line.
Also rename some things to be more fitting. And make sure that something
will be selected even when many files, including the selected one, have
disappeared.
When refreshing the screen (and thus the file list), use the prev_dir
mechanism to reselect the file that was selected before the refresh,
to prevent the selection from changing when files were added or deleted.
Also, when the selected name has disappeared, move the highlight one step
back, so that it is obvious that the selection has changed. (Decrementing
'selected' will never make it negative, because selected == 0 means the
'..' entry, and every directory has a '..' entry, so it will be found.)
This fixes https://savannah.gnu.org/bugs/?47812.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
When during searching we look at the keyboard, then don't look at
just the first keystroke, but check if there are more, and if so,
check each one until we find a Cancel -- or until all keystrokes
have been consumed and we can continue.
This fixes the first half of https://savannah.gnu.org/bugs/?47438.
Cancelling a search should restore waiting mode for the keyboard,
just like at the other exit points of the search routine.
And when the input routine has read in multiple keystrokes, it
should not blindly switch back to waiting mode, but only when
that mode was on before.
This fixes the second half of https://savannah.gnu.org/bugs/?47438.
When the terminal is very narrow, there is little point in showing only
part of the version string -- and chewing off one or two digits from the
version number might even give someone a wrong idea. The user is better
served with always showing the full filename, as long as it fits in the
available screen width.
This fixes https://savannah.gnu.org/bugs/?47703.
Also remove the item about one Replacement Character per invalid UTF-8
sequence, because how many bytes form a sequence? Two? Three? Four?
Better just put one Replacement Character per invalid byte, like is
done now.
When fixing a misspelling and not answering 'All' (but 'Yes' or 'No'),
the chance is quite substantial that one will type y or n at the end of
the next word. Diminish this chance by showing for a moment a message
on the statusbar.
Partitioning the file makes the undo system lose track, so that undoing
things has a good chance of losing data. Instead, just make sure that
the region is marked "backwards", with current at the top and the mark
at the bottom, and then let the replace loop take care of not going
outside of the marked region.
This also has the effect that if the marked region fits entirely on the
screen, or all the misspellings are onscreen, then the screen will not
be scrolled at all. Which makes for a smooth experience.
This fixes https://savannah.gnu.org/bugs/?47836,
and fixes https://savannah.gnu.org/bugs/?45573.
Since nano-2.4.1, reading in or pasting a large piece of text would put
the cursor on the bottom line, leaving only one line of the non-read or
non-pasted text visible. This is different from the centering behavior
of Pico, and somewhat disorienting, as you can't see "where you are" any
more in relation to the file as it was.
So now center the cursor whenever the read or pasted text is larger than
the screen, but don't center it when the text fits entirely on the screen.
(The latter avoids the effect of the screen jumping unnecessarily when
inserting just a few lines while the cursor is near the bottom.)
To achieve this behavior: default to focusing, and temporarily set it to
FALSE when the focusing effect is unwanted.
This fixes https://savannah.gnu.org/bugs/?47841.
For some reason the keyboard code seems to assume that all integers
waiting in the keybuffer form a single sequence. But this isn't the
case: when there is an escape (0x1b) among them, then that is where
a new sequence starts. So, prevent the input code from considering
an escape after a non-escape as part of the current sequence.
This fixes https://savannah.gnu.org/bugs/?47839.
When starting to replace misspelled words, pass the actual position
of the cursor instead of the position of the first found occurrence,
so that the cursor position will be updated for changed lengths.
This fixes https://savannah.gnu.org/bugs/?47834.
When verifying that a match is a separate word (during spell checking),
instead of first copying out the word, then passing the word, and then
measuring its length, just pass its length straigtaway.
When we're spell checking, we don't need a special mechanism to detect
we have come full circle: reaching the end-of-buffer means we're done.
So don't bother to reset came_full_circle when we're spell checking
(when begin == NULL) but simply ignore its value.
Add a global variable, 'present_path', so that 'cwd_tab_completion()'
knows where the user is in the browser, so that it can try completions
against names in that directory instead of always against names in the
current working directory (where nano was invoked).
This fixes https://savannah.gnu.org/bugs/?47234.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
The internal spell checker starts searching/replacing always at the top
of the buffer, so reaching the end of the buffer means we're done with
the current search/replace. This prevents the "Search Wrapped" message
from flashing over the statusbar at the end of a spelling replacement.
Commit 8704dde mistakenly removed this part of code -- it is not dead,
it is just that it will only fire when the user answered No at some of
the replacement prompts. So... when we've rereached the starting line,
a found occurrence is invalid when it is beyond the starting x (either
after or before it, dependending on the direction of search).
This fixes https://savannah.gnu.org/bugs/?47816.
Included files are meant to contain only syntax definitions; they may
not set or unset options, nor rebind keys, nor include other files.
This fixes https://savannah.gnu.org/bugs/?47391.
For a little contrast with the function edit_refresh() -- it's
annoying that when you search for the latter you get to see all
the settings of the flag too.
The function edit_update() is called by edit_refresh() itself, so it is
silly that the first sets 'edit_refresh_needed' to TRUE. This setting
is needed only in a few cases -- in the others it's not needed because
the screen does not need to be refreshed (it was just about positioning
the cursor), or 'edit_refresh_needed' has already been set by a call to
goto_line_posx(). So, just set the flag in the five places that need it
and spare the other four calls.
Since commit 41ed690, cancelling a prompt after tabbing would sometimes
leave the list of file names on the screen. When testing this first,
it worked fine -- I was fooled again by 'edit_refresh_needed' already
being TRUE when nano has just started up and sits waiting for the first
key stroke. I have to hunt this down and kill it.
Since commit dac0aa1, nano would leave edittop at current after reading
data from standard input, meaning that everything that had been read in
was invisible, "scrolled off" the top of the screen. Correct this by
explicitly setting edittop.
The above does not happen for ^R (^X) because it has a special mechanism
to save and restore edittop. Nor does it happen for ^R ^X M-F because it
sets current to the top of the file and refreshing the screen will make
edittop follow, or -- in case just one unterminated line was read in --
edittop will already be equal to current.
A normal lock file is apparently 1024 bytes in size, so the second
attempt at reading bytes from the file would try to read 8192 more
bytes into a buffer that has room for only 7168 left. According to
valgrind, the read() function doesn't like that -- and true: if for
some reason the lock file had suddenly expanded, the buffer would
overflow.
This fixes https://savannah.gnu.org/bugs/?47156.
Commit 36ec76a made the wrong change: after a tab that did not list any
file names on the screen, a refresh /is/ needed, because a previous tab
might have listed things on the screen. But at the end of the prompt,
it is not necessary to refresh the edit window if things were listed,
because the window will be refreshed anyway after reading in a file.
Use 'slash' to point at a possible slash, use 'filename' just to
point at the real file name, and use 'wasdirname' just to point at
the dir's name before expanding it in order to be able to free it.
Also, remove two superfluous asserts: 'dirname' cannot be NULL
because it has just been mallocstrcpy'd, and checking 'num_matches'
is pointless as it would crash on the next statement anyway.
This is a remnant from 2001, when things were different. Now, there
is no need to refresh the edit window when tabbing produced no list.
When it did produce a list, it is cleared off later.
If for some reason opening the spell-checked or formatted file fails,
don't throw away the current contents of the buffer.
(It should also give proper feedback about the failure, but we'll leave
that for some other time.)
Also, store the input character earlier, so we don't have to use len - 1.
Furthermore, len increments in steps of 1, so it cannot pass the value of
bufx unnoticed, so use a comparison for equality.
Most of the time NO_CONVERT will not be set, the number of lines will
not be zero, and the format of the file will be zero. Rearrange the
conditions so that they will evaluate as FALSE as soon as possible.
Index i follows almost synchronously the value of len. Since we're
adding characters to the intermediate buffer always only at the end,
just use len as the index.
Until now (when not leaving files unconverted), nano would fumble and
drop the final carriage return of a Mac file, and would thus treat the
last line of such a file as an unterminated line and prepend it to the
current line of the buffer. Correct that, and delete the dead piece
of code that was meant to do this.
This fixes https://savannah.gnu.org/bugs/?47716.
When we don't set edittop in read_line(), we don't need to readjust it in
read_file(), because in that particular case it will still be pointing at
current. And since fileptr is a new, freshly created line, it can never
be equal to filebot, so there is no point in comparing them.
If more than one line was inserted at the beginning of the file, leave it
up to the screen handling to set edittop to what it should be.
Move the setting of fileage a bit down, to its sister setting: the line
at current gets "connected" either to the top-of-file pointer or to the
last line of the inserted file.
The number of lines to scroll is: the y position of the start of the
current line, plus the extra lines that this line occupies, plus the
extra lines that the next line occupies, plus one, minus the y position
of the last window line.
The y position of the start of the current line is current_y -
xplustabs() / COLS, the extra lines are strlenpt(data) / COLS,
and the y position of the last window line is editwinrows - 1.
Note that we first compute the amount to scroll before actually moving
to the next line, because we need the current value of current_x, not
the one that it will have in the next line. The placewewant value is
not good either, because it might be beyond where we actually are.
This fixes https://savannah.gnu.org/bugs/?47665.
Doing a chdir("..") will not fail when the root directory is reached,
and when getcwd() keeps failing too, we have no way of knowing when
to stop. So, simply limit the number of attempted chdirs, to avoid
getting into an endless loop.
This avoids the hang in https://savannah.gnu.org/bugs/index.php?47659.
Reported-by: Chris Renshaw <osm0sis@outlook.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Also, don't force a full refresh of the edit window simply because the
current line needs to be horizontally scrolled. And further, when the
adjustment of edittop has determined that a full refresh is needed,
get out and don't bother scrolling some lines first.
When in softwrap mode and scrolling down a line, and thus going to
do a full refresh, get out and don't bother redrawing the current
and prior lines first.
When moving the cursor up or down one line, redraw the new current
line only when the target column (placewewant) is beyond the screen,
or when the mark is on.
(This still redraws the current and prior lines unnecessarily when
they are in fact shorter than the screen is wide and the mark is off,
but we'll let that pass for now.)
Also, when softwrap is on, we don't have have to redraw the current
and prior lines at all (when the mark is off): they are in full view,
there is nothing to show or hide.
When scrolling down a line, a full refresh of the edit window is only
needed when softwrap is on, because only then the movement is irregular.
When each file line takes up just one screen line (softwrap is off),
edit_scroll() is perfectly able to scroll and redraw only the necessary
lines.
(But... when doing a full refresh anyway with softwrap, why bother
scrolling at all? Why not just adjust edittop and call refresh?)
The old_current line needs to be redrawn only if it differs from current,
and if it wasn't drawn already by the iteration for when the mark is on.
Also make the conditions involving horizontal scrolling more precise.
Instead of saving the current value of placewewant, then setting the
new value, and then passing the old value to edit_redraw() in seven
different places, just let edit_redraw() do this saving and setting.
In the bargain placewewant is now only recalculated when it matters
-- when allow_update is TRUE -- and not when it's superfluous.
Nano doesn't start doing anything with the edit window or the keyboard
until all files have been read in or a blank buffer has been opened, so
the case of openfile->current == NULL will never occur.
Also correct the comment -- because with multibyte characters, it is
very well possible that the screen column corresponding to current_x
is smaller than current_x itself.
Instead of allocating a fixed amount of 128 bytes, which will overflow
and segfault, adjust the allocation to the length of the file name, and
if necessary trim the file name to make the prompt fit on the screen.
This fixes https://savannah.gnu.org/bugs/?47511.
Reported-by: Aapo Rantalainen <aapo.rantalainen@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
In the innermost search loop, don't set placewewant, because this loop
is also used for replacing and spell fixing, when we don't really want
to be there: we are just passing through. Not setting placewewant means
we don't need to save and restore it in those passing-through routines.
The value of placewewant is only relevant when doing cursor movement,
which doesn't happen during replacing nor spell checking, so there is
no need to keep placewewant up to date -- it is set when it matters:
at the end of go_looking().
Stop keeping track of the vertical screen position when searching for
something. If nothing is found, current_y doesn't change, and all the
incrementing/decrementing was a waste of time. If something is found
and it is onscreen, it is easy to calculate the new current_y. And if
something is found and it is offscreen, then current_y is irrelevant,
because we will be either centering the found occurrence (searching)
or putting it on the top or bottom line (bracket matching).
(The above does not take softwrapping into account, but neither did
the old code, so this doesn't introduce any new bugs.)
(Also, when the search wraps, and the viewport is away from head or
tail of the file, and the found occurrence is within the viewport,
then the incremented/decremented current_y would be way wrong, but
this didn't have any adverse effects as far as I could tell. It
seems that current_y is irrelevant in most cases.)
Add a third mode of scrolling, FLOWING, besides CENTERING and STATIONARY.
This is used for word and paragraph jumping (and for bracket matching,
but that worked correctly already), and only when focusing is FALSE.
The new mode prevents the screen from scrolling too many lines when
there are several blank lines at the bottom of the edit window and
the next word or paragraph is out of view.
This fixes https://savannah.gnu.org/bugs/?47194.
On iTerm2 on OS X, the Option+Arrow keys produce special sequences
that start with two escapes. Catch these sequences and interpret
them appropriately as WordLeft / WordRight / Home / End.
Signed-off-by: Mike Scalora <mike@scalora.org>
Signed-off-by: Thomas Rosenau <thomasr@fantasymail.de>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
When finding a misspelled word, the length of the match is simply the
length of that word, and its span in columns is simply the number of
columns that it occupies. Compute it thus directly.
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
When searching for a misspelled word takes a while, and the user
stops this search with ^C, then abort the spelling-checking session.
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
that is taking too long. This fixes Savannah bug #47439.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5776 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
(The measurable effect (during long searches, for example) is zero, though.)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5773 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
an operating directory is not the same as restricted mode.
(In restricted mode, the file browser is not available at all.)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5772 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
invalid escape sequence, and when entering a verbatim keystroke.
But leaving the cursor off during Unicode input, for extra feedback.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5771 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
anyway, and it will be placed back when it's needed: in the main loop.
This prevents a segfault laid bare by r5763: when trying, at startup,
to open a directory, there really is no open buffer yet.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5766 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
variable for a little optimization.
Openfile can never be NULL -- it should have been called openbuffer, and
before we start fiddling with the cursor, we will always have an open buffer.
Edittop might be NULL, but that's okay.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5763 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
a misspelled word twice. And deleting the piece of dead code that was meant
to do this. This fixes Savannah bug #47188.
When we've reached again the same line where we started and we find an
instance there, then this can only be /before or at/ the position from
where we started, otherwise we would have found it when we commenced
searching. And so... that little piece of dead code does absolutely
nothing -- it will never fire.
It's so nice... nano is full of Easter Eggs! :)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5760 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
using it when it's available (which it is on OS X systems).
This completes the fix for Savannah bug #47325.
Patch by Thomas Rosenau.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5759 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
been set to 'answer' in search_init() when 'answer' isn't empty, and when
'answer' /is/ empty we use 'last_search' anyway.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5755 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
deletion of words like the pressing of Backspace/Delete, so they don't
overwrite the lines you cut elsewhere and want to paste into the place
of the cut words.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5751 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and the next time a Search or Replace is run, this answer is overwritten
with an empty string.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5749 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
return with -2 when answer is empty, so when answer is empty
i cannot be zero.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5747 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
We will need this again when one day we make a toggle between
jumping to a directory and searching for a filename fragment,
just like the ^T toggle that exists in the Search / Go-to-line
menus. But for now, we don't need this.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5745 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
functions that could be executed -- other than the line-edition ones,
which are executed under do_prompt(). So the latter won't return
unless either it was cancelled or an answer was given. Also, if it
/had/ returned with a value bigger than zero, it tried to put back
the key sequence for do_gotolinecolumn_void(), which does not exist
in the MBROWSER menu, so this would not have done anything.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5744 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
the idea that it might have something to do with 'end_regex'.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5733 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
non-GNU systems. This is a partial fix for Savannah bug #47325.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5731 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
not for every added color, thus saving some 15 microseconds.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5729 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
a leading underscore as the only difference is not enough.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5726 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
comes first, so that a search can stop at the first match instead of always
having to run through the entire list.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5716 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
instead of the first syntax that matches a certain magic string
(forgotten in the previous commit).
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5705 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
name given on the command line, not from the name of the target file.
This fixes Savannah bug #47307.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5703 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
an rcfile ends or when an invalid syntax command is found.
This fixes Savannah bug #47207
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5696 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
to file extensions, but also to header lines and magic strings.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5690 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
the first element, and the insertion of a new element) directly.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5678 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
And not minding when the column number is zero or negative.
This partially fixes Savannah bug #47131.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5669 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
there is no need to put one in. Just trim the allocation.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5666 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* Add ability to kill the trailing spaces when justifying
code. New nanorc option kill_spaces_on_wrap, we'll see
whether this warrants a command line flahg or not.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5664 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
(Note that openfile cannot be NULL here. And in case it is,
nano should crash because DEBUG is enabled.)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5658 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
when the first Tab added the part that all matches have in common.
So now two Tabs in a row will always show the list of possible
completions -- if there /are/ any completions. Which means that
a second Tab will either: 1) do nothing, when the name is complete
and exists; 2) beep, when nothing in the current directory starts
with the current string; 3) show the list of matches.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5656 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
instead of in the given string. This fixes Savannah bug #47199.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5654 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
history. This fixes Savannah bug #47124 reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5653 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
This fixes Savannah bug #47129 reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5647 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and also when it is the first and only line.
This fixes Savannah bug #47153 reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5646 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
because 'allow_cntrls == FALSE' meant that controls were being filtered.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5644 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
iteration through search matches: showing them centered when found offscreen.
This fixes Savannah bug #47127.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5641 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
needed), so that it no longer shows in the help screen nor in the file list.
This fixes Savannah bug #47126.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5640 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
error messages upon reentry. And, if there are any messages,
allowing the user a little time to read them.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5632 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
With this option, nano would simply refuse to write to any symlinked file;
if anyone really used this option, they would certainly have complained.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5608 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
mentioning how to enter Unicode and that regular expressions are line oriented.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5605 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
This fixes a segfault reported in Savannah bug #47011.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5596 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
of the environment (which can lead to a root-owned .nano/ directory in
the invoking user's home directory). This addresses Ubuntu bug #1471459.
(See https://bugs.launchpad.net/ubuntu/+source/nano/+bug/1471459.)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5580 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
any more, not a SIGWINCH either. And deleting an always-FALSE 'if'.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5577 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
a setting or making an excursion to the file browser.
This fixes Savannah bug #46945.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5576 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
(So that most likely not more than two hundred plus a handful
will be written out. This was the easiest to implement.)
See https://lists.gnu.org/archive/html/nano-devel/2016-01/msg00050.html.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5571 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
This fixes Savannah bug #46904 reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5567 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
There's a bunch of return cases where we don't free the new full filename
which leads to leaks when writing out new files. One way to reproduce:
$ rm -f foo
$ nano foo
<hit enter>
<ctrl+o to save>
<ctrl+x to exit>
-> memory leak
Patch by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5563 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
<ahref="#2.4">2.4. By subversion (for the brave).</a></p></blockquote>
<h2><ahref="#3">3. Installation and Configuration</a></h2>
<blockquote><p><ahref="#3.1">3.1. How do I install the RPM or DEB package?</a><br>
<ahref="#2.4">2.4. By GIT (for the brave).</a>
</p></blockquote>
<h3><ahref="#3">3. Installation and Configuration</a></h3>
<blockquote><p>
<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></p></blockquote>
<h2><ahref="#4">4. Running</a></h2>
<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="#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 shown in the help browser? My keyboard only has F1-F12!</a><br>
<ahref="#4.6">4.6. nano crashes when I type <insert keystroke here>!</a><br>
<ahref="#4.7">4.7. nano crashes when I resize my window. How can I fix that?</a><br>
<ahref="#4.8">4.8. [version 1.3.12 and later] I'm using glibc 2.2.3, and nano crashes when I use color support or do regular expression searches. How can I fix that?</a><br>
<ahref="#4.9">4.9. [version 1.1.12 and earlier] Why does nano show ^\ in the shortcut list instead of ^J?</a><br>
<ahref="#4.10a">4.10a. [version 1.1.12 and earlier] When I type in a search string, the string I last searched for is already in front of my cursor! What happened?!</a><br>
<ahref="#4.10b">4.10b. [version 1.1.99pre1 and later] Hey, the search string behavior has reverted, it's now like Pico, what happened to the consistency?</a><br>
<ahref="#4.11">4.11. How do I make nano my default editor (in Pine, mutt, etc.)?</a><br>
<ahref="#4.12">4.12. I've compiled nano with color support, but I don't see any color when I run it!</a><br>
<ahref="#4.13">4.13. 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.14">4.14. When I paste text into a document, each line gets indented further than the last. Why does nano do this, and how can I avoid it?</a><br>
<ahref="#4.15">4.15. 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></p></blockquote>
<h2><ahref="#5">5. Internationalization</a></h2>
<blockquote><p><ahref="#5.1">5.1. There's no translation for my language!</a><br>
<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>
<ahref="#5.1">5.1. There's no translation for my language!</a><br>
<ahref="#5.2">5.2. I don't like the translation for <x> in my language. How can I fix it?</a><br>
<ahref="#5.3">5.3. What is the status of Unicode support?</a></p></blockquote>
<h2><ahref="#6">6. Advocacy and Licensing</a></h2>
<blockquote><p><ahref="#6.1">6.1. Why should I use nano instead of Pico?</a><br>
<ahref="#5.3">5.3. What is the status of Unicode support?</a>
</p></blockquote>
<h3><ahref="#6">6. Advocacy and Licensing</a></h3>
<blockquote><p>
<ahref="#6.1">6.1. Why should I use nano instead of Pico?</a><br>
<ahref="#6.2">6.2. Why should I use Pico instead of nano?</a><br>
<ahref="#6.3">6.3. What is so bad about the older Pine license?</a><br>
<ahref="#6.4">6.4. Okay, well, what mail program should I use then?</a></p></blockquote>
<ahref="#7.2">7.2. I want to send the development team a big load of cash (or just a thank you).</a><br>
<ahref="#7.3">7.3. How do I submit a bug report or patch?</a><br>
<ahref="#6.4">6.4. Okay, well, what mail program should I use then?</a>
</p></blockquote>
<h3><ahref="#7">7. Miscellaneous</a></h3>
<blockquote><p>
<ahref="#7.1">7.1. Where can I ask questions or send suggestions?</a><br>
<ahref="#7.2">7.2. How do I submit a bug report or patch?</a><br>
<ahref="#7.3">7.3. I want to send the development team a big load of cash (or just a thank you).</a><br>
<ahref="#7.4">7.4. How do I join the development team?</a><br>
<ahref="#7.5">7.5. Can I have write access to the subversion tree?</a></p></blockquote>
<h2><ahref="#8">8. ChangeLog</a></h2>
<ahref="#7.5">7.5. Can I have write access to the GIT tree?</a>
</p></blockquote>
<hrwidth="100%">
<h1><aname="1"></a>1. General</h1>
<h2><aname="1.1"></a>1.1 About this FAQ</h2>
<blockquote><p>This FAQ was originally written and maintained by Chris Allegretta <<ahref="mailto:chrisa@asty.org">chrisa@asty.org</a>>, who also happens to be the creator of nano. It was then maintained by David Lawrence Ramsey <<ahref="mailto:pooka109@gmail.com">pooka109@gmail.com</a>>. Maybe someone else will volunteer to maintain this FAQ someday, who knows...</p></blockquote>
<h2><aname="1.2"></a>1.2. How do I contribute to it?</h2>
<blockquote><p>Your best bet is to send it to the nano email address, <ahref="mailto:nano@nano-editor.org">nano@nano-editor.org</a> and if it is useful enough it will be included in future versions.</p></blockquote>
<h2><aname="1.3"></a>1.3. What is GNU nano?</h2>
<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 perhaps include extra functionality".</p></blockquote>
<h2><aname="1.4"></a>1.4. What is the history behind nano?</h2>
<h3><aname="1.1"></a>1.1. What is GNU nano?</h3>
<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 today.</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>
<p>In February 2001, nano was declared an official GNU program by Richard Stallman. nano also reached its first production release on March 22, 2001.</p></blockquote>
<h2><aname="1.5"></a>1.5. Why the name change from TIP?</h2>
<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>
<h2><aname="1.6"></a>1.6. What is the current version of nano?</h2>
<blockquote><p>The current stable version of nano *should* be 2.4.2. Of course, you should always check the <ahref="http://www.nano-editor.org/">nano homepage</a> to see what the latest and greatest version is.</p></blockquote>
<h2><aname="1.7"></a>1.7. I want to read the man page without having to download the program!</h2>
<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>5.1</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>
<h2><aname="2.4"></a>2.4. By subversion (for the brave).</h2>
<blockquote><p>For the 'bleeding edge' current version of nano, you can use subversion 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://svn.savannah.gnu.org/viewvc/trunk/nano/README.SVN?root=nano&view=markup">the nano SVN document</a> for info on anonymous SVN access to the nano source.</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>
<hrwidth="100%">
<h1><aname="3"></a>3. Installation and Configuration</h1>
<h2><aname="3.1"></a>3.1. How do I install the RPM or DEB package?</h2>
<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>
<h2><aname="3.2"></a>3.2. Compiling from source: WHAT THE HECK DO I DO NOW?</h2>
<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-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>
<h2><aname="3.3"></a>3.3. Why does everything go into /usr/local?</h2>
<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>
<h2><aname="3.5"></a>3.5. nano should automatically run strip on the binary when installing it!</h2>
<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>
<h2><aname="3.6"></a>3.6. How can I make the executable smaller? This is too bloated!</h2>
<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
<b>--disable-color</b> Disable color and syntax highlighting
<b>--disable-extra</b>Disable extra features (currently only an easter egg)
<b>--disable-help</b>Disable help functions
<b>--disable-comment</b> Disable the comment/uncomment function
<b>--disable-extra</b> Disable the easter egg
<b>--disable-help</b> Disable the built-in help texts
<b>--disable-histories</b> Disable the saving of search strings and cursor positions
<b>--disable-speller</b> Disable the spell-checker functions
<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 if 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>
<h2><aname="3.7"></a>3.7. Tell me more about this multibuffer stuff!</h2>
<blockquote><p>To use multiple file buffers, you must be using nano 1.1.0 or newer, and you must not have configured it 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>, then insert the file as normal with<b>^R</b>. If you always want files to be loaded into their own buffers, use the <b>--multibuffer</b> or <b>-F</b> flag when you invoke nano.</p>
<p>You can move between the buffers you have open with the <b>Meta-<</b> and <b>Meta-></b> keys, or more easily with <b>Meta-,</b> and <b>Meta-.</b> (clear as mud, right? =-). When you have more than one file buffer open, the ^X shortcut will say "Close", instead of the normal "Exit" when only one buffer is open.</p></blockquote>
<h2><aname="3.8"></a>3.8. Tell me more about this verbatim input stuff!</h2>
<blockquote><p>To use verbatim input, you must be using nano 1.3.1 or newer. 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"), then press the key(s) that generate the character you want.</p>
<p>Alternatively, if you've enabled Unicode support (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 instead. The prompt will change to "Unicode Input" when you do this.</p></blockquote>
<h2><aname="3.9a"></a>3.9a. How do I make a .nanorc file that nano will read when I start it?</h2>
<blockquote><p>It's not hard at all! But, your version of nano must <b>not</b> have been compiled with <b>--disable-nanorc</b>, and must be version 1.1.12 or newer (use nano -V to check your version and compiled features). Then simply copy the<b>nanorc.sample</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 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>
<h2><aname="3.9b"></a>3.9b. How about in Win32?</h2>
<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.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.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.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>
<h2><aname="4.1"></a>4.1. How do I open a file with a name beginning with '+' from the command line?</h2>
<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>
<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 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>
<h2><aname="4.2"></a>4.2. Ack! My Backspace/Delete/Enter/Meta/double bucky key doesn't seem to work! What can I do?</h2>
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>
<h2><aname="4.3"></a>4.3. Ack! My numeric keypad's keys don't work properly when NumLock is off! What can I do?</h2>
<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>
<h2><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?</h2>
<blockquote><p>This is a bug in the terminal, not in nano. When a key is repeating faster than nano can process it, the keyboard buffer becomes full and starts dropping incoming keystrokes. Unfortunately, it doesn't just drop whole keystrokes; it can also drop parts of multibyte key combinations, resulting in nano's receiving a wrong key.</p></blockquote>
<h2><aname="4.5"></a>4.5. How do I type the F13-F16 keys shown in the help browser? My keyboard only has F1-F12!</h2>
<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>
<h2><aname="4.6"></a>4.6. nano crashes when I type <insert keystroke here>!</h2>
<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>
<h2><aname="4.7"></a>4.7. nano crashes when I resize my window. How can I fix that?</h2>
<blockquote><p>Older versions of nano had this problem, please upgrade to a newer version (at least 0.9.9, but 2.4.2 is recommended).</p></blockquote>
<h2><aname="4.8"></a>4.8. [version 1.3.12 and later] I'm using glibc 2.2.3, and nano crashes when I use color support or do regular expression searches. How can I fix that?</h2>
<blockquote><p>It's a bug in glibc 2.2.3. You should upgrade to at least glibc 2.2.4.</p></blockquote>
<h2><aname="4.9"></a>4.9. [version 1.1.12 and earlier] Why does nano show ^\ in the shortcut list instead of ^J?</h2>
<blockquote><p>The help (^G) and justify (^J) functions were among the last to be written. To show the improvements that nano had over Pico (go to line number, and replace), ^_ and ^\ were put on the shortcut list. Later, ^G came back in place of ^_ as it proved to be very valuable for new Unix users.</p></blockquote>
<h2><aname="4.10a"></a>4.10a. [version 1.1.12 and earlier] When I type in a search string, the string I last searched for is already in front of my cursor! What happened?!</h2>
<blockquote><p>Since nano version 0.9.20, the default was to have a completely consistent user interface across all user input functions. This means that regardless of whether you're being asked for a filename to insert or write, or a string to search for, the previous value is already inserted before the cursor.</p></blockquote>
<h2><aname="4.10b"></a>4.10b. [version 1.1.99pre1 and later] Hey, the search string behavior has reverted, it's now like Pico, what happened to the consistency?</h2>
<blockquote><p>It was decided that consistency was nice, but people are used to Pico's inconsistent behavior. Also, in version 1.1.99pre1, search and replace history was introduced. If you wish to edit your previous search/replace entry (or any previous entry), you can do so by hitting the up arrow to cycle through your history. This method allows the best of both worlds: You don't need to erase the previous string if you want to enter a new one, but you can with one keystroke recall previous entries for editing. Therefore there is now no "Pico mode", nano is and has always been a Pico <b>clone</b>, and clones by default should be compatible.</p></blockquote>
<h2><aname="4.11"></a>4.11. How do I make nano my default editor (in Pine, mutt, etc.)?</h2>
<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>--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.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>
@@ -206,126 +211,50 @@
<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>
<h2><aname="4.12"></a>4.12. I've compiled nano with color support, but I don't see any color when I run it!</h2>
<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>doc/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>
<h2><aname="4.13"></a>4.13. 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?</h2>
<blockquote><p>Try holding down the Shift key and selecting or pasting the text as you normally would.</p></blockquote>
<h2><aname="4.14"></a>4.14. When I paste text into a document, each line gets indented further than the last. Why does nano do this, and how can I avoid it?</h2>
<blockquote><p>You have the autoindent feature turned on. Hit Meta-I to turn it off, paste your text, and then hit Meta-I again to turn it back on.</p></blockquote>
<h2><aname="4.15"></a>4.15. On startup I get a message that says "Detected a legacy nano history file". Now older nano versions can't find my search history!</h2>
<blockquote><p>In nano 2.3.0, cursor-position history was introduced, and both history files now reside under a .nano directory in your home. nano was trying to move this file into the new location so it could continue to use it. This means that if you try and use an earlier version of nano, it will be unable to see your current search history. To fix this, run the following commands:<br>
<p>Again, replace x.y with the version of nano you use.</p></blockquote>
<hrwidth="100%">
<h1><aname="5"></a>5. Internationalization</h1>
<h2><aname="5.1"></a>5.1. There's no translation for my language!</h2>
<blockquote><p>On June of 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 very 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 repository.</p></blockquote>
<h2><aname="5.2"></a>5.2. I don't like the translation for <x> in my language. How can I fix it?</h2>
<blockquote><p>The best way would probably be to send an e-mail to the team's mailing listed mentione in the <code>Language-Team:</code> field in the <b><your_language>.po</b> file with your suggested corrections, and then they can make the changes reach the nano-devel list.</p></blockquote>
<h2><aname="5.3"></a>5.3. What is the status of Unicode support?</h2>
<blockquote><p>In version 1.3.12 or later, Unicode should be usable. With your terminal, locale (LC_ALL and similar environment variables), and encoding configured to properly support UTF-8, you should be able to enter and save Unicode text.</p></blockquote>
<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="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>
<blockquote><p>Unicode should be fully usable nowadays. When the encoding of your terminal is set to UTF-8, and your locale (mainly the LANG environment variable) is UTF-8 too, then you should be able to read, enter and save Unicode text.</p></blockquote>
<hrwidth="100%">
<h1><aname="6"></a>6. Advocacy and Licensing</h1>
<h2><aname="6.1"></a>6.1. Why should I use nano instead of Pico?</h2>
<blockquote><p>There are many reasons to use nano instead of Pico. A more complete list can be found at the <ahref="http://www.nano-editor.org/">nano homepage</a>.</p></blockquote>
<h2><aname="6.2"></a>6.2. Why should I use Pico instead of nano?</h2>
<blockquote><p>Again, check out the <ahref="http://www.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>
<h2><aname="6.3"></a>6.3. What is so bad about the older Pine license?</h2>
<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>
<h2><aname="6.4"></a>6.4. Okay, well, what mail program should I use then?</h2>
<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>
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>
<h3><aname="6.1"></a>6.1. Why should I use nano instead of Pico?</h3>
<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>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="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>
<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>
<h2><aname="7.2"></a>7.2. I want to send the development team a big load of cash (or just a thank you).</h2>
<blockquote><p>That's fine. Send it <ahref="mailto:nano-devel@gnu.org">our way</a>! Better yet, fix a <ahref="https://savannah.gnu.org/bugs/?group=nano">bug</a> in the program or implement a <ahref="http://www.nano-editor.org/dist/v2.3/TODO">cool feature</a> and send us that instead (though cash is fine too).</p></blockquote>
<h2><aname="7.3"></a>7.3. How do I submit a bug report or patch?</h2>
<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="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 place to submit bugs is to the <ahref="https://savannah.gnu.org/bugs/?group=nano">Savannah bug tracker</a> as you can check whether the bug you are submitting has already been submitted.
<p>Please submit patches for nano via the <ahref="https://savannah.gnu.org/patch/?group=nano">Savannah project's patch manager</a> for the nano project.</p></blockquote>
<h2><aname="7.4"></a>7.4. How do I join the development team?</h2>
<blockquote><p>The easiest way is to consistently send in good patches that add some needed functionality, fix a bug or two, and/or make the program more optimized/efficient. Then ask nicely and you will probably be added to the Savannah development list and be given SVN write access after a while. There is a lot of responsibility that goes along with being a team member, so don't think it's just something to add to your resume.</p></blockquote>
<h2><aname="7.5"></a>7.5. Can I have write access to the subversion tree?</h2>
<blockquote><p>Re-read Section <ahref="#7.4">7.4</a> and you should know the answer.</p></blockquote>
<h2><aname="8"></a>8. ChangeLog</h2>
<blockquote><p>
2015/07/18 - More small fixes and updates. (Benno)<br>
2014/04/24 - A bunch of small fixes and updates. (Benno)<br>
2009/11/30 - Update various bits for nano 2.2.x. (DLR)<br>
2009/11/18 - Typo fix. (j.mader@gmail.com)<br>
2008/03/16 - Update docs to refer to subversion instead of CVS, add more words about Alpine, and refer to Savannah for bugs and patches. (chrisa)<br>
2007/12/09 - Add minor punctuation and wording fixes, and update various sections to account for Alpine. (DLR)<br>
2007/08/26 - Update links to the Free Translation Project. (DLR)<br>
2007/07/29 - Update RPM links for nano 2.0.x. (DLR)<br>
2007/04/18 - Add a new section 4.14 to explain how autoindent affects pasted text. (John M. Gabriele, minor tweaks by DLR)<br>
2007/04/04 - Update email address. (DLR)<br>
2007/01/01 - Update section 4.1 to describe how to open files with names beginning with '+' at specified columns as well as lines. (DLR)<br>
2006/11/25 - Add miscellaneous wording and capitalization fixes. (DLR)<br>
2006/10/28 - Update various links for the 2.0 branch of nano. (DLR)<br>
2006/10/06 - Update the question in section 4.13 to match the version of it in the answer section. (DLR)<br>
2006/07/25 - Update section 5.3 again to not state "the latest development version" before 1.3.12, as it's no longer accurate. Also add some minor spacing fixes. (DLR)<br>
2006/06/12 - Update section 5.3, due to the display fix for two-column Unicode characters. (DLR)<br>
2006/06/05 - Add a new section 4.8, and move all section 4 entries after it down one number, to explain how to deal with glibc 2.2.3's crashes involving extended regular expressions. (DLR)<br>
2006/06/04 - Add minor punctuation, wording, and typo fixes. (DLR)<br>
2006/05/27 - Update section 3.8 to mention the new "Unicode Input" prompt, and how Unicode input only works when Unicode support is enabled. (DLR)<br>
2006/05/12 - Remove section 4.4, and move all section 4 entries after it up one number, since it no longer applies. Meta-] and Meta-[ are no longer used to indent and unindent marked text, since they require that the bracket matching key change to Ctrl-], which is used as the telnet escape key (found by Chris). Also, make the link to the nano CVS page a bit more readable. (DLR)<br>
2006/05/08 - Add a new section 4.5, and move all section 4 entries after it down one number, to explain a problem that can occur when holding down keys to generate Meta sequences. Also add a few more capitalization and wording fixes. (Benno Schulenberg, minor tweaks by DLR)<br>
2006/05/01 - Add a new section 4.4, and move all section 4 entries after it down one number, to explain how to deal with problems typing Meta-[. Also add a few capitalization and wording fixes. (DLR)<br>
2006/04/14 - Clarify section 1.4: help menu -> help text display. (DLR, suggested by Benno Schulenberg)<br>
2006/03/16 - Update the Free Translation Project's address, change the character set to UTF-8, and remove broken links to contributed RedHat nano packages. (DLR)<br>
2005/11/21 - Clarify section 5.3 to better explain how to enable Unicode support, and remove the mention of quirks, since they turned out to not be a nano problem. (Mike Frysinger and DLR)<br>
2005/11/19 - Add a new section 5.3 to explain the status of nano's Unicode support. (Mike Frysinger, minor tweaks by DLR)<br>
2005/08/27 - Update email address. (DLR)<br>
2005/08/10 - Add a new section 4.3, and move all section 4 entries after it down one number, to explain how to deal with numeric keypad problems. (DLR)<br>
2005/08/08 - Update section 3.8 to mention that verbatim input mode now takes a six-digit hexadecimal number. (DLR)<br>
2005/07/04 - Update section 4.10 to mention that pasting from the X clipboard via the middle mouse button also works when the Shift key is used. (DLR)<br>
2005/06/15 - Update description of --enable-extra, and add missing line breaks. (DLR)<br>
2005/06/13 - Minor capitalization and wording fixes. (DLR)<br>
2005/06/08 - Updated section 1.1 to mention the current maintainer. (DLR)<br>
2005/03/09 - Added question about opening files with names beginning with '+'s, and added a few more miscellaneous cosmetic fixes. (DLR)<br>
2005/01/03 - Removed now-inaccurate note about verbatim input's not working at prompts, and update its description to mention that it handles hexadecimal values now. (DLR)<br>
2004/11/21 - Listed sh as an example of a Bourne shell. (DLR)<br>
2004/11/05 - Fixed inaccuracy: Pico compatibility mode was made the default in nano 1.1.99pre1, not 1.2.2. Also added question about how to type F13-F16 on terminals lacking keys past F12 (suggested by Chris), question about how to select text for the clipboard in X terminals with nano's mouse support turned on (answer found by Joseph Birthisel), and misc. fixes and link updates. (DLR)<br>
2004/04/07 - Removed NumLock glitch question, as it's no longer needed. (DLR)<br>
2004/01/30 - Fixed inaccuracy: multibuffer mode was first in nano 1.1.0, not 1.1.12. (DLR)<br>
2003/12/31 - Added question about the new verbatim input function, and a few minor fixes. Removed reference to "set pico" (DLR).<br>
2003/07/02 - Added question about nano's not showing color when it's compiled with color support (DLR; suggested by Jordi).<br>
2003/02/23 - Updated RPM links for nano 1.2.x (DLR).<br>
2003/01/16 - Split section 4.5 into 4.5a and 4.5b for search string behavior. Added --enable-all docs.<br>
2002/12/28 - More misc. fixes (David Benbennick, DLR).<br>
2002/10/25 - Misc. fixes and link updates (DLR).<br>
2002/09/10 - Another typo fix (DLR).<br>
2002/05/15 - Typo fix (DLR).<br>
2001/12/26 - Misc. fixes (Aaron S. Hawley, DLR).<br>
2001/10/02 - Update for Free Translation Project.<br>
2000/11/28 - Added blurb about make install-strip.<br>
2000/11/19 - Changed Debian frozen to stable.<br>
2000/11/18 - Previous string display (4.5).<br>
2000/09/27 - Moved addresses to nano-editor.org.<br>
2000/06/31 - Initial framework.</p></blockquote>
<p>$Id$</p>
<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.
<p>You can submit patches for nano via <ahref="https://savannah.gnu.org/patch/?group=nano">Savannah's patch manager</a>.</p></blockquote>
<h3><aname="7.3"></a>7.3. I want to send the development team a big load of cash (or just a thank you).</h3>
<blockquote><p>That's fine. Send it <ahref="mailto:nano-devel@gnu.org">our way</a>! Better yet, fix a <ahref="https://savannah.gnu.org/bugs/?group=nano">bug</a> in the program or implement a <ahref="https://nano-editor.org/dist/latest/TODO">cool feature</a> and send us that instead (though cash is fine too).</p></blockquote>
<h3><aname="7.4"></a>7.4. How do I join the development team?</h3>
<blockquote><p>The easiest way is to consistently send in good patches that add some needed functionality, fix a bug or two, and/or make the program more optimized/efficient. Then ask nicely and you will probably be added to the Savannah development list and be given write access after a while. There is a lot of responsibility that goes along with being a team member, so don't think it's just something to add to your resume.</p></blockquote>
<h3><aname="7.5"></a>7.5. Can I have write access to the git tree?</h3>
<blockquote><p>Re-read section <ahref="#7.4">7.4</a> and you should know the answer.</p></blockquote>
color brightyellow ":|\*|/|%|\+|-|\^|>|>=|<|<=|~=|=|\.\.|\<(not|and|or)\>"
# Statements
color brightblue "\<(do|end|while|repeat|until|if|elseif|then|else|for|in|function|local|return|break)\>"
# Keywords
color brightyellow "\<(io|math|os|string|table|coroutine|debug)\>\."
color brightyellow "\<(_G|_VERSION|assert|collectgarbage|dofile|error|getfenv|getmetatable|ipairs|load|loadfile|module|next|pairs|pcall|print|rawequal|rawget|rawset|require|select|setfenv|setmetatable|tonumber|tostring|type|unpack|xpcall)\s*\("
# Standard library
color brightyellow "io\.\<(close|flush|input|lines|open|output|popen|read|tmpfile|type|write|stdin|stdout|stderr)\>"
color brightyellow "math\.\<(abs|acos|asin|atan2|atan|ceil|cosh|cos|deg|exp|floor|fmod|frexp|huge|ldexp|log10|log)\>"
color brightyellow "math\.\<(max|min|mod|modf|pi|pow|rad|random|randomseed|sinh|tan)\>"
color brightyellow "os\.\<(clock|date|difftime|execute|exit|getenv|remove|rename|setlocale|time|tmpname)\>"
color brightyellow "package\.\<(cpath|loaded|loadlib|path|preload|seeall)\>"
color brightyellow "string\.\<(byte|char|dump|find|format|gmatch|gsub|len|lower|match|rep|reverse|sub|upper)\>"
color brightyellow "table\.\<(concat|insert|maxn|remove|sort)\>"
color brightyellow "coroutine\.\<(create|resume|running|status|wrap|yield)\>"
color brightyellow "debug\.\<(debug|getfenv|gethook|getinfo|getlocal|getmetatable|getregistry|getupvalue)\>"
color brightyellow "debug\.\<(setfenv|sethook|setlocal|setmetatable|setupvalue|traceback)\>"
# File handle methods
color brightyellow "\:\<(close|flush|lines|read|seek|setvbuf|write)\>"
color brightblue "((Icon|ExclusiveOs|ExcludeOs)[[:space:]]*:)"
color brightblue "((BuildArch|BuildArchitectures|ExclusiveArch|ExcludeArch)[[:space:]]*:)"
color brightblue "((Conflicts|Obsoletes|Provides|Requires|Requires\(.*\)|Enhances|Suggests|BuildConflicts|BuildRequires|Recommends|PreReq|Supplements)[[:space:]]*:)"
color brightblue "((Epoch|Serial|Nosource|Nopatch)[[:space:]]*:)"
color brightblue "((AutoReq|AutoProv|AutoReqProv)[[:space:]]*:)"
color brightblue "((Copyright|License|Summary|Summary\(.*\)|Distribution|Vendor|Packager|Group|Source\d*|Patch\d*|BuildRoot|Prefix)[[:space:]]*:)"
color brightblue "((Name|Version|Release|Url|URL)[[:space:]]*:)"
color brightblue start="^Source" end=":" start="^Patch" end=":"
# Architectures.
color brightred "(i386|i486|i586|i686|athlon|ia64|alpha|alphaev5|alphaev56|alphapca56|alphaev6|alphaev67|sparc|sparcv9|sparc64armv3l|armv4b|armv4lm|ips|mipsel|ppc|ppc|iseries|ppcpseries|ppc64|m68k|m68kmint|Sgi|rs6000|i370|s390x|s390|noarch)"
# Architecture conditionals.
color brightred "(ifarch|ifnarch)"
# OS conditionals.
color brightred "(ifos|ifnos)"
# %* strings.
color green "%([A-Z_a-z_0-9_]*)"
color magenta "%_([A-Z_a-z_0-9_]*)"
color yellow start="%__" end="\ "
color magenta start="%\{" end="\}"
color yellow start="%\{__" end="\}"
# Sections.
color red "^%(build$|changelog|check$|clean$|description|files|install$|package|pre|prep$|pretrans|preun)"
color red "^%(post|posttrans|postun|trigger|triggerin|triggerpostun|triggerun|verifyscript)"
# Conditionals and defines.
color brightred "%(if|else|endif|define|global|undefine)"
# Comments.
color cyan "#.*$"
# Special case: "# norootforbuild" is handled as main tag.
File diff suppressed because it is too large
Load Diff
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.
