Storing the orientation of the marked region beforehand is not needed,
as this orientation is readily available also after the justification.
(By the way, cursor and mark need to be swapped after justifying
a backward-marked region because the rule is that the cursor gets
placed *after* the justified paragraph. Maybe that should change?)
The most likely reason for stat() returning -1 is that the file
does not exist. And an absent positionlog file is not an error.
(In some cases it is, like immediately after writing the file,
but even then we don't want to complain, because it may have
been some other process that deleted the file straightaway.)
This fixes https://savannah.gnu.org/bugs/?58993.
Bug existed since version 5.0, commit fcb9e58b.
This ability was lost in commit 92298349 from two hours ago, which
bypasses the keystroke buffer and its integrated screen resizing.
This new implementation is better than it was before, because it
responds almost instantly to a resize instead of with a delay of
up to a second.
(Still, this does not allow a full escape sequence to be used as
the Cancel command, but I think that is an acceptable limitation,
because 1) nobody ought to be using --rawsequences, and 2) very
few people will bind Cancel to something like F3 or Ins.)
This improves the fix for https://savannah.gnu.org/bugs/?58825.
When checking (during a Search command) whether the user has pressed
the Cancel keystroke, look at ncurses' input stream directly instead
of at nano's own keystroke buffer, because the latter may contain the
copied keystrokes of a macro and we don't want to discard those.
(This does not yet allow a Meta keystroke to be used for Cancel, but
the next commit will fix that.)
This fixes https://savannah.gnu.org/bugs/?58825.
Bug existed since version 2.9.0, since the macro was introduced.
First mention the three main 'pieces' of the editor: Editing window,
Help viewer, and File browser. Then mention how to change settings:
with the toggles or with nanorc files.
There is no reason to deselect the region, as nothing has changed.
(This also retains the shift-selected region when a non-shortcut key is
typed in view mode, which makes sense, as again nothing was changed.)
This fixes https://savannah.gnu.org/bugs/?58980.
Bug existed since version 4.9, commit 0ed62e84.
Replace an obsolete question that doesn't have a good answer: setting
TERM to vt100 is unlikely to make the more complicated keystrokes work,
which are the ones that are most likely not to work.
When keypad() is set to FALSE, like for verbatim input, ncurses is
not waiting its fifty milliseconds after an ESC to see if another
code will follow it, so nano itself will have to pause a little.
Otherwise 'solitary' could get set to TRUE when in fact the ESC
is followed very closely by another code.
This fixes https://savannah.gnu.org/bugs/?58955.
Bug existed since version 2.6.2, commit f2150d3f.
Also when each character is just one byte, parse_verbatim_kbinput()
can produce two bytes; plus the terminating NUL that is three bytes.
This fixes https://savannah.gnu.org/bugs/?58959.
Bug existed since version 4.9, commit 03d296eb.
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.
<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.9">3.9. How do I make a .nanorc file that nano will read when I start it?</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.2">4.2. How can I make Ctrl+Shift+Left/Right select words on urxvt?</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. 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.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>
@@ -85,7 +89,7 @@
<h3><aname="1.3"></a>1.3. Why the name change from TIP?</h3>
<blockquote><p>On January 10, 2000, TIP was officially renamed to nano because of a namespace conflict with another program called 'tip'. The original 'tip' program "establishes a full duplex terminal connection to a remote host", and was included with many older Unix systems (and newer ones like Solaris). The conflict was not noticed at first because there is no 'tip' utility included with most GNU/Linux distributions (where nano was developed).</p></blockquote>
<h3><aname="1.4"></a>1.4. What is the current version of nano?</h3>
<blockquote><p>The current version of nano <i>should</i> be <b>4.2</b>. Of course, you should always check the <ahref="https://nano-editor.org/">nano homepage</a> to see what the latest and greatest version is.</p></blockquote>
<blockquote><p>The current version of nano <i>should</i> be <b>5.2</b>. Of course, you should always check the <ahref="https://nano-editor.org/">nano homepage</a> to see what the latest and greatest version is.</p></blockquote>
<h3><aname="1.5"></a>1.5. I want to read the man page without having to download the program!</h3>
<p>You can also have a look at the <ahref="ftp://ftp.debian.org/debian/pool/main/n/nano/">Package Pool</a> to see all the available binary and source packages.</p>
<p>You can also have a look at the <ahref="http://ftp.debian.org/debian/pool/main/n/nano/">Package Pool</a> to see all the available binary and source packages.</p>
</blockquote>
<h3><aname="2.4"></a>2.4. By GIT (for the brave).</h3>
<blockquote><p>For the 'bleeding edge' current version of nano, you can use GIT to download the current source code. <b>Note:</b> believe it or not, by downloading code that has not yet stabilized into an official release, there could quite possibly be bugs, in fact the code may not even compile! Anyway, see <ahref="http://git.savannah.gnu.org/cgit/nano.git/tree/README.GIT">the nano GIT document</a> for info on anonymous GIT access to the nano source.</p></blockquote>
@@ -120,23 +124,23 @@
<h1><aname="3"></a>3. Installation and Configuration</h1>
<h3><aname="3.1"></a>3.1. How do I install the RPM or DEB package?</h3>
<blockquote><p>It's simple really! As root, type <b>rpm -Uvh nano-x.y.z-1.i386.rpm</b> if you have a RedHat-ish system or <b>dpkg -i nano_x.y.z-1.deb</b> if you have a Debian-ish system, where <b>x.y.z</b> is the release of nano. There are other programs to install packages, and if you wish to use those, knock yourself out.</p></blockquote>
<blockquote><p>It's simple really! As root, type <b>rpm -Uvh nano-x.y-1*.rpm</b> if you have a RedHat-ish system or <b>dpkg -i nano_x.y-1*.deb</b> if you have a Debian-ish system, where <b>x.y</b> is the version number of nano. There are other programs to install packages, and if you wish to use those, knock yourself out.</p></blockquote>
<h3><aname="3.2"></a>3.2. Compiling from source: WHAT THE HECK DO I DO NOW?</h3>
<blockquote><p>Okay, take a deep breath, this really isn't hard. Unpack the nano source with a command like:</p>
<p><b>tar -xvf nano-x.y.z.tar.gz</b></p>
<p><b>tar -xvf nano-x.y.tar.gz</b></p>
<p>Then you need to run <b>configure</b> with any options you might want (if any).</p>
<p>The average case is this:</p>
<p><b>cd nano-x.y.z/</b><br>
<p><b>cd nano-x.y/</b><br>
<b>./configure</b><br>
<b>make</b><br>
<b>make install</b> (as root, of course)</p></blockquote>
<h3><aname="3.3"></a>3.3. Why does everything go into /usr/local?</h3>
<blockquote><p>Well, that's what the <b>configure</b> script defaults to. If you wish to change this, simply do this:</p>
<p><b>./configure --prefix=/usr</b></p>
<p>to put nano into /usr/bin when you run <b>make install</b>.</p></blockquote>
<h3><aname="3.5"></a>3.5. nano should automatically run strip on the binary when installing it!</h3>
<blockquote><p>Actually, it does, but you have to use <b>make install-strip</b>. The default make install does not, and will not, run strip automatically.</p></blockquote>
<h3><aname="3.6"></a>3.6. How can I make the executable smaller? This is too bloated!</h3>
<p>This will put nano into /usr/bin when you run <b>make install</b>.</p></blockquote>
<h3><aname="3.4"></a>3.4. nano should automatically run strip on the binary when installing it!</h3>
<blockquote><p>It does when you use <b>make install-strip</b>. The default <b>make install</b> does not, and will not, run strip automatically.</p></blockquote>
<h3><aname="3.5"></a>3.5. How can I make the executable smaller? This is too bloated!</h3>
<blockquote><p>Actually, there are several parts of the editor that can be disabled. You can pass arguments to the <b>configure</b> script that disable certain features. Here's a brief list:</p>
<pre>
<b>--disable-browser</b> Disable the built-in file browser
@@ -156,30 +160,49 @@
<b>--disable-tabcomp</b> Disable the tab-completion functions
<b>--disable-wordcomp</b> Disable the word-completion function
<b>--disable-wrapping</b> Disable all hard-wrapping of text</pre>
<p>There's also the <b>--enable-tiny</b> option which disables everything above, as well as some larger chunks of the program (like the marker code that you use with Control-^ to select text). Also, if you know you aren't going to be using other languages, you can use <b>--disable-nls</b> to disable internationalization and save a few K to a few dozen K depending on whether you have locale support on your system. And finally, there's always good old <b>strip</b> to strip all debugging code and code that exists in libraries on your system.</p>
<p>There's also the <b>--enable-tiny</b> option which disables everything above, as well as some larger chunks of the program (like the undo/redo code and the code for selecting text). Also, if you know you don't need other languages, you can use <b>--disable-nls</b> to disable internationalization and save a few kilobytes. And finally, there's always good old <b>strip</b> to remove all unneeded symbols.</p>
</blockquote>
<h3><aname="3.7"></a>3.7. Tell me more about this multibuffer stuff!</h3>
<h3><aname="3.6"></a>3.6. Tell me more about this multibuffer stuff!</h3>
<blockquote><p>To use multiple file buffers, you must not have configured nano with <b>--disable-multibuffer</b> nor with <b>--enable-tiny</b> (use <b>nano -V</b> to check the compilation options). Then when you want to insert a file into its own buffer instead of into the current file, just hit <b>Meta-F</b> after typing <b>^R</b>. If you always want files to be loaded into their own buffers, use the <b>-F</b> or <b>--multibuffer</b> flag when you invoke nano, or add <b>set multibuffer</b> to your .nanorc file.</p>
<p>You can move between the buffers you have open with the <b>Meta-<</b> and <b>Meta-></b> keys, or more easily without holding Shift: <b>Meta-,</b> and <b>Meta-.</b> (clear as mud, right? =-). When you have more than one buffer open, the ^X shortcut will say "Close", instead of "Exit".</p></blockquote>
<h3><aname="3.8"></a>3.8. Tell me more about this verbatim input stuff!</h3>
<h3><aname="3.7"></a>3.7. Tell me more about this verbatim input stuff!</h3>
<blockquote><p>When you want to insert a literal character into the file you're editing, such as a control character that nano usually treats as a command, first press <b>Meta-V</b> (if you're not at a prompt, you'll get the message "Verbatim Input" on the status bar), then press the key(s) that generate the character you want.</p>
<p>Alternatively, if Unicode support is enabled (see section <ahref="#5.3">5.3</a>), you can press <b>Meta-V</b> and then type a six-digit hexadecimal code (from 000000 to 10FFFF, case-insensitive), and the character with the corresponding value will be inserted. The status bar will change to "Unicode Input: ......" when you do this.</p></blockquote>
<h3><aname="3.9"></a>3.9. How do I make a .nanorc file that will be read when I start nano?</h3>
<blockquote><p>It's not hard at all! But, your nano must <b>not</b> have been compiled with <b>--disable-nanorc</b>. Then simply copy the <b>sample.nanorc</b> that came with the nano source or your nano package (most likely in /usr/doc/nano) to .nanorc in your home directory. If you didn't get one, the syntax of the file is simple. Flags are turned on and off by using the words <b>set</b> and <b>unset</b>plus the long option name for the feature. For example, "set nowrap" or "set smarthome".</p></blockquote>
<h3><aname="3.8"></a>3.8. How do I make a .nanorc file that will be read when I start nano?</h3>
<blockquote><p>It's not hard at all! Simply copy the <b>sample.nanorc</b> from the doc/ directory in the nano source package (or from /usr/doc/nano on your system) to <b>.nanorc</b> in your home directory, and then edit it. If you didn't get a sample nanorc, the syntax of the file is simple: features are turned on and off by using the words <b>set</b> and <b>unset</b>followed by the long option name of the feature (see <b>man nanorc</b> for the full list of options). For example, "set quickblank" or "set smarthome". Of course, for this to work, your nano must <b>not</b> have been compiled with <b>--disable-nanorc</b>.</p></blockquote>
<h3><aname="3.9"></a>3.9. Why does my self-compiled nano not read /etc/nanorc?</h3>
<blockquote><p>By default (see <ahref="#3.3">3.3</a>), nano gets installed into /usr/local. This also means that, at startup, nano will read <b>/usr/local/etc/nanorc</b> instead of <b>/etc/nanorc</b>. You can make a symlink from the former to the latter if you want your self-compiled nano to read the same nanorc as the system-installed nano. Or you can configure your nano to overwrite the system nano (again, see <ahref="#3.3">3.3</a>).</p></blockquote>
<hrwidth="100%">
<h1><aname="4"></a>4. Running</h1>
<h3><aname="4.1"></a>4.1. How do I open a file with a name beginning with '+' from the command line?</h3>
<blockquote><p>If a command-line option that begins with '+' is followed by another option, the former is always treated as a starting line and column number, and the latter is always treated as a filename. If a command-line option that begins with '+' isn't followed by another option, it's always treated as a filename. Examples:</p>
<p>To open '+filename.txt' starting on line 1: <b>nano +filename.txt</b><br>
<blockquote><p>If a command-line argument that begins with '+' is followed by another argument, the former is always treated as a starting line (plus column number), and the latter always as a filename. If a command-line argument that begins with '+' isn't followed by another argument, it's treated as a filename. Examples:</p>
<p>To open '+filename.txt': <b>nano +filename.txt</b><br>
To open '+filename.txt' starting on line 10: <b>nano +10 +filename.txt</b><br>
To open '+filename.txt' starting on line 1, column 20: <b>nano +,20 +filename.txt</b><br>
To open '+filename.txt' starting on line 10, column 20: <b>nano +10,20 +filename.txt</b><br>
To open '+filename.txt' starting on line 1 and 'filename.txt' starting on line 40 (if nano has been compiled with multibuffer support): <b>nano +1 +filename.txt +40 filename.txt</b></p></blockquote>
<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>
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. How can I make Ctrl+Shift+Left/Right select words on urxvt?</h3>
<blockquote><p>The urxvt terminal emulator produces non-standard escape sequences for the modified cursor keys. These deviant sequences are not listed in the terminfo database, which means that ncurses does not recognize them. The easiest way around this is to tell urxvt to produce xterm-compatible escape sequences for the relevant keystrokes. To achieve this, add the following lines to your ~/.Xresources file:</p>
<pre>
URxvt.iso14755_52: False
URxvt.keysym.C-S-Up: \033[1;6A
URxvt.keysym.C-S-Down: \033[1;6B
URxvt.keysym.C-S-Right: \033[1;6C
URxvt.keysym.C-S-Left: \033[1;6D
URxvt.keysym.M-Up: \033[1;3A
URxvt.keysym.M-Down: \033[1;3B
URxvt.keysym.M-Right: \033[1;3C
URxvt.keysym.M-Left: \033[1;3D
URxvt.keysym.M-Insert: \033[2;3~
URxvt.keysym.M-Delete: \033[3;3~
URxvt.keysym.M-Page_Up: \033[5;3~
URxvt.keysym.M-Page_Down: \033[6;3~</pre>
<p>Then run <b>xrdb ~/.Xresources</b> and restart your urxvt terminal. Now <b>Ctrl+Shift+Left</b> and <b>Ctrl+Shift+Right</b> will select words, <b>Alt+Up</b> and <b>Alt+Down</b> will scroll the text without moving the cursor, and several such things more.</p></blockquote>
<h3><aname="4.3"></a>4.3. Ack! My numeric keypad's keys don't work properly when NumLock is off! What can I do?</h3>
<blockquote><p>You can use the <b>-K</b> or <b>--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>
@@ -187,9 +210,11 @@
<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></blockquote>
<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></blockquote>
<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>
@@ -203,8 +228,8 @@
<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>
<p><b>my_hdr X-Composer: nano-x.y</b></p>
<p>Again, replace x.y with the version of nano you use.</p></blockquote>
color red "\<(as|case|of|class|data|default|deriving|do|forall|foreign|hiding|if|then|else|import|infix(l|r)?|instance|let|in|mdo|module|newtype|qualified|type|where)\>"
# Various symbols
color cyan "\||@|!|:|_|~|=|\\|;|\(\)|,|\[|\]|\{|\}"
# Operators
color magenta "==|/=|&&|\|\||<|>|<=|>="
# More symbols
color cyan "->|<-|=>"
color magenta "\.|\$"
# Data constructors
color magenta "\<(True|False|Nothing|Just|Left|Right|LT|EQ|GT)\>"
# Data classes
color magenta "\<(Bounded|Data|Enum|Eq|Floating|Fractional|Functor|Integral|Monad|MonadPlus|Num|Ord|Read|Real|RealFloat|RealFrac|Show|Typeable)\>"
color brightblue "\<(Name|Version|Release|Summary|Group|URL|Url|Epoch|Icon|Serial)[[:space:]]*:"
color brightblue "\<(BuildArch(itectures)?|Exclusive(Arch|OS)|Exclude(Arch|OS))[[:space:]]*:"
color brightblue "\<(Provides|Requires(\(.*\))?|Obsoletes|Conflicts|Recommends|Suggests|Supplements|Enhances|PreReq)[[:space:]]*:"
color brightblue "\<(BuildRoot|BuildRequires|BuildConflicts|Prefix|RemovePathPostfixes)[[:space:]]*:"
color brightblue "\<(AutoReq|AutoProv|AutoReqProv)[[:space:]]*:"
color brightblue "\<(License|Copyright|Distribution|Vendor|Packager)[[:space:]]*:"
color brightblue "\<((Source|Patch)[0-9]*|Nosource|Nopatch)[[:space:]]*:"
# Architectures.
color brightred "\<(i386|i486|i586|i686|athlon|ia64|alpha|alphaev5|alphaev56|alphapca56|alphaev6|alphaev67|sparc|sparcv9|sparc64armv3l|armv4b|armv4lm|ips|mipsel|ppc|ppciseries|ppcpseries|ppc64|m68k|m68kmint|Sgi|rs6000|i370|s390x?|noarch)\>"
# Architecture and OS conditionals.
color brightred "%(ifarch|elifarch|ifnarch|ifos|elifos|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 "^%((prep|build|install|check|clean)$|(description|files|package|changelog)\>)"
color red "^%((pre|post)(trans|un)?|trigger(prein|in|un|postun)?)\>"
color red "^%(trans)?filetrigger(in|un|postun)\>"
color red "^%(sourcelist|patchlist|generate_buildrequires|verifyscript)\>"
# Conditionals and defines.
color brightred "%(if|elif|else|endif|define|global|undefine)\>"
# Comments.
color cyan "(#|%dnl[[:space:]]).*"
# Special case: "# norootforbuild" is handled as main tag.
color brightblue "^# norootforbuild"
# For %changelog entries: first the author, then just the date.
@@ -8,17 +8,17 @@ color cyan "^\.(ds|nr) [^[:space:]]*"
# Single-character escapes
color brightmagenta "\\."
# The argument of \f or \s in the same color
color brightmagenta "\\f." "\\f\(.." "\\s(\+|\-)?[0-9]"
color brightmagenta "\\f(.|\(..)" "\\s(\+|\-)?[0-9]"
# Newlines
color cyan "(\\|\\\\)n(.|\(..)"
color cyan start="(\\|\\\\)n\[" end="]"
color cyan "\\(\\)?n(.|\(..)"
color cyan start="\\(\\)?n\[" end="]"
# Requests
color brightgreen "^\.[[:space:]]*[^[:space:]]*"
# Comments
color yellow "^\.\\".*"
# Strings
color green "(\\|\\\\)\*(.|\(..)"
color green start="(\\|\\\\)\*\[" end="]"
color green "\\(\\)?\*(.|\(..)"
color green start="\\(\\)?\*\[" end="]"
# Characters
color brightred "\\\(.."
color brightred start="\\\[" end="]"
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.