That is: mention also the new option names --newbuffer / set newbuffer.
And don't mention M-< and M-> for switching between buffers, as those
keystrokes have been reassigned to horizontal scrolling since nano-9.0.
It matches the "New Buffer" description of the M-F toggle in the file-
insertion menu, similar to how --noconvert matches "No Conversion".
(This should have been done ages ago, but it never occurred to me.)
That is: make line_needs_update(), when the mark is on, return TRUE
only when "page start" for old and new cursor position are the same
OR, otherwise, when NOT doing whole-window sidescrolling (that is:
when --solosidescroll is active).
This fixes https://savannah.gnu.org/bugs/?68556.
Bug existed since version 9.0, since whole-window sideways scrolling
was introduced.
Only the `lineno` of the last history item is ever referenced, so...
adjust only that number when an item is removed from the list.
This works, because whenever an item is added, it is added after the
last item, giving it automatically that item's line number plus one.
Also, make the relevant comparison a little more robust.
Since the previous commit, the history routines no longer make use
of splice_node() and unlink_node(), so now `openfile` will always
have a value when these functions are called.
This makes use of some knowledge about history lists: that there is
always another item when an identical item is found (because each
list ends with an empty item), that there is no item before the
head of the list, and that a new item is always added at the end.
This code is not time critical, but not calling splice_node() when
populating the search histories during startup saves upto three
hundred function calls, double the number of ifs, and triple the
number of assignments... Several tens of microseconds.
That is: do not dereference a null pointer when -- during startup, when
no files have been opened yet -- the search history file is read in and
a section contains more than the maximum number of items.
This fixes https://savannah.gnu.org/bugs/?68545.
Bug existed since version 4.2, commit 34d22d3f.
There is no reason to redirect nano's output, as it is just a lot of
ANSI codes, so not allowing this redirection has no negative effect.
But forbidding the redirection will prevent users from accidentally
doing so and then getting stuck, not realizing what has happened.
Signed-off-by: Vincent Yang <yang.vincent.h@icloud.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
These are the two most important commands, so it's good to have them
in the man page, especially since the help lines do not list ^S.
Inspired-by: Sébastien Desreux <seb@h-k.fr>
"Blind" meaning that the toggle is not shown in the help lines
nor in the help text, and that its function (`flipgoto`) cannot
be bound to another keystroke.
This addresses https://savannah.gnu.org/bugs/?68503 and
https://lists.gnu.org/archive/html/nano-devel/2026-07/msg00006.html.
Apparently there are some users who are in the habit of typing ^W^T
when they want to jump to a specific line. Avoid frustrating their
muscle memory.
In other words: handle ^W^T and ^/^T similar to how ^W^Y and ^W^V
are handled since commit 8e302738 from seven years ago.
And put all lowercase type modifiers into a second regex.
Also, move 'register' and 'volatile' to the modifiers regex
-- the remaining ones in the last “green” regex are all C++
keywords, but that list is far from complete.
Furthermore, make the regex for binary and hex more succinct
-- the final \> will prevent an apostrophe from coming last.
C23 introduced binary numbers (things like 0b101010) and predefined
constants 'true', 'false', and 'nullptr'. Colorize them specially,
and colorize hexadecimal numbers too, for good measure.
(Note that binary and hexadecimal numbers may contain apostrophes,
for separating groups of digits, for better legibility.)
Inspired-by: Vincent Yang <yang.vincent.h@icloud.com>
The previous commit changed the help text for the Spell Checker,
so this is a good time to further improve that text. That is:
speak of "buffer" instead of "file", speak of "marked region"
instead of "selected text", make use of the standard phrase for
introducing the function keys, and modernize the title: wrap it
in "===" and don't include the redundant "Help Text".
Most of all, tune the text to the actual phase of the process:
here the user can make spelling *corrections* -- the checking
has already been done.
Otherwise the help viewer would attempt to highlight something random,
*and* the original highlighting would be gone after closing the viewer.
This fixes https://savannah.gnu.org/bugs/?68443.
Reported-by: Mirko Adam <development@four-m.de>
The underflow bug existed since version 6.0, commit 8762e046,
the spotlight-losing bug since version 5.6, commit 37717bae.
For new users, the description is more important than the notices,
and... old users probably don't look at the man page anyway.
(Arguably, the notices should be moved to after the editing section,
but I don't like how things look then.)
When the specified name (including the final slash) is not an existing
directory, then reject it as an invalid name -- instead of complaining
later, when the user tries to save the buffer, that the specified name
is a folder, which isn't actually true.
This addresses https://savannah.gnu.org/bugs/?68433.
Buglet existed since before version 2.0.0.
That is: make it conform to the function's comment, which says that it
returns the canonical path when this path exists (and is reachable).
This addresses https://savannah.gnu.org/bugs/?68428.
Problem existed since version 6.3, commit fdd946c0.
When restoring a series of anchors, don't ruin the string by leaving
a NUL byte after each number -- restore each space that was there.
This fixes https://savannah.gnu.org/bugs/?68423.
Bug existed since version 8.5, commit 60e2f2ba, since the saving
and restoring of anchors was introduced.
Allowing to rebind M-Del gives the user the chance to make M-Bsp and
M-Del do symmetrical things: delete a word leftward and rightward,
respectively. With --modernbindings, ^H calls `help` and thus the
user can no longer bind this code to `chopwordleft` to make Ctrl+Bsp
behave symmetrically to Ctrl+Del. So, to give the user the chance
to still have symmetrical Bsp/Del combos, allow to rebind M-Del.
(Allowing to rebind M-Ins is just for symmetry -- on my two laptops
that key combination is dead: it does not produce any keycode.)
(This assumes a more modern terminal width of 100 columns. And it
allows to exercise nano's horizontal-scrolling feature on terminals
that have the old 80-column standard width.)
The reason to not call chmod() on a partially edited file is that this
file may contain stuff that the person who did the editing may not want
others to see. Whereas calling chown() is pointless for normal users,
and would be falsifying information for root.
(This does oblige the user to do `cp file.save file && rm file.save`
instead of the simple `mv file.save file` to recover the partially
edited file. But... .save files should be such a seldom occurrence
that this extra step should not be a problem.)
This addresses the third part of
https://lists.gnu.org/archive/html/nano-devel/2026-05/msg00040.html.
Reported-by: Arjun Basnet <disclose@securin.io>
The minor problem existed since version 2.2.0, since the chmod()
and chown() were added in 2009, in commit 123110c5, upon a request
by Mike Frysinger made in https://savannah.gnu.org/bugs/?27273.
This avoids having the viewport positioned slightly to the right
when an earlier match needed it shifted and the current match is
somewhere near the beginning of the line. I found that behavior
annoying, especially when the entire line fit within the viewport.
Since commit d0ee91f4 from earlier today, the full timestamp is used
('st_atim' instead of 'st_atime', for example). As macOS does not
seem to know the shorter names (see commit f516cddc from seven years
ago), define those shorter names when compiling for macOS.
Nano should do what it says: when it says "[Backup]" at the prompt,
it must make a backup. No exceptions.
True, this might overwrite an earlier backup (that the user might wish
to keep) with work by another user, but really... when multiple users
could be editing a file, this file should be under version control.
This fixes https://savannah.gnu.org/bugs/?68384.
Bug existed since before version 2.0.0.
When overwriting another file, or when appending or prepending to it,
the backup file should get the original timestamp of that other file,
not the timestamp of the file in the current buffer.
This fixes https://savannah.gnu.org/bugs/?68385.
Bug existed since before version 2.0.0.
Nano cannot edit directories, so when the user specifies a solitary
tilde on the command line, they can only mean a file by that name.
(Other editors behave like this too, with the exception of Emacs.)
This addresses https://savannah.gnu.org/bugs/?68373.
Reported-by: Chris Martin <987687@gmail.com>
• add operators `&`, `|`, and `~` (Lua-5.3)
• add statements `goto` (Lua-5.2) and `global` (Lua-5.5)
• drop `math` functions `atan2`, `cosh`, `sinh`, and `pow`
(deprecated by Lua-5.3, `frexp` and `ldexp` returned in Lua-5.5)
• drop function `module` (deprecated since Lua-5.2)
• drop `package.seeall` (gone together with `module`)
• drop functions `getfenv` and `setfenv` (gone from Lua-5.2)
• drop functions `math.log10` and `table.maxn` (Lua-5.2)
• move function `unpack` to the `table` library (Lua-5.2)
• drop `math.mod` (renamed to `math.fmod` since Lua-5.1)
• add function `table.create` (Lua-5.5)
• add function `warn` (Lua-5.4)
Also, colorize only `==` as an operator, not a lone `=`,
because coloring also the latter looked too garish.
Furthermore, colorize labels (`::somename::`) specially,
and give _G and _VERSION from the rule for basic functions
their own rule as they are not functions.
Main reference:
https://lua.org/manual/5.5/contents.html#index
This coloring rule existed since the syntax for Lua was added
(fifteen years ago, in commit 090e2cf7), but it was commented
out -- probably because it came after the coloring rule for
multiline comments, and would thus recolor those comments red.
Seven years later, commit 21cd953e removed the inactive rule,
but after just seven months, commit bf594939 swapped the order
of the coloring rules for strings and comments, and since then
a coloring rule for multiline strings would have worked right.
(Also, remove a rule that doesn't make sense -- the one that
colored everything between [[ and ]] in brightwhite first.)
The `flipgoto` toggle (^T) made for an uneven number of help items in
the Where-Is and Go-To-Line menus, and an odd item doesn't look good.
Also, removing the ^T toggle from the Where-Is menu makes its number
of help items equal to that of the Replace menu, which looks nice
when toggling between the two with ^R. And reducing the number of
help items gives the remaining ones more space, which will allow to
unabbreviate three of them in the next commit, which will look better.
Furthermore, this gets rid of the strange and unclear "Go To Text" tag
in the Go-To-Line menu.
Users who insist on having the ^T toggle can help themselves:
bind ^T "{cancel}{gotoline}" search
bind ^T "{cancel}{whereis}" gotoline
The only difference with the old behavior is that these bindings
don't preserve what was typed at the prompt before ^T was hit.
Also, say "GNU nano" instead of "version".
Having the name of the software on the left and the date in the middle
aligns better with preponderant practice.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
As libmagic, ncurses, and terminfo are software components that
aren't topics of nano's own man pages, use italics for them.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Also protect them from hyphenation (by prepending \%)
and add hyphenless break points (\:) to lengthy file names.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The \(xx style looks ugly with its unbalanced left parenthesis,
and \[bu], \[Fc], and \[md] are already being used.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The plus and the comma are literals, so should be in bold.
(See commit a06b921f1 from seven years ago.)
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Twenty five years after the Mac switched from Carriage Return (CR)
to Line Feed (LF) as the line ending, it is time to ditch the code
for reading and writing the old format.
Permitting everyone to write to the .local directory gave attackers
(on platforms where umask is 000) a tiny opportunity to become the
owner of the .local/share subdirectory, which would allow them to
install malicious .desktop files.
This fixes https://bugzilla.redhat.com/2455314.
Reported-by: Michał Majchrowicz <mmajchrowicz@afine.com>
Patch-by: Michał Majchrowicz <mmajchrowicz@afine.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Bug existed since version 2.9.1, commit 4200ed30,
from shortly after support for XDG was added.
With this change, any format specifiers that the now third parameter
of statusline() *might* contain will not lead to unintended accesses
of memory.
Suggested-by: Jonathan Echavarria <jrec93@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
When a filename contains things that look like format specifiers
(%s, %p, %n, ...) and opening this file throws some error and this
file is opened together with others, then switching to the relevant
buffer would cause the %x parts to be interpreted as actual format
specifiers, resulting in the leakage of information, or in a crash,
or possibly in arbitrary memory writes.
Reported-by: Jonathan Echavarria <jrec93@gmail.com>
Patch-by: Jonathan Echavarria <jrec93@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Otherwise, when the cursor is near the bottom of the viewport, and there
are overlong lines visible *above* the cursor, it is frustrating that
nano refuses to scroll sideways further than the bottom lines allow.
(Trying to move the cursor up has to happen before trying to move it
down, otherwise nano can get "stuck" on a long line that is present
just below the viewport.)
More than redrawing the entire screen, its most obvious effect is
centering the current line, which is a movement of the viewport.
(Also, improve the wording for Alt+G.)
The list of filenames-plus-their-last-cursor-position contains just one
cursor position per file, not a record of the last two hundred cursor
positions per file. So the name `register` is much more fitting than
the name `history`.
Also, correct a comment.
The previous commit restricted the line-jumping behavior of the cursor
to just the lines in the current viewport, thus keeping the viewport in
the (linewise) same position in the buffer.
When the current line is not long enough to allow the viewport to be
scrolled another tabsize to the right, then look for a longer line
only within the current viewport (and after the current line) --
because changing the vertical position of the viewport when doing an
essentially horizontal movement was not a good idea.
Put it at CUSHION columns, not at CUSHION+1 columns, when scrolling to
the right and the cursor would otherwise be outside this inner frame.
(The -1 and +1 came from attempts to make it work before I decided to
make it scroll a tabsize number of columns.)
If all text on a line is scrolled offscreen to the left, it looks ugly
to show the highlighted "<" continuation marker. And it is misleading:
there is nothing onscreen (on that line) that is continued on the left.
This will allow the user to make <Alt+Left> and <Alt+Right> scroll
sideways, similar to how <Alt+Up> and <Alt+Down> scroll vertically,
so that Alt plus the arrow keys work in a consistent manner.
Nowadays probably most people use <Alt+Left> and <Alt+Right> for
switching between buffers, and most of the others use M-, and M-.
-- most likely nobody uses M-< and M->, as they require holding
down Shift (on a US keyboard).
M-< and M-> seem like a good choice for the sideways-scrolling
functions, because "<" and ">" are used to indicate offscreen
continuation of the line, and requiring the user to hold Shift
is good as it helps to prevent accidental horizontal scrolling.
Now that nano can do whole-window sideways scrolling, it makes sense
to have the functions `scrollleft` and `scrollright` -- analogous to
the functions `scrollup` and `scrolldown`. Because having to first
navigate the cursor to an overlong line and then pressing <End> (or
holding down <Ctrl+Right>) in order to see what is on the rest of
the line does not speak "ease of use". (Sure, toggling softwrap is
much easier, but that messes with the vertical alignment of things.)
The `paintlen` variable becomes non-zero only when the endmatch
is onscreen, so choose instead a sure way of setting the `index`
to the end of the endmatch.
This fixes https://savannah.gnu.org/bugs/?68104.
Bug existed in this form since version 2.4.3, commit 3f1878d9
(things being worse before that), but became visible since the
introduction of whole-window sideways scrolling.
This avoids unneeded full redraws for simple cursor movements.
This addresses https://savannah.gnu.org/bugs/?68105.
Problem existed since whole-window sideways scrolling was introduced
in commit 7779a199 from five weeks ago.
Also, colorize more quoted symbols and booleans, make the green for
syntax words and the blue for keywords lighter, and show comments
in grey italics. Also, don't miscolorize some empty strings as if
they were the start of a multiline string.
This addresses most of https://savannah.gnu.org/patch/?10558.
Only the cut-from-cursor toggle should break a chain of cuts or copies,
because it affects how those operations behave. All other toggles have
no effect on those operations nor on the position of the cursor, so they
should not break a chain of cutting or copying keystrokes.
Achieve this by reshuffling a fragment of code to before the fragment
that triggers cutbuffer clearing for most operations.
(This has as interesting side effect that none of the toggles breaks a
chain of completions either.)
This fixes https://savannah.gnu.org/bugs/?68050.
Bug existed since version 4.3, commit 6c4f228f.
Starting the recording or replaying of a macro does not change anything
about the position of the cursor or the state of the buffer, so those
functions should not interrupt a series of cuts (^K) or copies (M-6).
This allows a macro to complete a series of cuts or copies that were
initiated manually (or by a previous macro).
This addresses https://savannah.gnu.org/bugs/?68046.
When the user stops a macro recording immediately after starting it,
cancel the recording and restore the macro that existed previously,
instead of storing a new empty macro.
This avoids overwriting an existing macro when the user realizes at
once that they've hit `recordmacro` instead of `runmacro`.
Signed-off-by: Charles Mirabile <cmirabil@redhat.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
When using --jumpy, the viewport scrolls vertically in steps of
half a screen (height). Then it makes sense that the viewport
also scrolls horizontally in steps of half a screen (width).
Parentheses were missing in the declaration of wmemchr().
They were added two months ago in gnulib commit df17f4f37e.
This addresses the first part of https://savannah.gnu.org/bugs/?67954.
Reported-by: Rudi Heitbaum <rudi@heitbaum.com>
In the prompt bar, clicking beyond the end of the answer places the
cursor at the end of the answer. Then it makes sense that clicking
before the beginning of the answer places the cursor at its beginning.
With --mouse and --indicator, clicking in the rightmost column of
the edit window (the "scrollbar" area) now makes the cursor jump
to the line that places the indicator at the clicked position.
Inspired-by: Firefox, and originally by tilde and fte.
When going to handle clicks on shortcuts, the help lines are present,
so we know exactly where the prompt is (third line from the bottom),
so there is no need to first convert the coordinates to be relative
to the bottom window and then restore them when `mouse_y` is zero.
Only the Yes-No routine handles clicks on shortcuts itself, so just
exclude that menu from the shortcut handling by mouse, instead of
burdening every call with an unclear parameter.
This refixes https://savannah.gnu.org/bugs/?56033.
This became needed after the previous commit removed the regeneration
of the screen from the blocking/unblocking of SIGWINCHes.
Otherwise a SIGWINCH could occur between finalizing the reading of the
specified files and becoming ready for user input, which would result
in the first keystroke getting transformed into the THE_WINDOW_RESIZED
meta symbol, and thus effectively being discarded.
This fixes the third part of https://savannah.gnu.org/bugs/?67635.
The issue was reported by `twofiftysix`.
Buglet has existed for a long time.
Otherwise nano is deaf for SIGWINCHes during several milliseconds,
which can cause it to start off with wrong dimensions.
This fixes the second part of https://savannah.gnu.org/bugs/?67635.
The issue was reported, and the solution suggested, by `twofiftysix`.
Buglet has existed for a long time.
Otherwise 'currmenu' still has an invalid value, causing a division by
zero in bottombars() because shown_entries_for() returns zero.
This fixes the first part of https://savannah.gnu.org/bugs/?67635.
The issue was reported by `twofiftysix`.
Bug existed since version 8.6, commit 09d574ba.
The feature is activated by preceding the command with two pipes (||).
This lets the command's output go to the terminal, enabling the user
to implement the OSC52 copy-to-clipboard command with a string bind:
bind M-* "{execute}|| printf "\033]52;c;%s\007" "$(base64 | tr -d '\n')" {enter}{undo}" main
This keystroke now copies the buffer (or the selected region) to the
local system clipboard, also when nano is running on a remote host --
if and when the used terminal implements the OSC52 command.
Inspired-by: Alessandro Carminati <alessandro.carminati@gmail.com>
When Enter is pressed at the end of a line that contains only blanks
while --autoindent is in effect, and thus this line gets emptied, then
the mark should be adjusted accordingly (when somewhere on this line).
This fixes https://savannah.gnu.org/bugs/?67578.
The issue was reported by `correctmost`.
Bug existed since version 2.8.1, commit 005ee8ed, but
became more exposed since version 4.0, commit f7f5514e.
Until two commits ago, a full refresh (^L) would first refresh the
screen and then reread the file list and redo the screen again.
Now it will just reread the list and redo the screen, skipping the
redundant refresh. The latter is done only for the tiny version.
Also rename a label, to be more precise.
The user may have resized the window not only while in the help viewer
but also while at the Search or Goto prompt. Ensure that after all of
them the browser rebuilds the list according to the current dimensions.
This fixes https://savannah.gnu.org/bugs/?67294.
Bug existed since version 2.5.3, commit 813f9f72.
When a line number is given on the command line, the position-history
file needs to be read first, because it might contain saved anchors.
(Before placing the cursor on the given line, or searching for a given
string, the current position now needs to be set back to top-of-file,
as otherwise the saved column position is likely to be inherited, or
the search will start from the inherited position.)
This fixes https://savannah.gnu.org/bugs/?67272.
Bug existed since version 8.5, commit 60e2f2ba,
since the saving of anchors was introduced.
Twelve years ago, commit 2e4228f7 added a check for the 'ncursesw/
ncurses.h' header file. A week later commit 66e5972c removed that
check again, but forgot to remove the corresponding #ifdef.
This addresses https://savannah.gnu.org/bugs/?67225.
Showing only "Placed anchor" and not "Removed anchor" makes it possible
to notice without looking at the status bar whether an anchor has been
placed or removed. (The mini bar is not just a different interface but
is also about minimizing status-bar output.)
When line numbers are present, any anchors are displayed in the margin,
so it should be rather obvious where the cursor jumped to -- no need to
mention this on the status bar.
When line numbers or the mini bar are active, there is no need for
the status-bar messages. Only when both line numbers and mini bar
are absent, the feedback messages are needed.
Now that anchors are always saved, there is no need to differentiate
anchors that are saved (￭) from anchors that will evaporate (⬥).
Choose a new appearance (†) to signal the changed behavior.
(And because I didn't much like the look of the block.)
Let the saving of anchors not depend on the presence of an anchor
on the first line. That was a clever mechanism to allow avoiding
the unnecessary saving-of-anchors, but... it was awkward and ugly.
This may seem a little wasteful, as line=1,column=1 is the default
cursor position, but this change enables the next commit: always
saving any anchors. In the bargain, the position-history file now
contains a list of all files that were recently opened with nano.
Putting the record for the last-edited file at the top of the list
ensures that (in case of a duplicate entry) the newest entry will
be encountered first and thus reused. It also makes searching the
list faster, because the files that the user is likely to soon edit
again will be near the top of the list instead of near the end.
This fixes https://savannah.gnu.org/bugs/?67120.
Problem existed since version 2.3.0, since position logging was
introduced, but was aggravated by the recent anchor-saving code.
And as the presence of an anchor is now visible in the mini bar,
the "Placed anchor"/"Removed anchor" messages are no longer needed
when the mini bar is active.
When an anchor is present on the first line of the buffer, make any
anchors appear as little blocks (￭) instead of the usual diamonds (⬥).
This different appearance lets the user know whether a placed anchor
anywhere in the file will be saved or not -- when line numbers are
active. (In an 8-bit locale an = replaces the usual +).
When an anchor is placed on the first line in a buffer and --positionlog
is active, nano will now save the positions of the anchors when the file
is closed, and will restore the anchors when the file is reopened.
(The positions are stored in the file-positions history file, along
with the cursor position.)
This fulfills https://savannah.gnu.org/bugs/?62269.
Requested-by: Shi Yanling <sylphenix@126.com>
Requested-by: Sébastien Desreux <seb@h-k.fr>
Sponsored-by: Sébastien Desreux <https://doc-solus.fr>
The function has_old_position() was used just twice, and both calls
were followed by basically the same call of goto_line_and_column().
So... move the latter call into the first function, to avoid the
unneeded passing back and forth of the line and column numbers.
In some locales certain normal ASCII characters are not included in
the ranges [A-Z] and [a-z]. So, use [[:upper:]] and [[:lower:]]
instead, and [[:alpha:]] for [A-Za-z], and similarly for others.
This fixes https://savannah.gnu.org/bugs/?67094.
Calling tolower() on the 'I' (of "M-I") in a Turkish locale will not
return 'i' but 'I' instead. This is because the lowercase of 'I' is
'ı' (a dotless i), which does not fit in an 8-bit character type, so
tolower() will return the 'I' unchanged.
This fixes https://savannah.gnu.org/bugs/?67092.
Buglet existed since before version 2.2.0.
Nano used to exit always with a success status (0). But now, if
the user wants to make nano report failure to a calling program,
they can use ^X^Q (when the buffer is modified) or ^O^Q (always).
This fulfills https://savannah.gnu.org/bugs/?65755.
The label "Discard buffer" is rather long (and is in most translations),
so make the item the last-but-one so that it effectively has the space
for two labels available (because the number of items in the WriteOut
menu is currently uneven).
In my experience the default cycling behavior of ^L was puzzling:
hitting ^L twice left me wondering sometimes: where is the cursor?
Inspired-by: Peter Michaux <petermichaux@gmail.com>
Some keyboard layouts allow typing hard spaces (U+00A0),
which means that sometimes they can get typed by accident.
Colorize those spaces to make such accidents noticeable.
Inspired-by: Sébastien Desreux <seb@h-k.fr>
Allow some people to use 'set whitespacedisplay' in their rcfiles
(or --whitespacedisplay on the command line), but leave the option
undocumented as I think it shouldn't exist.
Since nano-8.1 (which moved to gettext-0.20), compiling on Cygwin
failed with: "undefined reference to `libintl_dgettext'". Avoid
this by moving the '-lintl' argument to after the gnulib one.
Reported-by: Philippe Baril Lecavalier <pbl.ltx@gmail.com>
For some reason `autopoint` from gettext-0.20 (used since nano-8.1)
started to include the 'm4/host-cpu-c-abi.m4' file. Ignore it, to
prevent it from accidentally getting tracked.
Signed-off-by: Peter Michaux <petermichaux@gmail.com>
The ceck is only done at the start of a line, because in other places
the BOM will be glued to the preceding character.
This partially addresses https://bugs.debian.org/964901.
Reported-by: Nils König <oneric@oneric.de>
Until the previous commit, nano used to beep for any command code
in an external paste. It's better to continue doing that.
(When pasting multiple lines, it's debatable whether nano should
beep for each discarded CR. But for any other command code, it
definitely should beep. Maybe it should even show a message.)
Ask ncurses to recognize the escape sequences that mark the start
and end of a bracketed paste, and thus benefit from the waiting that
ncurses does for an escape sequence to complete. This helps prevent
nano from failing to recognize an end-of-paste sequence (resulting
in hanging or inserting some sequence characters into the buffer).
This addresses https://savannah.gnu.org/bugs/?66858 in a better way.
Reported-by: Doug Smythies <dsmythies@telus.net>
Let the more general flaw handling (added in commit 41c1b962, and
amended in the previous commit) handle also this case: it's better
to let the user know that they are using poor pasting software than
to silently work around the issue.
This effectively reverts commit 555a9878 from last week.
If (on a bogged-down computer) a paste goes so slow that the bytes
come in one by one, nano shouldn't discard any of them -- the user
is unlikely to appreciate this. Just switch the bracketed paste
off, for the possibility that the closing sequence went missing,
and accept that this closing sequence gets pasted into the buffer.
Since the previous commit, the escape-sequence-parsing code does not
set 'bracketed_paste' to FALSE any more when the closing sequence is
deficient. So, the browser and viewer need to do that themselves.
Also, instead of just beeping and wordlessly discarding a paste when
it's done in the file browser or help viewer, report that it is being
ignored. This is much more friendly.
A bracketed paste should be one large batch (or several batches)
of bytes, not single bytes coming in one by one. When the latter
happens, assume the end-of-paste sequence got swallowed somehow,
stop the bracketed paste and display a warning, while discarding
the first byte that came in alone.
This change was inspired by this report from Doug Smythies:
https://lists.gnu.org/archive/html/nano-devel/2025-02/msg00001.html
When pasting something into nano over OpenSSH_for_Windows, the final
tilde of the end-of-paste sequence can lag some 29 ms behind the rest
of the sequence, causing ncurses to split it off into a next batch of
bytes. Accommodate for this by noticing the missing tilde and then
waiting at most one second for it to arrive. This prevents the tilde
from appearing spuriously in the buffer after the paste.
This addresses https://savannah.gnu.org/bugs/?66858.
Reported-by: Doug Smythies <dsmythies@telus.net>
When the user types something at the Execute prompt and then invokes
one of the six tools or special functions (that don't take any input),
stash the typed string and restore it upon the next invocation of the
Execute menu. This way the typed string is not lost when the tool or
special function was invoked by accident -- which it likely was, as
those tools and functions don't take any input from the prompt.
This addresses https://savannah.gnu.org/bugs/?66637.
Suggested-by: Evgeny Pestov <fsdhfhhf@gmail.com>
Also, remove redundant double quotes, protect single quotes from
possibly getting misinterpreted, and protect periods from getting
treated as end-of-sentence. Also, use \e instead of \\.
(Overlong lines are left alone -- they don't bother me.)
This partially addresses https://bugs.debian.org/1095957.
Reported-by: Bjarni Ingi Gislason <bjarniig@simnet.is>
Functions like tolower() expect characters in the range -1..255.
Reference: https://savannah.gnu.org/bugs/?50289.
The other occurrences of toupper(), tolower(), and isxdigit() that
don't do a cast are fine, because the values of 'code' or 'keycode'
are already guaranteed to be in range by the surrounding code.
For the affected four "tags" only 10 character cells are available
(on an 80-column terminal) since they are used in the help viewer.
For the other two "tags" 15 cells are available, as they are shown
only when the terminal is at least 380 columns wide.
Indirectly-reported-by: Rafael Fontenelle <rafaelff@gnome.org>
Previously some of these regexes could color part of a directive;
for example, the `.int` part of `.intel_syntax`.
Signed-off-by: LIU Hao <lh_mouse@126.com>
This avoids those arguments getting colorized as if they were regexes
(when the relevant lines are uncommented), and instead allows them to
get colorized in bold purple by a dedicated rule.
Since commit 50954a4b from two years ago, a replacing session will
not ever change the final empty line, and thus a fresh magic line
will never need to be undone or redone.
This complements commit c6a26641 from five months ago.
Most calls of draw_all_subwindows() are made while in the edit window.
The only call that could occur while in the file browser is the one in
regenerate_screen(). So only this call needs to be guarded against
being made while the file list is being shown.
This can be useful when replacing text in a Japanese locale,
avoiding the need to guide the input method to produce "A".
Inspired-by: Takeshi Hamasaki <hmatrjp@users.sourceforge.jp>
When the mark is on, moving the cursor to the top or bottom row should
highlight the relevant area -- thus requiring a call of edit_refresh()
to be scheduled.
Also, drop two calls of place_the_cursor(), as that is done anyhow in
the main loop, either directly, or indirectly through edit_refresh().
This fixes https://savannah.gnu.org/bugs/?65992.
Reported-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Bug existed since version 8.0, since Alt+Home/Alt+End were introduced.
Instead of simply overwriting the current contents of the keystroke
buffer with the contents of the macro buffer, insert the latter's
contents at the head of the keystroke buffer.
This allows using {runmacro} in a string bind, and allows typing ahead
over a laggy connection after invoking `runmacro` (normally with M-;).
This fixes https://savannah.gnu.org/bugs/?65991.
Reported-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Bug exists since version 2.9.4, since string binds were introduced.
When NumLock is off, let Ctrl plus the central key on the numeric keypad
center the current line.
(This binding is not advertised anywhere
-- it's left as a little Easter egg.)
As version 0.20 of `autopoint` no longer overwrites 'extern-inline.m4',
there is no need any more for the custom calls of the various parts of
`autoreconf`.
This effectively reverts commit 4a1db96d from two and a half years ago.
Gettext-0.20 is the first version where its `autopoint` does not
overwrite the newer 'extern-inline.m4' from gnulib.
Version 0.20 is five years old, so most users will be on a distro
that includes that version of gettext or a newer one.
Also, reshuffle Alt+T for balance, slightly reword the description
of Alt+A (as it differs in nature from the other toggles), and add
some spaces for better alignment.
Something similar can be achieved with:
bind ^T "{center}{bottomrow}{center}{toprow}" main
bind ^B "{center}{toprow}{center}{bottomrow}" main
But that requires allocating two extra shortcuts, and it works right only
when the edit window has an odd number of rows, not with an even number.
Also, this new ^L behavior is available by default, out-of-the-box.
On the first call, `cycle` centers the line with the cursor, on the
second consecutive call it pushes that line to the top of the viewport,
and on the third consecutive call to the bottom of the viewport.
The function do_tab() is only ever called when in the main edit window,
and never called while a bracketed paste is in progress.
(The two conditions were thoughtlessly copied when this fragment of code
was moved here three commits ago.)
When softwrapping with a tabsize larger than the width of the viewport,
scrolling one row when the cursor goes offscreen might not be enough,
so in that case use edit_redraw() instead.
This fixes https://savannah.gnu.org/bugs/?65860.
Bug existed since version 2.9.6, commit 0d9080a2.
This allows a {tab} in a string bind to indent a marked region.
This fixes https://savannah.gnu.org/bugs/?65859.
Problem existed since version 7.0, since braced function names
were introduced.
Activating --modernbindings when the binary's name starts with "e"
interferes with Debian's alternatives system that symlinks `editor`
to `nano` in a default install.
(Also: why "e"? It would have made more sense to check for "m",
similar to the checking for "r" for a restricted nano.)
This reverts commit 580eaf29 from fifteen months ago.
This addresses https://savannah.gnu.org/bugs/?65810.
Reported-by: Colin Snover <nano@zetafleet.com>
The names of the authors were retrieved from:
git log -p --follow syntax/<name>.nanorc
and from:
git log -p --follow --all -- doc/nanorc.sample
For some files the original author is unclear, or
the file is/was too small to mention an author for.
The typo prevented several keywords from getting colorized.
This addresses https://savannah.gnu.org/patch/?10459.
Bug existed since version 2.1.6, commit 513157df,
since the Fortran syntax was introduced.
The succinct function descriptions in the help lines are not shown in
reverse video by default, so they are not bolded by -D/--bold either.
Also, mention 'promptcolor' and 'minicolor' where they were missing.
Prevent also the toggling of Append and Prepend. All four functions
should not be available in restricted mode, and are absent from the
WriteOut menu in that mode, but using {browser}, {backup}, {append}
or {prepend} in a string bind allowed to bypass the menu checks.
This fixes https://savannah.gnu.org/bugs/?65819.
Problem existed since version 7.0, since braced function names
were introduced.
Since version 3.2, commit 5ca444e5, nano reads the nanorc files also
in restricted mode (when not also --ignorercfiles is given), meaning
that syntaxes are available and that a specific syntax can be selected
on the command line. So, the --help output in restricted mode should
list the relevant option: -Y<name> / --syntax=<name>.
(This should have been part of commit b81995af from six years ago.)
The bindable function 'nowrap' has been deprecated for three years,
since version 5.5, commit e14127b8.
(The obsolete options --nowrap and 'set nowrap' continue to exist.)
When one has installed additional syntaxes, one tends to forget
what exactly is there. So it's nice to be able to list them.
The syntaxes are listed in the reverse order in which they were
read: the most recent first.
The long form of the option is, of course, --listsyntaxes,
which can be abbreviated to --list.
This fulfills https://savannah.gnu.org/bugs/?65779.
The feature was suggested by `davidhcefx`.
Stop doing colon parsing by default, to avoid surprises and frustration
for users that have filenames that end in a colon plus digits.
The equivalent rcfile option is, of course, 'set colonparsing'.
Using +1, or similar, before the filename disables any colon parsing
and the filename is taken as is.
Starting from the end of the provided filename avoids needlessly looking
at colons that are somewhere in the middle of the path or the filename.
It also avoids inconsistenly interpreting a specified line number as a
column number when the filename itself ends with a colon plus digits
and the filename without the colon plus digits exists too.
This also removes the eliding of a backslash before a colon, which
would mangle the filename if the name actually contained a backslash
followed by a colon.
Negative line and column numbers are no longer allowed when using the
colon notation.
This fixes https://savannah.gnu.org/bugs/?65781,
and fixes https://savannah.gnu.org/bugs/?65782.
Problems existed since version 8.0, since colon parsing was introduced.
While updating the screen, ncurses by default polls the input source
now and then to see if there is new input, and if so, stops updating
the screen and waits for the next call of doupdate() or refresh().
https://lists.gnu.org/archive/html/bug-ncurses/2024-05/msg00077.html
Disable this polling, as it is just a waste of time, and there *might*
be situations where the intruding keystroke does not actually trigger
a new update, which could result in a half-updated screen.
When the file 'foo:24' exists (but not 'foo') and the user wants to
use the colon notation to place the cursor on a certain line, then
nano would first interpret the given line number as a column number,
before noticing that 'foo' does not exist and then skipping the first
colon. So, when such a misinterpretation occurs, the column number
needs to be reset to zero.
When the user specifies, on the command line, a filename that ends with
a colon plus digits, and that filename exists in the file system, then
open that file, instead of interpreting the digits as a line number.
Also, if the filename stripped of the colon plus digits does not exist,
then do not interpret the digits as a line number either but treat them
as part of the file name.
Before this change, the user would have to escape the colon whenever
they wanted to open a file whose name ended with a colon plus digits.
Now the user needs to escape the colon only when 'foo' exists and they
want to create, say, 'foo:24'.
Problem-was-reported-by: Ralph Corderoy <ralph@inputplus.co.uk>
https://lists.gnu.org/archive/html/nano-devel/2024-05/msg00001.html
Mitigation-was-suggested-by: Mike Scalora <mike@scalora.org>
https://lists.gnu.org/archive/html/nano-devel/2024-05/msg00008.html
Nano does not recognize the urxvt escape sequences for other
<Alt+cursorkey> combinations either. And with the previous
two commits, the urxvt user can now "help themselves".
This reverts commit 363a4378 from three days ago.
This makes those keystrokes work too when --raw is used.
But more importantly: these raw sequences can be used in an
~/.Xresources file to override the odd behavior of urxvt for
those keystrokes, making the previous commit redundant.
When pressing Alt+Home/Alt+End on urxvt, urxvt either sets the high bit
of the last byte in the sequence for Home/End (when Meta8 is True), or
sends an extra escape before that same sequence (when Meta8 is False).
Accommodate for this bug by recognizing the produced code sequences.
Indirectly-reported-by: Sébastien Desreux <seb@h-k.fr>
https://lists.gnu.org/archive/html/nano-devel/2024-05/msg00007.html
The 'openfile->fmt' element gets initialized to 'UNSPECIFIED',
so the code has to take that possibility into account.
This fixes https://savannah.gnu.org/bugs/?65676.
Bug existed since version 8.0, commit fe4f74f6.
This closes a window of opportunity where the emergency file could be
replaced by a malicious symlink.
The issue was reported by `MartinJM` and `InvisibleMeerkat`.
Problem existed since version 2.2.0, commit 123110c5, when chmodding
and chowning of the emergency .save file was added.
When recording a macro over a laggy connection or on a slow, overloaded
computer, several keystrokes could be recorded in one burst, and if any
but the last of those keystrokes was the shortcut for `runmacro`, then
running the macro would lead to an infinite loop and nano would hang.
This new implementation of snipping the "last keystroke" will, however,
snip *too many* keystrokes when several of them were recorded at once
and `runmacro` or `recordmacro` was among them, resulting in a cropped
and thus misrecorded macro. But... that's better than hanging.
In general, though, the user should be slow and deliberate when
recording a macro: waiting for nano to have processed the last
keystroke before typing the next.
This fixes https://savannah.gnu.org/bugs/?65649.
The issue was reported by `correctmost`.
Problem existed since version 2.9.0, since macros were introduced.
These calls of do_delete() were meant to delete just one character,
but over time do_delete() morphed into doing also other things...
Change the calls to invoke the correct function instead.
(This also avoids snipping any zero-width characters that come after
a snipped space, as that is probably not what the user wants.)
This fixes https://savannah.gnu.org/bugs/?65636.
The issue was reported by `correctmost`.
Bug existed since version 3.2, commit ae3ec178,
when --zap was introduced.
Redoing an automatic hard-wrap while one or more chunks of the affected
line are offscreen, can leave 'firstcolumn' with a value that doesn't
fit the situation. So, make sure that it has a valid value.
This complements the previous commit.
This fixes https://savannah.gnu.org/bugs/?65611.
The issue was reported by `correctmost`.
Bug existed since version 2.8.6, commit e375995d.
When one or more chunks of the current line are above the viewport,
and this line gets hard-wrapped, then 'edittop' needs to be advanced,
otherwise the first row could be blank -- representing a chunk that
doesn't exist any more.
This fixes https://savannah.gnu.org/bugs/?65604.
The issue was reported by `correctmost`.
Bug existed since version 2.8.6, commit e375995d.
When opening a nonexistent file with nano, it likely consists of only a
name without any path component, and thus without any slash. So when a
file regex checks for a slash, it should check also for start-of-string.
This fixes https://savannah.gnu.org/bugs/?65591.
Problem existed for the Makefile since version 2.9.8, commit 22663f8a,
and for .profile since version 3.0, commit 4a268678 (but earlier, nano
did not recognize .profile files at all).
When an entirely blank line is trimmed (when --autoindent is active and
Enter is pressed while the cursor is at the end of the current indent),
the mark needs be adjusted *before* 'current_x' is zeroed, otherwise the
mark gets moved too much to the right, which causes the region to become
bigger than what the user intended, or leads to accessing unallocated
memory.
This fixes https://savannah.gnu.org/bugs/?65586.
The issue was reported by `correctmost`.
Bug existed since version 2.8.1, commit 005ee8ed.
A "Read xx lines (converted from...)" message should be suppressed when
--zero or --minibar are active (just like the normal "Read xx lines"),
as otherwise it gets shown at a confusing moment when multiple files
are opened at the same time. The message should get shown, however,
when inserting a file into the current buffer.
This fixes https://savannah.gnu.org/bugs/?65560.
Bug existed since version 6.0, commit f147131e.
The idea of the warning was that `row < 0 || row >= editwinrows` would
never be true: that the check was redundant and could be removed.
As it appears to be too hard to make sure in advance that a chunk will
not fall outside the viewport, just drop the warning and leave the check
in place.
This also addresses https://savannah.gnu.org/bugs/?64168.
Reported-by: Matteo Raso <matteo_luigi_raso@protonmail.com>
When we're on the last row in the viewport, it is unwise to try and draw
the next line.
This fixes https://savannah.gnu.org/bugs/?65539.
The issue was reported by `correctmost`.
Bug existed since commit c2322f85 from three days ago.
Drawing a line will allocate multidata for it (even when the line is
actually empty), so that this multidata will not be missing later on
when the next line gets drawn in the same burst of keystrokes.
(This also removes the triggering of a full refresh when line numbers
are active: only the new magic line needs to be additionally drawn, in
order to get the line number printed.)
This fixes https://savannah.gnu.org/bugs/?65516.
The issue was reported by `correctmost`.
Problem existed since version 6.3, commit 80c2000f.
It is bindable only in the Insert menu -- in the Execute menu it has
a "blind", unadvertised binding (because I consider toggling between
menus somewhat of a misfeature).
On my current laptop, typing <Alt+Insert> is awkward because it requires
holding down <Fn> too. Also, M-" and M-' are in the normal symbols area
of the keyboard, which makes them easier to type and more discoverable.
Furthermore, being next to M-: and M-; (on a US keyboard) reinforces the
meanings: start/place, stop/remove, run/goto.
Normally, when recording a macro, users will make their keystrokes
slowly and carefully, and will most likely wait to see the effect
of the previous keystroke before making the next. So, the chances
of two `recordmacro` keystrokes coming in in quick succession is
normally nil. The 'macro_length' variable just needs a guard to
prevent it from underflowing when someone is hammering the keys.
This fixes https://savannah.gnu.org/bugs/?65394 in a better way.
When the justified region fits in its entirety onscreen, then it should
be shown in its entirety, because the user is probably curious what the
region looks like after justification. This behavior will mean that
the line above the topline of the screen will still have multidata
(when the syntax has multiline regexes). When the justified region
does not fit onscreen, then as much as possible should be shown --
meaning that the cursor should be either at the top or the bottom
of the viewport, meaning that it should not be centered.
This fixes https://savannah.gnu.org/bugs/?65482.
The issue was reported by `correctmost`.
Bug existed since version 4.0, since justifying a region was introduced.
When justifying a region that was marked backwards, the cursor
should stay at the beginning of this region. The old logic was
faulty because mark_is_before_cursor() does not give the correct
result *after* the justification has been done: for some reason
the mark ends up always before the cursor.
Bug existed since version 5.2, commit 0f8423eb,
which mistakenly removed the auxiliary variable. :/
The strings are gettextized further down, for the non-tiny version,
so they will get translated anyhow. The relevant translator hint
is the earlier one about "the next thirteen strings".
Also adjust an indentation, and ungettextize another string for
consistency.
With NetBSD curses, when only the cursor is moved (without writing any
text), then a call of wnoutrefresh() is needed to make doupdate() move
the cursor. Ncurses does not need this.
This addresses https://savannah.gnu.org/patch/?10438.
The calls of wnoutrefresh() after those new blank lines are not needed
for ncurses to show the cursor in the right place, but are logically
needed because things have been written to the screen in the preceding
code -- although nano seems to work correctly also without those calls.
A detailed list of changes is useful for a small number of users only,
and only when the changes are fairly recent.
The NEWS file, that contains a summary of user-visible changes and
will be useful for a larger number of users, is distributed in full.
This looks better in the help viewer (^F/^B matching the pair M-B/M-F),
and showing ^F instead of ^W for search in the main edit window will
prevent novice users from using ^W in situations where they shouldn't.
As a backward search is now normally always bound (to ^B, instead of
conditionally to ^Q), ^L should always be shown in the help viewer.
This fixes https://savannah.gnu.org/bugs/?65434.
Problem existed since commit 8a304bdf, since ^F/^B do a search.
When modern bindings are requested, ^S should save and ^Q must exit,
so --preserve and 'set preserve' need to be cancelled.
This fixes https://savannah.gnu.org/bugs/?65433.
Bug existed since commit 18b37c98, which introduced --modernbindings.
Because meanwhile the cursor might be someplace where EOF is offscreen.
This effectively reverts commit 9ccf85ea from two years ago, but also
sets 'focusing' to false so that the last line of the buffer will be at
the bottom of the edit window, where it probably was when Bsp was typed.
This fixes https://savannah.gnu.org/bugs/?65428.
The issue was reported by `correctmost`.
Bug existed since version 6.3, commit 9ccf85ea.
When a justification (or even a spell check) is undone or redone,
this might affect the matching of multiline regexes, so... schedule
a recalculation of the multidata in those cases.
This fixes https://savannah.gnu.org/bugs/?65426.
The issue was reported by `correctmost`.
Problem existed since version 6.3, commit 80c2000f.
Since commits c8363a0d and a75bf0a1 from seven years ago, the Execute
menu permits retrieving previously executed commands, but the help text
and help lines never showed the corresponding keystrokes.
Four years ago commit d3954901 made the Execute menu directly accessible,
but I preferred to not mention the ^P/^N keystrokes in the help lines,
to leave as much space as possible for the executable functions (added
in subsequent commits), thinking that no one would want to rebind those
keystrokes anyway, as the Up/Down arrows seem more logical and easier.
The issue was reported by Ivan Vorontsov:
https://lists.gnu.org/archive/html/help-nano/2024-02/msg00003.html
Since commit 50954a4b from a year and a half ago, a replacing session
will not ever change the final empty line, so a fresh magic line will
never be needed.
A freshly justified paragraph does not yet have any multidata,
and if this new paragraph has more lines than fit in the viewport
(minus one line for the cursor), then the line above the top of the
new viewport will be without multidata. The coloring code cannot
handle this, so all the multidata then needs to be recalculated.
This fixes https://savannah.gnu.org/bugs/?65396.
The issue was reported by `correctmost`.
Problem existed since version 6.3, commit 80c2000f.
The `gnulib` globbing module apparently does not handle an overload
of slashes well, so avoid feeding it more than it can take.
This fixes https://savannah.gnu.org/bugs/?65407.
Problem probably existed since version 2.3.3,
since globbing was introduced.
When the keystroke after the keystroke bound to `recordmacro` arrived
so quickly that the two got stored together in nano's keystroke buffer,
the main loop had not yet interpreted the `recordmacro` command and had
thus not yet set 'recording' to true, meaning that that second keystroke
would not get recorded.
Nano should record keystrokes into the macro buffer when fetching them
from its own keystroke buffer, not when fetching them from ncurses.
This fixes https://savannah.gnu.org/bugs/?65394.
The issue was reported by `correctmost`.
Bug existed since version 2.9.0, since macros were introduced.
During the Replace-With prompt the user could search in its help text,
which would overwite the 'last_search' string. Make therefore sure that
the latter gets restored to what it was before the Replace-With prompt.
This fixes https://savannah.gnu.org/bugs/?65381.
Bug existed since version 2.8.2,
since searching in a help text became possible.
Searching in a help text does not support using regular expressions,
so when 'inhelp' is set, do not free a compiled regex -- because if
there is such a regex, it belongs to a replacement session that is
about to begin.
This fixes https://savannah.gnu.org/bugs/?65369.
The issue was reported by `correctmost`.
Bug existed since version 2.8.2,
since searching in a help text became possible.
Only check input bytes when their count is nonzero.
This fixes https://savannah.gnu.org/bugs/?65365.
The issue was reported by `correctmost`.
The problem existed since version 5.7, commit c75a3839,
but occurred more easily since version 7.0, commit 75e5f885.
Translate mousewheel events into Alt+Up/Down key presses instead of
into plain Up/Down key presses, as the latter only start scrolling
once the cursor reaches the top or bottom.
Scrolling rather than moving the cursor is the standard behavior for
mousewheel events in GUI editors such as Gedit and Kate, as well as
in the mouse mode of terminal editors such as vim, joe, and mcedit.
Signed-off-by: Andy Koppe <andy.koppe@gmail.com>
When --cutfromcursor is active, 'current_x' needs to be set to zero when
doing a justification, so that the correct starting position gets stored
in the undo item. (Without --cutfromcursor, the value of 'current_x'
does not matter.)
This fixes https://savannah.gnu.org/bugs/?65317.
The issue was indirectly reported by `correctmost`.
Bug existed in this form since version 5.0, commit ae5a4ece.
Between versions 4.0 and 5.0, nano would not eat a line but would
instead crash when undoing a justification that was done with the
cursor away from the left edge.
This stops the execution of a macro or a string bind whenever something
unexpected happens, to prevent the waiting keystrokes from doing things
that were not intended.
Especially this prevents an infinite loop: when during the recording
of a macro the `runmacro` keystroke is typed in some menu (where the
keystroke is not bound), and the macro is later replayed in a way that
results in exiting from that menu before the `runmacro` keystroke gets
replayed...
This fixes https://savannah.gnu.org/bugs/?65301.
The issue was reported by `correctmost`.
Bug existed since version 2.9.0, since the macro feature was introduced.
When --cutfromcursor is active, 'current_x' does need to be zero for
the segment extraction to do the right thing.
This fixes https://savannah.gnu.org/bugs/?65289.
The issue was indirectly reported by `correctmost`.
Bug existed since version 4.0, commit 2500debb.
When going back from the browser to a file prompt, restore the typing
position also after a 'to_first_file' (^Y) and 'to_last_file (^V).
The cursor misplacement existed since version 5.9, commit 508301a2.
When going back to a previous prompt, restore the typing position
also for 'to_first_line' (^Y) and 'to_last_line (^V).
This fixes https://savannah.gnu.org/bugs/?65278.
Bug existed since version 5.9, commit 6d5b1656, which allowed exiting
from a Search-in-help prompt with ^Y or ^V.
When the cursor is on the last line, and an undo removes this line,
do not let 'openfile->current' become invalid.
This fixes https://savannah.gnu.org/bugs/?65279.
Bug existed since version 6.3, commit eea3e1f0.
(It should have been fixed in commit 9410a556, more than a year ago.)
Commit 18b37c98 moved the bindings of ^H and ^D further down. Now move
the bindings of <Bsp> and <Del> to after those, so that ^H and ^D will
be shown again first in the help text (when not using --modernbindings).
This allows activating the "modern" bindings without having to pass an
option, by simply invoking nano through a symlink -- for example: `en`
(short for "editor nano"), or `et` (short for "edit"), or just `e`.
With --modernbindings, instead accept ^Q^X for abandoning any changes
-- the inverse of the normal (but undocumented) ^X^Q.
This prevents the unintentional loss of work when the user hits ^Q twice
by accident.
With --modernbindings, ^Q quits, ^F finds, ^B finds backwards, ^G finds
again, ^D finds again backwards, ^X cuts, ^C copies, ^V pastes, ^A sets
the mark, ^R replaces, ^O opens a file, ^W writes out a file, ^S saves,
^Z undoes, ^Y redoes, ^P shows the position, ^T goes to a given line,
and ^E executes.
Note that with --modernbindings ^Q and ^S are always bound, meaning that
--preserve / 'set preserve' is ignored. This is necessary because ^Q is
an essential keystroke in the modern bindings.
Also note that these "modern bindings" are effective only in the main
edit window, not in the various menus. In all menus ^C means Cancel,
and I can't think of a good alternative default keystroke for that
(in order for ^C to mean Copy). And in a few menus ^V has a meaning,
and there is no good alternative for that either. So... in the menus
the user has to use M-6 for Copy and ^U for Paste (and ^K for Erase --
Cut does not exist in the menus), like with the default bindings.
Instead simply say that no linter is defined.
This fixes https://savannah.gnu.org/bugs/?65204.
Bug existed since version 5.5, commit bc368133, but before
that commit nano would crash on an empty linter command.
Instead simply say that no formatter is defined.
This fixes https://savannah.gnu.org/bugs/?65196.
Bug existed since version 4.6, since the formatter was reintroduced.
On Windows builds, gnulib might set GETRANDOM_LIB to -lbcrypt and then
use that API. But since we don't include $(GETRANDOM_LIB) when linking,
we fail. On Linux systems, this is empty as getrandom APIs are part of
the main C library already. This is also what the link requirements say
in gnulib's modules/getrandom spec.
This avoids miscolorizing part of a string when it contains a URL.
This fixes https://savannah.gnu.org/bugs/?64340.
Reported-by: Yonut Smith <deanlast3@gmail.com>
Problem has existed for more than twenty years, at least since support
for multine-line regexes was added in commit 6c1e6612 in 2002.
The terminal in VSCode splits pastes into 50-byte chunks and can
thus split an escape sequence somewhere in the middle, resulting
in nano failing to recognize the end-of-bracketed-paste sequence
and thus hanging -- until another, different-sized paste is made.
Avoid this hang by interpreting any invalid escape sequence that
starts with "\e [ 2" as a truncated end-of-bracketed-paste.
(This will leave a spurious tilde after the 39-character paste,
which is not nice but... better than hanging.)
This works around https://savannah.gnu.org/bugs/?64996.
Reported-by: Jacob Lifshay <programmerjake@gmail.com>
Even though in nano the names F13 to F24 exist, these names actually
refer to Shift+F1...Shift+F12. One cannot blame people for thinking
that F13 in nano is the same as F13 in Xorg, so... recognize the escape
sequence for the latter and map it to what nano calls F13.
This accommodates users that put F13...F16 in a custom keymap for Xorg.
This fixes https://savannah.gnu.org/bugs/?64632.
Reported-by: Danny Milosavljevic <dannym@scratchpost.org>
Problem existed since version 5.0, commit 9a6158cd.
When softwrapping at blanks, the wrapping routine should, when called
again, continue searching from where the previous chunk ended, not from
the point it reached during that previous search, because this could be
*just* beyond the space that could be the next breaking point.
This fixes https://savannah.gnu.org/bugs/?64945.
Reported-by: Andreas Schamanek <schamane@fam.tuwien.ac.at>
Bug existed since version 6.4, commit 0e9bef34.
When the user hits the M-C toggle while option --zero is in effect,
instead of complaining "Not possible", do what the user probably
tries to achieve: cancel `zero` mode and switch on `constantshow`.
This makes nano more usable for users that are accustomed to the
near universal use of ^F for Find/Search in other programs, and
especially for users that somehow access a terminal through their
browser (where ^W will, destructively, close the terminal tab).
(To keep the bindings consistent, make ^B start a backward search,
and let M-F and M-B search for the next occurrence in the matching
direction.)
Suggested-by: Chris Allegretta <chrisa@asty.org>
Suggested-by: Donnie Ferris <DonnyBahama@gmx.com>
https://lists.gnu.org/archive/html/nano-devel/2023-01/msg00001.html
This makes nano more usable for users that are accustomed to the
near universal use of ^F for Find/Search in other programs.
To keep the bindings consistent, make ^B start a backward search,
and let M-F and M-B search for the next occurrence in the matching
direction.
At least some of the VTE-based terminals claim to be compatible with
xterm-25color (and set TERM to that value). But they really aren't:
they mishandle the focus-in and focus-out events, for example. So,
catch and discard the corresponding keycodes that nano shouldn't be
seeing at all.
This improves the fix for https://savannah.gnu.org/bugs/?64578.
When the red, green and blue components of a three-digit hex #RGB code
are equal and they aren't #000 for black or #FFF for white, map them to
xterm-256color's 24-level grayscale ranging from index 232 to 255.
This means that the 14 gray levels available in #RGB codes all map to
different tones, whereas previously they mapped to only the four gray
tones available in the 6x6x6 color cube.
Signed-off-by: Andy Koppe <andy.koppe@gmail.com>
Xfce Terminal sets TERM to xterm-256color even though it does not have
all the capabilities that an xterm has, leading it to misinterpret some
escape sequence and produce a spurious 0x24C key code.
Intercept this mistaken key code and tell the user what is wrong.
This mitigates https://savannah.gnu.org/bugs/?64578.
Reported-by: Lawrence R. Steeger
An ambiguous option like --back or --word would cause nano to spew
the entire help text. It should do the latter only when the user
explicitly requests it.
The short option '-?' was removed nine years ago in commit 43019189,
then restored six years later in 5bd92d4c, and then removed again two
months later in 743100fe due to getopt() returning '?' for options
that aren't recognized, preventing the use of '-?' as a valid option.
However, getopt() provides a way to check for unrecognized options
via the 'optopt' variable, which gets set only for invalid options.
Signed-off-by: Mateusz Kazimierczuk <mataha+savannah@protonmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
When the directory that the user is browsing in is deleted by another
process at the moment that nano is building the list of file names,
this can result in an empty list, which some items in the main loop
in browse() cannot handle. Prevent this mishandling by not entering
the loop when the list is empty.
This fixes https://savannah.gnu.org/bugs/?64465.
Reported-by: Jerry Meng <jerrytstng@gmail.com>
Speller, linter, formatter, and execute-a-command cannot be used in
restricted mode, but the relevant keys should report that the function
is *disabled*, not that the key is unbound.
This fixes https://savannah.gnu.org/bugs/?64226.
Problem existed since version 3.2, since nano reads the nanorc files
also in restricted mode.
With some imagination, the lack of access could be inferred from the
other descriptions, but it's much better to be clear and explicit.
Also, separate two items that are unrelated and reshuffle them into
a neater order.
Triggered by https://savannah.gnu.org/bugs/?64181.
This suppression prevents the filename flashing by at the bottom
of the screen when switching between buffers.
This addresses https://savannah.gnu.org/bugs/?64019
Reported-by: Alan Cristhian Ruiz <alancristhian@protonmail.com>
Problem existed since version 6.0, since --zero was introduced.
I already added this for myself since I've been using this patch for a while
so I figured I'd include it. This simply makes it possible to colorize the
folded segments as the user desires. An option 'foldedcolor' is enabled for
the rcfile.
Signed-off-by: rexy712 <rexy712@protonmail.com>
In order to test the functionality, one actually has to be able to build it!
This patch adds an option to the configure script, builds 'folding.c', and
adds a shortcut to make folding possible. The shortcut here is set to 'M-['.
Signed-off-by: rexy712 <rexy712@protonmail.com>
Not everything is as simple as just UNFOLD_SEGMENT. These are the cases where
specific modifications were needed. Most of the actual heavy lifting was done
when modifying the functions 'update_line' and 'do_prev_word'.
Most of the changes here actually came down to 'get_row_from_edittop' or
changing from 'update_line' to 'update_line_at'.
Signed-off-by: rexy712 <rexy712@protonmail.com>
When adding folding lines, the lines drawn on screen are no longer
guaranteed to increment one by one. There could be a large skip when
handling folded segments. So instances where the codebase assumed
'openfile->current->lineno - edittop->lineno' would yield the position
on screen of the current line needed to be modified. Similar problems
existed in many places so a function 'get_row_from_edittop' handles
finding the current position of a line in relation to 'edittop'.
Signed-off-by: rexy712 <rexy712@protonmail.com>
The bracket search functions 'find_a_bracket' is very useful for searching for
region to fold when no selection is made. To make this possible, the function
needed to be modularized so it could be reused in a way not originally
intended.
The functions 'do_prev_word' and 'do_next_word' were interesting in that
sometimes it is desirable to get the corresponding word within a folded
segment and sometimes it was better to skip folded segments. So a boolean
parameter seemed like a good way to not duplicate functionality while
making the function work for both cases.
The 'update_line' function only worked in relation to edittop from the
given line's lineno. This obviously won't get the correct position if
there are folded lines. So I added a new function 'update_line_at' to
allow specifying where in the window to update when calling the function.
The original 'update_line' still exists to not modify existing code
utilizing it.
Signed-off-by: rexy712 <rexy712@protonmail.com>
Nano's existing functionality needs to mesh with the ability to
fold lines. The most common of these issues is needing to unfold
when a line is updated or the user accesses a line inside of a folded
segment. This patch handles all the places this can be done simply
with a 1 or 2 line modification.
Signed-off-by: rexy712 <rexy712@protonmail.com>
Adds in some preprocessor directives for easily adding in unfolding
support to existing functions that require it. Also adds in some
helper functions in 'folding.c' for common tasks which will need
performed. And of course add the 'folded' boolean to the linestruct
type so we know which lines are currently folded.
Signed-off-by: rexy712 <rexy712@protonmail.com>
Various tools will output filenames with line numbers in the format
<filename>:<line>:<column>. Support this format in addition to the
+<line>,<column> format when opening files.
Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The isxxxxx() functions expect their parameter to be either EOF or
a value in the unsigned char range. Passing a negative char value
could (in theory) result in unexpected behavior.
In view mode it should be impossible to modify any buffer, but...
when (through some bug) the user did succeed in modifying a buffer,
this should not lead to writing out this modified buffer to disk.
Had this safety stop been present earlier, it would have prevented
the second part of https://savannah.gnu.org/bugs/?63616.
A string bind can only contain bytes (chars), not keycodes (integers,
in nano upto 0x4FF). So, apart from an error code or a placeholder
command code, get_code_from_plantation() can only return a byte.
The function get_code_from_plantation() should return ERR only when
the string bind is fully exhausted. In the normal case, where some
bytes are still available, it should return the first of these bytes,
so that the {verbatim} function will work too.
This fixes https://savannah.gnu.org/bugs/?63702.
Bug existed since version 7.0, commit 958ec294,
since command cartouches were introduced.
This separation avoids the impression that we're thanking the mentioned
people for their use of nano (something they probably don't do).
(Also, remove two other blank lines -- effectively moving these two
lines further up, keeping the total amount of whitespace the same.)
That is: do not silently return from parse_one_include() when the
given file does not exist, *and* return the filename (or pattern)
itself when it matches nothing.
This fixes https://savannah.gnu.org/bugs/?63446.
Bug existed since version 4.0, commit d3f0d32e.
This prevents an unwanted message when nano
is compiled with -fsanitize=undefined.
This fixes https://savannah.gnu.org/bugs/?63447.
Problem existed since version 4.8, commit 343f97b3,
since the --rcfile option was added.
Make sure that there is only whitespace to the left of the cursor
before setting 'allblanks' to TRUE, because this latter value will
cause these characters to be eaten (as a special case, to avoid
creating lines that contain only blanks when both --autoindent
and --breaklonglines are on).
This fixes https://savannah.gnu.org/bugs/?63407.
Reported-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Bug existed since version 2.9.8, commit d00ab406.
Also, mention my email address in the colophon of the PDF,
to avoid the impression that Chris is the sole responsible.
And improve the general layout by adding three blank lines.
This places the cursor in a more predictable position.
This fixes https://savannah.gnu.org/bugs/?63223.
Issue existed since version 4.4, commit a9dd73fb,
since the +/string feature was introduced.
Not just for +/ (a search command without a string) should nano report
an "Empty search string", but also for +c/ or +r/ or similar.
This fixes https://savannah.gnu.org/bugs/?63222.
Bug existed since version 4.4, commit 2326bf69.
When the user interrupts an external command that hangs or takes too
long, nano should also kill the data-sending process (when present).
This fixes https://savannah.gnu.org/bugs/?63177.
Bug existed in this form since version 4.3, commit d946f38a,
but basically existed since version 3.0, commit ec339d3b.
When something goes wrong while executing an external command or while
piping text to it, report an error on the status bar and restore the
state of the buffer to what it was before the execution.
This fixes https://savannah.gnu.org/bugs/?63114.
Bug existed since version 2.9.8, since filtering text was introduced,
but basically existed since before version 2.0.0, since executing an
external command was introduced.
The execute_command() function — then called open_pipe() — was changed
to have a boolean return value in commit ce62e82a eighteen years ago,
but the value has never been used or checked.
The function line_from_number() can handle only line numbers that exist,
and will crash otherwise. (The lack of checks makes the function fast.)
This fixes https://savannah.gnu.org/bugs/?63120.
Bug existed since commit d1e28417 from five weeks ago.
Since commit c848ec3d from three years ago, nano has assumed that
'char' is always a single byte. So... elide the last occurrences
of sizeof(char), as they give a false impression of generality.
The function recode_LF_to_NUL() has to iterate over the string anyway
(to replace each \n with \0), so... instead of calling strlen() right
before it, just let recode_LF_to_NUL() return the length of the string.
(This is not speed-critical code, but... it saves one iteration over
the entire buffer contents whenever writing out a file.)
(There is no need to recode the NULs back to LFs because the sending of
the data happens in a separate process, which then simply disappears.)
This fixes https://savannah.gnu.org/bugs/?63106.
Bug existed since version 2.9.8, since filtering a buffer or a region
through an external command was introduced.
Not quitting would make nano hang for several seconds (which is very
annoying) and then die and save an emergency file (which is useless).
This fixes https://savannah.gnu.org/bugs/?63109.
Bug existed chiefly since version 5.9, commit 8d1a666d,
but basically existed since before version 2.0.0.
Analogous to commit 3922b531: instead of allocating and later freeing
a tiny fragment of memory for every character that the user enters (in
the edit window or at a prompt), reserve a small piece in the beginning
and retain it, and increase (but never decrease) its size as needed.
This addresses the second part of https://savannah.gnu.org/bugs/?63086.
In theory, the 'size_t' of 'capacity' could be just two bytes, which
means the keystroke buffer would overflow for pastes that are larger
than 32 kilobytes -- which are unlikely to occur, but... possible.
However, previously there was *no* overflow check when extending the
keystroke buffer (only when trying to put back a key code), so this
check is an improvement.
(On a regular machine, 'size_t' is at least four bytes, which means
the keystroke buffer would overflow at 2 gigabytes. Such a paste
is extremely unlikely to occur, so this check is really a no-op.)
Instead of allocating and freeing a tiny fragment of memory for every
keystroke, reserve a small piece in the beginning and then retain it,
because it will be needed again and again and again. Increase the size
when needed (for a large paste, probably), but don't bother to shrink
it afterward.
This addresses the first part of https://savannah.gnu.org/bugs/?63086.
Move the triggering of the line redraw out of the error path, and
into a better place: next to the normal clearing of the feedback.
This fixes https://savannah.gnu.org/bugs/?63053.
Bug existed since version 6.0, commit 6d828cf4.
As the magic line isn't really a line (it is not counted in the number
of lines read and written), and nothing is on it (not even a newline),
it doesn't make sense to allow any regex, like ^ or $, to match it.
This fixes https://savannah.gnu.org/bugs/?63034.
Indirectly-reported-by: Mike Scalora <mike@scalora.org>
Bug existed since before version 2.0.0.
Calling strstrwrapper() with the Backwards, Casesens, and Regex flags
unset is equivalent to calling mbstrcasestr(). So... do that instead
and quit saving and restoring the flags for each call of findfile().
This saving-and-restoring has been redundant since commit b0957254
from eight years ago.
The dots gave the impression that the next keystroke (hex digit) would
land somewhere on the dots. But this is not so -- the current digits
are instead shifted to the left and the new digit is added at the end.
Also adjust and improve several comments.
Also elide three calls of tolower(), using ORing with 0x20 instead,
as we're dealing with plain ASCII here.
Rename a variable too, away from a double abbreviation.
Instead of requiring always six digits, allow the user to indicate
with <Enter> or <Space> that the digits typed so far are the complete
Unicode code point (when prefixed with the missing number of zeroes).
This fulfills https://savannah.gnu.org/bugs/?63021.
Inspired-by: the <Ctrl+Shift+U> shortcut that some desktops have
This does not quite do what I would have liked (scroll only when needed)
when on a softwrapped line and jumping to a different chunk, but... it's
still better than needlessly centering the line.
(The user can still center the line, if that is what they want, by using
a period or a slash instead of a comma.)
This addresses https://savannah.gnu.org/bugs/?63008.
As double-quote-plus-space indicates the end of a regular expression
in a nanorc file, the inclusion of this combination *in* a regular
expression requires breaking the juxtaposition of the two, which
can be achieved by putting either of them between square brackets.
(It can also be achieved by preceding the space with a backslash,
which is shorter, but... the above method is more symmetrical.)
This addresses https://savannah.gnu.org/bugs/?62997.
Nobody will configure nano with --enable-tiny --enable-extra, but *if*
someone does, the title bar should be absent during the crawl.
Also, swap two messages, so that their order in the POT file will be
more sensible -- a closing brace comes after the function name.
"Cannot map name %s to <thing>..." was unnecessarily verbose and vague.
I have kept these strings unchanged all these years because I didn't
want to invalidate the existing translations. But now it's time to
harmonize things and simply say "Unknown <thing>: %s" for an invalid
function name, menu name, option name, and syntax name.
("No such <thing>: %s" is nice and snappy, but its translations often
are clumsy and longer and unclear.)
(It is a harmless leak, but LeakSanitizer is loud when it complains.)
After having determined that there is a menu name, first check that
it is valid, before processing the string or the function name.
This fixes https://savannah.gnu.org/bugs/?62991.
Problem existed since version 2.9.4, since string binds were introduced.
This makes more sense than letting the formatter and the linter depend
on ENABLE_COLOR (which maybe should have been named ENABLE_SYNTAX).
This fulfills https://savannah.gnu.org/bugs/?50080.
Six years ago, commit a878f5f1 introduced a call of regenerate_screen()
directly in the input routine, which made the call of refresh_func() in
the prompt routine redundant -- except when in the file browser.
Since version 6.0, with option --zero, the edit window can cover
the whole terminal. Make use of this also for the credits crawl.
Also, shorten and quicken the crawl a bit, and make it start always
on the bottom row, instead of (for mysterious reasons) one row higher
when the terminal has an odd number of rows.
Furthermore, don't put back the key the user typed to stop the crawl.
Instead of starting always from the top of the buffer, start at the
current line, as it is quite likely to be near the target line.
(Since the previous commit we're assuming that openfile->current is
always valid, so we might as well make use of this assumption.)
Also, rename a parameter to make its meaning more explicit.
After undoing an <Enter> or redoing a line join, it is likely that the
"eaten" and freed line was the current line. In fact, goto_line_posx()
should not refer to it any more, but... accommodate for this and just
set openfile->current to a valid value before calling goto_line_posx().
This fixes https://savannah.gnu.org/bugs/?62952.
Bug existed since version 6.3, commit eea3e1f0.
Checking for the literal ^N, ^Q, and ^Y before checking for do_toggle
and full_refresh made it impossible to rebind any of those keystrokes
to these two functions. (Not that anyone would want this, but...)
Problem existed since version 4.3, commits 341601e1 and 82aea04c.
This allows specifying bindable functions in a string bind by name
instead of by the literal control code or escape sequence to which
they are bound, which makes for a much more readable string bind,
and also allows specifying functions that are not bound to any key.
The opening brace, {, is made into a special symbol inside a string
bind, and each literal occurrence there needs to be escaped as {{}.
This fulfills https://savannah.gnu.org/bugs/?61692.
Requested-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Original-idea-by: Brand Huntsman <alpha@qzx.com>
https://lists.gnu.org/archive/html/nano-devel/2018-02/msg00006.html
This makes that the three options that change the default layout
of the interface (--stateflags, --minibar, --zero) come last.
Also, sort the option letters into a consistent order in the code.
(That 'also_the_last' now gets reset to FALSE whenever the cursor moves
to a different line is fine -- it is redundant when the mark is off, but
it does no harm.)
It was silly to check again specifically for <Del> and <Bsp> after
any possible keystroke had been handled. It was an anomaly.
This makes the tail of do_deletion() similar to the tail of inject().
(That sometimes the current line is redrawn twice is acceptable -- how
often does one type <Backspace> while having Shift-selected something?
Normally one wouldn't, because it would cancel the selection, so it's
fine to accept some inefficiency for this case.)
The checking for all functions that are marked as not-okay-for-view-mode
was excessive and unneeded. It had been inherited from commit d47d8cd4
from thirteen years ago, and was never verified for correctness.
This addresses the main part of https://savannah.gnu.org/bugs/?62903.
The linter has been marked as NOVIEW since it was introduced in 2.3.3.
But that was a mistake, as the tool does not change the buffer contents.
This addresses a minor part of https://savannah.gnu.org/bugs/?62903.
This is especially meant to avoid dereferences of 'shortcut' after its
linked function has been executed, because in an upcoming commit this
execution may have freed the shortcut's structure.
(For symmetry, make the same change also in do_statusbar_input(), even
though it is not needed there.)
This addresses one part of https://savannah.gnu.org/bugs/?62899.
The only menus that are accessible in view mode are WhereIs, Insert,
WhereIsFile, GoToDirectory, and Help. In the WhereIs menu, the only
keystroke that is not allowed in view mode (^R) is caught explicitly.
In the other four menus, all available shortcuts are permissible in
view mode, so... there is no need to check them at execution time.
(The ^R keystroke in the WhereIs menu is still shown in view mode
so as not to upset the pairing of the subsequent shortcuts.)
Since commit 63f2be7a from four years ago, view mode always sets
multibuffer mode, allowing ^R (Insert) to be invoked. But the
user is then not allowed to switch multibuffer mode off, so...
don't show the toggle.
When confirm_margin() first sets the margin needed for the requested
line numbers, also then it needs to keep 'focusing' TRUE. Only when
actually toggling --linenumbers ON (from a zero margin to something)
should focusing be suppressed, in order to obtain smooth scrolling
when the cursor is pushed off-screen.
This fixes https://savannah.gnu.org/bugs/?62885.
Bug existed since version 4.4, since the search-at-startup feature
was introduced.
In many keyboard layouts M-< and M-> are awkward to type (in a Spanish
layout, for example: Alt+Shift+AltGr+Z and Alt+Shift+AltGr+X when there
is no LSGT key), whereas M-, and M-. are simple two-key keystrokes in
most Latin-script layouts. So, show M-,/M-. before showing M-</M->.
Also, make a condition more precise, to not show M-Left and M-Right in
the tiny version, when those shortcuts are not understood.
Since version 6.0, Suspend is no longer bound by default, which meant
that it dropped out of the help lines, leaving the items after it in an
unpaired arrangement. Move the Suspend item and its intended partner
to near the end of the list, to reestablish pairing for several items.
This makes invoking the formatter cleaner, by giving feedback and *not*
leaving curses mode. Leaving curses mode had the small advantage that
any messages from the formatter would be on the terminal after closing
nano. But it had the disadvantage that invoking the formatter flashed
the screen.
This basically reverts commit 2b9f0619 from three years ago and then
solves the issue of intruding formatter messages in a different way.
This fulfills https://savannah.gnu.org/bugs/?62789.
Requested-by: Gert Cuykens <gert.cuykens@gmail.com>
Also, elide an unneeded condition: when not softwrapping, left_x will
be zero, which is always smaller than or equal to the indentation.
Furthermore, reshuffle a few lines, improve three comments, and adjust
one to mention the parameter that was added in the previous commit.
This adjusts the main softwrapping routine so that it remembers the
reached point in a line's text and the corresponding column. This
avoids having to scan the line from the beginning for each iterative
call, and thus saves a substantial amount of time when softwrapping
very long lines.
This mitigates https://savannah.gnu.org/bugs/?62442.
Reported-by: Devin Hussey <husseydevin@gmail.com>
Original-patch-by: Devin Hussey <husseydevin@gmail.com>
The double slash would derail the file browser, causing a crash.
This fixes https://savannah.gnu.org/bugs/?62760.
Reported-by: Frank Wolff
Bug existed since version 6.3, commit fdd946c0.
It has been more than three years since version 4.0 was released,
the moment that the defaults for line wrapping, smooth scrolling,
and the size of the editing window were changed.
Keep the note in the texi manual, though, as it is less in the way,
and the manual generally contains more info than the man pages.
Due to CVE-2022-24765, Git refuses to operate on local repositories if
it runs as a different user from its owner. Since version 2.35.2:
$ sudo git describe --tags
fatal: unsafe repository ('/home/lh_mouse/GitHub/nano-win' is owned by someone else)
To add an exception for this directory, call:
git config --global --add safe.directory /home/lh_mouse/GitHub/nano-win
Conventionally, a user, who wishes to build and install nano from Git,
does this:
$ ./configure
$ make
$ sudo make install
The first `make` command builds the program as the current user.
The `make install` then installs the built files.
However, we have a recipe for 'revision.h' that is always executed,
even in the case of `make install`. As here it is run as root, Git
actually fails and produces an empty string. This causes `make install`
to rebuild nano.o and winio.o and results in an empty version string in
the upper left corner.
The solution is simple: First we attempt a dryrun of `git describe`.
If it fails, 'revision.h', which should have been updated by the first
`make` command, will be left intact.
Reference: https://nvd.nist.gov/vuln/detail/CVE-2022-24765
Signed-off-by: LIU Hao <lh_mouse@126.com>
When one wants an Undo to restore the cursor to where it was before an
operation, one shouldn't fiddle with the position before it is stored
in the relevant undo item.
This fixes https://savannah.gnu.org/bugs/?62341.
Bug existed since version 4.9, commit 38af812a.
(This effectively reverts commit 38af812a from two years ago.)
For some reason, when copying something to the system clipboard
with 'xsel', it wants to see all output descriptors closed before
it will exit without requiring ^C.
This fixes https://savannah.gnu.org/bugs/?62276.
Reported-by: Shi Yanling <sylphenix@126.com>
Bug existed since version 2.9.8, since piping text through an
external command was introduced.
Instead of silently opening an empty buffer when the user tries to
open a file in the current but disappeared directory, give a clear
warning about the absence of this directory.
This improves the fix for https://savannah.gnu.org/bugs/?62244.
When the working directory has been deleted from under nano's feet,
get_full_path() would move up in the directory tree until getcwd()
would succeed. This meant that a filename that was specified on the
command line without any path (or with a relative path) would refer
to a different file than what the user intended. Not good.
So, stop changing directories in get_full_path(). Use the realpath()
function with NULL as second parameter instead -- it has been part of
the POSIX standard since 2008, time enough for operating systems to
have caught up.
In the bargain, this saves seventy lines of complicated logic.
This fixes https://savannah.gnu.org/bugs/?62244.
Bug existed since version 2.0.0, commit 85e35e67.
Use lightgrey for the prolog tags, as they normally are unimportant
boiler-plate stuff. Comments are likely to be more relevant.
Any /> is part of the tag itself, not of the attributes.
Especially when softwrapping and when multiline regexes are involved,
colorizing takes roughly exponential time relative to the line length.
To avoid bogging down, stop colorizing a line beyond a certain point.
This mitigates https://savannah.gnu.org/bugs/?61799.
Reported-by: Devin Hussey <husseydevin@gmail.com>
Although an anchor at the top line is rather pointless, it shouldn't
get cleared when the user pipes just a part of the buffer through an
external command.
When the filter command makes just small, per-line changes, keeping the
cursor at the same line number allows the user to observe the effect of
the changes -- which is not possible when the cursor gets moved to the
end of the buffer.
This partially fulfills https://savannah.gnu.org/bugs/?57248.
The same line number may not be the same position in the text, but
it will be approximately -- and it is certainly better than leaving
the cursor at the end of the buffer.
This fulfills https://savannah.gnu.org/bugs/?61175.
When making a forward movement larger than a screenful, we cannot rely
on the multidata of the line before the new screen start to have been
set correctly by a previous screen drawing, so we need to recompute all
of the multidata, for the whole buffer, so that afterward we can freely
move around and draw the screen without having to do any backtracking.
Also when a piece of text larger than a screenful is pasted or inserted,
all the multidata needs to be recomputed.
This fixes https://savannah.gnu.org/bugs/?60041,
and fixes https://savannah.gnu.org/bugs/?62056.
First bug existed in this form since version 2.4.2, commit d49c267f
(but editing Python was incomparably slower in those days).
Second bug existed since version 5.6, commit 43d94692.
This does not waste time looking for an end match, which is especially
wasteful when there is none. Also, it makes the coloring behavior more
consistent: any start match will cause coloring of the subsequent text,
no matter whether the user is in the middle of the file or near the end.
As it's possible for the start regex to match what is actually the end
match of a multiline thing (see the Python triple quotes, for example),
make sure that such a detected start match is *not* an end match, just
to avoid a needless full-screen refresh.
By passing --disable-maintainer-mode to ./configure the user can disable
autoconf build rules that would cause configure to be rebuilt and rerun.
Kind-of-requested-by: Mike Frysinger <vapier@gentoo.org>
This makes nano conform to the https://no-color.org/ idea: suppressing
any color in the output (in the default setup) when NO_COLOR is set in
the environment.
Specifying a color for any interface element will, however, re-enable
also yellow for the spotlight and red for error messages.
This mitigates https://savannah.gnu.org/bugs/?36864.
Reported-by: Clarence Risher <sparr0@gmail.com>
Problem has existed since the beginning, as nano empties the existing
file before writing the current buffer contents into it.
Fix building with x86_64-w64-mingw32 to cross-compile native Windows
programs. Need to:
* add checks for missing functions
* don't use signals that are unavailable on the platform
* avoid useless non-Linux sys/ioctl.h include
* use putenv instead of setenv as the latter is unavailable
That is, take into account that the cutbuffer could be NULL
(when updating the undo item).
This fixes https://savannah.gnu.org/bugs/?62107.
Bug existed since version 4.9, commit b15c5a7e.
The 'endmatch.rm_eo' value is relative to the end of the start match,
so to find the end of the end match, one has to add 'startmatch.rm_eo'
plus 'endmatch.rm_eo' to the starting point of the line.
This addresses https://savannah.gnu.org/bugs/?62091.
Problem existed since version 5.6, commit 0596b875.
In version 2.2.0, pyflakes changed its output format,
from 'filename:line: text' to 'filename:line:column text'.
This fixes https://savannah.gnu.org/bugs/?62057.
Problem existed since version 2.9.0, commit 5dcf375f.
(That commit tried to compensate for an introductory message from gcc
that no longer seems to exist.)
The new name 'gauge' more clearly indicates that it is a distance
between two "columns", two "pillars", two "piles". Using 'longest'
was poor, because in fact it was set to 'widest + 10'.
(Also, change the type of 'piles' to an integer -- it will always
be smaller than COLS, and COLS is an integer.)
A newer compiler (gcc-10.3) said: browser.c:174:34: warning:
field width specifier '*' expects argument of type 'int'
It's fine for 'longest' to be an integer, as a filename in Unix is
at most 255 bytes long, which can occupy at most 510 columns (when
the name consists entirely of control codes), and that fits easily
within an 'int', which has at least fifteen bits, unsigned.
Well... in theory 'tabsize' could be set to an insanely high number,
and if a filename contains several tabs, this could cause 'longest'
to overflow. (Why doesn't the compiler warn about that?) If that
were to occur, and the filename with the tabs were the last in the
list, then 'longest' would get set to the minimum width: 15. That
would not be correct, but... nothing bad would happen.
This addresses https://savannah.gnu.org/bugs/?62014.
Reported-by: Mike Frysinger <vapier@gentoo.org>
This wipe suppression is meant to prevent the last row of the edit window
getting cleared when edit window and bottom window overlap, and this is
relevant only when the user is actually editing -- the file browser and
help viewer take care not to use this bottom row for content.
This fixes https://savannah.gnu.org/bugs/?62031.
Bug existed since version 6.0, commit be61aad9.
Problem existed since commit 3b657a26 from five days ago.
In addition, exclude pasting-at-the-prompt from the tiny version, as
it's hardly useful when one cannot copy a selected piece of text.
When re-entering curses mode, ncurses will pick up the new size of
the terminal and set the LINES and COLS variables appropriately.
(We don't ask the terminal for its size when nano starts up, so why
would we need to do it when the terminal is resized?)
Since version 2.8.7 the user can paste text at the prompt (with ^U),
but the ability to copy what is present at the prompt was overlooked.
For feedback, the cursor is moved to the start of the answer -- like
it moves to the start of the next line when in the edit buffer.
This addresses https://savannah.gnu.org/bugs/?61702.
Reported-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
In most cases, the cursor will be at the end of what the user typed
at the prompt (or retrieved from history), and ^K will work as it
always did, erasing the whole answer. But if the user has moved the
cursor to somewhere in the middle of the answer, a ^K will now erase
just the part after the cursor. A second ^K will erase the rest.
Inspired-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Because doing the spotlighting after those extra keycodes have been
handled will most likely spotlight the wrong piece of text. Also,
if those keycodes hadn't arrived early, the first of them would have
cancelled the spotlighting.
This fixes https://savannah.gnu.org/bugs/?61962.
Bug existed since version 5.8, commit 3f340836.
When a large piece of text was pasted into nano, then the old way of
repeatedly moving the buffered text one more position toward the head
of the keystroke buffer would waste a lot of time. With this change,
pasting the current NEWS file into a buffer goes down (on my machine)
from around 30 seconds to just 2.
This addresses https://savannah.gnu.org/bugs/?61822.
Reported-by: Radu Caragea <rcaragea@protonmail.com>
Problem existed in this form since version 1.3.6, commit 7483571f.
When the user exits with ^X and gets warned that the file on disk
has changed, then typing ^C at the question whether to continue
saving should not discard the buffer and exit, but should return
the user to the filename prompt.
This fixes https://savannah.gnu.org/bugs/?61883.
Reported-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Bug existed since version 2.9.0, commit 217cfbf3.
And don't mention <Tab> for the 'indent' function, as the keystroke
is equivalent to M-} only when lines are marked.
Reported-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
The value of 'consumed' may not exceed the given 'length'.
Bug existed since version 2.9.3, commit e739448c.
(Bug was found by studying Fedora crash reports. Thank you, Fedora!)
The file contained two syntaxes (each of them fairly large) that are
useful only for Gentoo users. I don't think the file should have been
distributed with nano ever, as the syntaxes are just a dead weight for
the users of all other distributions.
That is: colorize text after a blank-plus-hash as a comment when there
is at least one non-hexadecimal character among the first three.
This relaxes the demand that a trailing comment should have a blank
after the hash too, as implemented by commit 90946c5e two weeks ago.
Make types a bluish green, for more contrast with strings, so that the
latter can be made greener, for more contrast with the yellow keywords.
Make the main keywords bluer and less bright, and unbold and soften the
yellow ones. Soften the comments too.
Reference for case-insensitivity:
https://www.postgresql.org/docs/14/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS
Also, colorize comments more readably (on a dark background), and
schemas less yelling, and languages more distinct from keywords.
And add a few more keywords, like IS and NULL.
Also, combine some keywords that can only occur together.
And drop a few that are probably rare, like LARGE OBJECT.
Reference:
https://www.postgresql.org/docs/14/bookindex.html
And use a more readable color -- blue is too dark on a black base.
Regular expressions in SQL are not written between // or %r{},
strings are not written between <> or %Q{} or anything similar,
and comments do not start with # -- and officially not with //
either, but some dialects seem to allow it.
This fixes https://savannah.gnu.org/bugs/?61381.
Bug existed since version 2.4.2, since the SQL syntax was included.
The path after 'include' is not a regex and does not need to be quoted;
when it's unquoted, colorize it specially, instead of leaving it red.
The syntax name after 'extendsyntax' should be brightgreen, like after
'syntax', but it's better that the subsequent commands have their own
special color.
Saying "Unbound key" would imply that it could be bound in a nanorc.
This fixes https://savannah.gnu.org/bugs/?61574.
Bug existed in this form since version 2.6.0, commit e0c4f9c5.
Letting the dummy key KEY_FRESH do a full refresh in the tiny version
allows a 'fg' to properly resume after an external SIGSTOP.
(Reminder: the ungetch() is needed in the normal version to prevent
the eating of a keystroke: https://savannah.gnu.org/bugs/?48331.)
Achieve this by translating KEY_SUSPEND back to ^Z.
(Strictly speaking, this is incorrect, as the terminfo entry
might specify some other keystroke for 'kspd', but... meh.)
This fixes https://savannah.gnu.org/bugs/?61573.
Bug existed since before version 2.2.0, since keys became rebindable.
With --zero, any message that was there will get overwitten by the
text window anyway as result of the current operation. And with
--minibar, any message will get overwritten with the minibar.
This fixes https://savannah.gnu.org/bugs/?61539.
Bug existed since commit 03637030 from two weeks ago.
The unsetting should happen after the three possible early returns,
to avoid leaving the flag unset.
Also, don't bother to exclude the setting and unsetting from the
tiny version, to get rid of some cluttering conditionals.
Most terminal emulators support a palette of 216 indexed colors:
the 6x6x6 color cube pioneered by Xterm. But as an index gives
little indication about what kind of color it produces, allow the
user to specify the color with three hex digits instead, one for
the level of red, green, and blue each, in the format #rgb.
One hex digit allows for sixteen values, but as there are only
six levels available, only 0, 4, 8, a, c, and e are significant
-- other values get reduced to the nearest lower one.
This fulfills https://savannah.gnu.org/bugs/?56445.
Requested-by: Peter Liscovius, Erik Lundin, Owen Maresh, Dave Lemonby
Signed-off-by: Brad Town <brad@bradtown.com>
Only requested information (^C, M-D) and alerts stay onscreen until the
next keystroke, but less important messages are overwritten after 1.5
seconds (or 0.8 seconds with --quick). This makes the behavior more
consistent with dropping a message when there is a spotlighted match.
This fragment suppressed the cursor when it was on the bottom row of
the terminal and a message was displayed on the status bar. But since
commit a2a00577 from eight days ago, the cursor will be scrolled off
of the bottom row when there is a message.
Also, reshuffle one call and drop another: the cursor has been placed
fifteen lines earlier (either directly or in edit_refresh()).
(Important test case: toggling softwrap.)
For consistency of style, the number of lines read should only be shown
when inserting a file into the current buffer, not when reading it into
a new buffer.
This amends the fix for https://savannah.gnu.org/bugs/?61509.
Inserting another file is somewhat unusual -- it's better to give
feedback about it.
This fixes https://savannah.gnu.org/bugs/?61509.
Bug existed since version 5.5, since the minibar was introduced.
Things like "Cancelled" and "Undid addition" are not needed. They
are nice for discovery, but become distracting once you know nano.
This fixes https://savannah.gnu.org/bugs/?61508.
Bug existed since commit 03637030 from last week.
Also when adjusting the viewport, after the cursor has gone offscreen
(by toggling the help lines, for example), should the SHIM be applied.
This fixes https://savannah.gnu.org/bugs/?61503.
Bug existed since commit 03637030 from last week.
It's an editor -- the largest element should be the text to be edited,
not some part of the interface.
(It would be better if the edit window was always the largest element,
larger than or equal to all interface elements combined. But that is
something for another time.)
There is no need to prevent NO_HELP from being unset on terminals
with fewer than five rows, because the bottombars() routine already
automatically suppresses the help lines on such terminals.
This improves the fix for https://savannah.gnu.org/bugs/?61497.
(The problem with absent feedback is still there when the terminal
has just one row.)
This should make it slightly easier for translators when they compare
their PO file to nano's main help text.
Also, drop a die() -- a forgotten toggle name is not worth dying over.
When the syntax contains a 'tabgives' command, toggling the conversion
of tabs-to-spaces has no effect -- not for the current file. So, tell
the user that and don't change the flag.
This fixes https://savannah.gnu.org/bugs/?61496.
Bug existed since version 4.5, since 'tabgives' was introduced.
In UTF-8 locales, the ranges A-F and a-f include several accented
characters beyond "ABCDEF" and "abcdef", such as the Croat č and ć.
This fixes https://savannah.gnu.org/bugs/?61487.
Bug existed since the beginning of each of the syntaxes,
for the C syntax since version 1.3.6, commit 159bdfdc.
Messages like "Search Wrapped" and "This is the only occurrence"
do not need to be shown until the next keystroke. Dropping them
quickly gives a better fullscreen experience.
When <Tab> at a prompt shows a list of filenames, this list should
not "sit" on the prompt bar but float one row above it.
This addresses the third issue mentioned in commit 03637030.
If there is a status-bar message and the cursor happens to be on the
bottom row of the screen (in hidden-interface mode), then scroll the
viewport one row down, to keep the cursor in view.
This addresses the second issue mentioned in commit 03637030.
(The issue was rereported in https://savannah.gnu.org/bugs/?61464.)
This needlessly wipes the status bar when --constantshow is active,
but it already needlessly wiped it when --minibar is active, so...
It is not a performance issue. It was just a small optimization.
(Plus, with --zero, nano does a full edit_refresh() when in fact
only the bottom row needs to be redrawn, but there is no easy way
to do that when --softwrap is active, so...)
(Using --constantshow with --zero doesn't make sense, but the user
might want to have the --constantshow when they toggle --zero off.)
This fixes https://savannah.gnu.org/bugs/?61460.
Bug existed since version 5.0, commit d3954901, since in the normal
version ^T was repurposed to give direct access to the Execute menu.
The --noread option should apply only to the files listed on the
command line, but once nano has started, it should be possible to
insert other files into the current buffer or into a new buffer.
This fixes https://savannah.gnu.org/bugs/?61458.
Bug existed since version 2.3.3, since --noread was introduced.
Before version 4.3, commit 3eab405e, nano would write a help text to
a temporary file and then read this file into a buffer. The NOREAD
flag interfered with the latter, so needed to be reset for showing
help. But since the mentioned commit nano writes a help text directly
into a buffer and the unsetting of the NOREAD flag is superfluous.
The display code never references the LINE_NUMBERS flag -- the trigger
for displaying line numbers in front of the text is 'margin > 0'. So,
since commit 90bd25c1 that put help texts into a "normal" buffer, the
unsetting of the LINE_NUMBERS flag has been superfluous.
As a special case, and because it doesn't need any feedback on the
status bar nor other calls, add a special function and key binding
to allow the user to flip the LINE_NUMBERS flag also in a tiny nano.
This fixes https://savannah.gnu.org/bugs/?61441.
Reported-by: Hannu Nyman <hannu.nyman@iki.fi>
When the terminal has just one row, there is no room to constantly show
the position of the cursor, so do not allow the user to switch it on.
This fixes https://savannah.gnu.org/bugs/?61445.
Bug existed since version 5.8, commit 36ffb5f0.
With --zero or 'set zero', nano will hide the title bar or the minibar
(whichever is active) and will use all rows of the terminal for showing
the text of the buffer. Only when there is an important message will
it be shown on the bottom row -- until the next keystroke.
This feature can be toggled with M-Z.
The feedback at startup ("Read nnn lines") is suppressed with --zero,
because it disrupts the fullscreen experience (and is hardly useful).
The "Reading..." message then needs to be suppressed too, otherwise
it creates an annoying little flash.
There are still some issues that need to be addressed:
* In the browser, when the highlighted item is on the bottom row, it
will get obscured by the prompt bar or the "Search Wrapped" message.
* In the edit window, when the search occurrence is on the bottom row,
it can get obscured by the "This is the only occurrence" message.
* When tabbing at a prompt shows possible completions, they are shown
a row too low.
The text to be justified has been excised from the buffer and is now
in the cutbuffer, so we cannot compare any of its lines to 'filetop'.
This fixes https://savannah.gnu.org/bugs/?61438.
Bug existed since version 4.0, commit 14c08589.
Also, drop the unneeded and mistaken 'end=' in the first regex, as
a coloring rule with just end="something" is not valid. And drop
the requirement for having trailing whitespace or nothing at all,
as it does not constitute a useful restriction.
Also, fold two regexes together, for economy.
The coloring rule for 'unbind' still checked for the old 'extcmd' and
'externalcmd' menu names. And not coloring binds and unbinds as valid
when followed by something other than a comment was overrestrictive,
because the bind or unbind command would work just fine.
(Nano silently allows trailing garbage on any line without a regex.)
Also, take the opportunity to order the menu names in the bind and
unbind rules in the same way.
This fixes https://savannah.gnu.org/bugs/?61419,
and fixes https://savannah.gnu.org/bugs/?61420.
First bug existed since version 5.0, commit d9106abf.
Second bug existed since version 2.3.3, commit 9c11ba93.
In the beginning, the goal for nano was to be a drop-in replacement for
Pico. Pico did not know a Suspend command, so the ^Z keystroke needed
to be conditionalized on an option (-z or --suspend or the toggle M-Z),
just like the ^S and ^Q keystrokes (for stopping and resuming terminal
output) were conditionalized on --preserve.
But nano has abandoned full Pico compatibility since version 4.0. It
is time to unconditionalize ^Z as well. This should not be a problem:
Debian and Ubuntu have had 'set suspend' in their /etc/nanorc for years,
so a considerable portion of nano users have had ^Z enabled by default
for a long time, and no one seems to have complained.
If the keystroke bothers some user, they can unbind it in their nanorc.
They will still be able to suspend nano through the Execute menu: ^T^Z.
This addresses https://savannah.gnu.org/bugs/?61372.
The spotlighting should only be dropped when in the main menu, like in
the code thirty lines up, where 'timed' became TRUE only for MMAIN.
This fixes https://savannah.gnu.org/bugs/?61398.
Bug existed since version 5.8, commit 3f340836.
Normally, returning to the main loop will set 'focusing' back to TRUE,
but the replacement loop doesn't return until replacing is finished.
This fixes https://savannah.gnu.org/bugs/?61397.
Bug existed since version 5.0, commit d8249917.
When --breaklonglines is in effect and the user pasted just a few words
(anything without a linebreak), then act as if this short text had been
typed by the user and hard-wrap the line when it became overlong.
This fulfills https://savannah.gnu.org/bugs/?61353.
When --wordbounds (-W) is active, nano considers punctuation as
word-forming characters and will thus count words the same way
as 'wc -w' does. This is how nano counted words until now.
But when --wordbounds is not active (the default), only letters
and digits will be considered word-forming and thus lone groups
of lines and dashes and other punctuation will not be counted
as words, which is more like how a human would count words.
This addresses https://savannah.gnu.org/bugs/?61367.
(It would be much better if the build rules automatically included
any *.nanorc files in the syntax/ directory into the tarball...)
This fixes https://savannah.gnu.org/bugs/?61391.
Reported-by: John Prokos <jprokos@gmail.com>
Bug existed since version 5.9, commit c2790a8a.
Also, trim some whitespace and group one rule better.
Also, fix a stray closing parenthesis in the JSON syntax,
and add the missing slash to the possible escaped characters.
(Reference: https://www.json.org/json-en.html.)
Also, improve the ending of multiline strings in the Rust syntax.
A backslash should not be allowed inside a quoted string unless
it is used to escape another character.
This fixes https://savannah.gnu.org/bugs/?61389.
Bug existed since each of these syntaxes was introduced.
(Awk and Fortran do not know include files with names between
angled brackets, so those regexes are dropped in the bargain.)
Quoted strings cannot start within another quoted string and end after
that other string has ended. Therefore single-quoted and double-quoted
strings should (as much as possible) be colorized by a single rule, so
that overlapping colorations are avoided.
(This also fixes a double typo in the PHP syntax (\. --> \\.) that has
been there since the PHP syntax was added in 2008, commit 90ee8ee4.)
This fixes https://savannah.gnu.org/bugs/?61387.
Bug existed since each of these syntaxes was introduced,
the oldest ones around 2006, a few others around 2015.
The one that got it right was the Lua syntax from 2011.
The "\.?" part was pointless. It says that the string "nanorc"
*might* be preceded with a period. Sure, but if the period is
absent, then anything else may be there too, so the optional
period gives zero restriction.
The restriction should be: either the filename has the extension
".nanorc" OR the full filename is "nanorc". So the "nanorc" part
must be preceded by either a period or a slash.
(However, in the times of commits 3dc0e23e and dc9c40a5, fifteen
and eighteen years ago, it was still the user-provided filename
that was matched against the regex, not the full-path filename.
The latter method arrived in commit ec8d51be, six years ago.)
Strings may not contain a double quote unless it is escaped.
Reference:
https://doc.rust-lang.org/reference/tokens.html#string-literals
(This will still not colorize multi-line strings with an unescaped
newline, will still colorize "this\" as if it were a valid string,
and will still miscolor things when there is another string after
the closing quote of a two-line string. But those things can't
be helped -- line-based regexes cannot emulate a full parser.)
This fixes https://savannah.gnu.org/bugs/?61361.
Reported-by: Elias Jonsson <e@ejon.eu>
Bug existed since version 2.6.1, since the Rust syntax was introduced.
Or rather, move the chapter about command-line options to between
the chapters on file browser and feature toggles. Also, rename the
chapter about the built-in help, and move the section about screen
layout to be the first in the editor-basics chapter.
Within a bracket expression, the backslash is not special,
so it does not need to be escaped.
The double backslashes within brackets were found with:
grep -o '\[[^][]*\\\\[^][]*\]' syntax{,/extra}/*rc
Also, incorporate the square brackets into some bracket expressions
by listing the closing bracket first, saving a separate regex for
those two brackets.
Texinfo-6.8 (that was used to build the docs of nano-5.9) changed
the way the @contents command is processed for HTML output, with as
result a detailed table of contents at the start of the HTML page.
That is ugly and too much detail. To avoid that, produce a table
of contents only when generating output meant for printing.
This fixes https://savannah.gnu.org/bugs/?61344.
Bug existed since version 5.9.
What @* does is guesswork when you don't use Texinfo regularly.
That the "sp" in the @sp command refers to vertical space is not
very clear either, but the command is used on nearby lines too,
so better use it more.
Also, improve two wordings and fix a four-year old typo.
An @command must either start at the beginning of the line and be
followed by whitespace or EOL, or it must be followed by a brace.
Colorizing just any "@text" string colored too much.
Also, allow an @} and another @command{} within a pair of braces,
colorize only the valid @-commands with uppercase in their names,
unbold enclosed command arguments, colorize the directory entries
for the manual, and properly colorize also the comments that use
the full @comment command.
Reference:
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Command-List.html
Testing was done with:
info texinfo @-C "Command List" --output=list
sed -i -e "s/^'//" -e "s/'$//" list
nano list -Ytexinfo
In olden times, each help text started with a title line in the text
window followed by a blank line. But since version 2.8.2, since the
help texts have become almost regular buffers (and thus searchable),
the title of the help text is in the title bar, and since version 4.0,
since --morespace became the default, the text will start immediately
below it. But a title line immediately followed by text, without a
blank line between them, does not look nice. So, add such a blank
line back when not using --emptyline (and also when using --minibar,
because the top of the terminal window is like a title bar).
When the history file has been created by nano, it will not contain
any duplicate search or replace strings, nor duplicate commands, so
checking for such a duplicate for each read item was a waste of time.
And if the user edited the history file and created duplicates, who
are we to filter them out? They will not cause the history mechanism
to malfunction; they just take a little extra memory.
(Aaah, being able to define a keyboard macro
came in very handy when making this edit.)
This fixes https://savannah.gnu.org/bugs/?61331.
Bug existed since before version 2.2.0.
If all is programmed well, then the functions 'get_older_item' and
'get_newer_item' will only occur when a history list is passed to
acquire_an_answer(). But let's keep it certain we don't dereference
a NULL pointer.
When the user immediately cancels a search (^W^C), then nothing in
the history stack has changed, so then there is no need to reset the
history pointer to the bottom.
This slightly improves the fix for https://savannah.gnu.org/bugs/?61316.
This also gets rid of an assignment in an 'if' clause (twice),
elides a local variable, and makes it clearer that a pointer
gets moved to the previous or next item (instead of hiding it
as a side effect of the function call).
Whenever invoking a search prompt, calling up historical search items
should start with the newest item.
This fixes https://savannah.gnu.org/bugs/?61316.
Bug existed since version 2.8.2, since help texts became searchable.
When the answer at the prompt was clear before the user went up into
the history list, the answer should be cleared again when the user
comes back down to the present.
This fixes https://savannah.gnu.org/bugs/?61308.
Bug existed since before version 2.2.0.
For consistency, these five names ought to start with "flip_", but
then the bindable functions would need to be renamed too, and that
would be annoying for the user, *and* it would create too many names
that start with "flip" -- it wouldn't be distinctive any more.
When the current filename is equal to the filename of the buffer,
then clear the filename, because the chances that the user wants
to append or prepend a file to itself are practically nil.
This fulfills https://savannah.gnu.org/bugs/?61243.
The keystrokes are not listed, but should work like
they do in a normal, editable buffer.
This fixes https://savannah.gnu.org/bugs/?61274.
Bug existed since version 4.0, commit bc98dbca.
The functions to_first_file() and to_last_file() can get called from
do_statusbar_input(), which is called indirectly from do_prompt(),
and are expected to make the corresponding adjustment.
This fixes https://savannah.gnu.org/bugs/?61273.
Bug existed since version 5.0, commit 07c1ac90.
Some Yaml files use path names and sometimes version numbers as keys,
even though / and . are not officially in the character set allowed
for key names (just like underscore is not), as far as I understand.
Also, do not colorize any backslash escapes as invalid
because some of them occur sometimes in value strings.
Also, colorize only the valid double-exclamation tags.
This avoids an unused and misleading assignment that might make
someone think the incremented variable will be used again.
Signed-off-by: Hussam al-Homsi <sawuare@gmail.com>
Perl keys can contain a double colon. And unspaced colons occur
quite regularly in values (URLs, IPv6 addresses, and the like)
and should not be colored as if they were an error.
The calls of write_file() in do_spell() and do_formatter() write out
a temporary file -- such a file does not have an 'openfile' record,
so setting 'annotate' to TRUE was pointless. Using the correct value
for this parameter allows dropping two conditions in write_file().
And when 'exiting' is TRUE and --save-on-exit is in effect, it is
slightly wasteful to stat() the written file and store the info in
its 'openfile' record as the buffer will be closed directly after.
So, now the only place where 'annotate' is TRUE is when writing out
the full buffer to a normally named file.
First, we don't want the writing of an emergency file to be interrupted
by the user. But more important: the routine for restoring the handler
also disables SIGINT, which would leave the terminal with a non-working
Ctrl+C.
Saving an emergency file calls write_file() in a unique manner: with
thefile == NULL, fullbuffer == FALSE (even though the entire buffer
will be saved, of course) and tmp == TRUE (even though it is not a
temporary file, as it will persist after nano exits). But in fact
we want the handler for Ctrl+C installed only for normal files, not
for temporary files and not for emergency files -- the user should
not be able to interrupt the writing of those.
This fixes https://savannah.gnu.org/bugs/?61237.
Bug existed since version 4.3, commit 8550c6bd.
Trying to prepend would hang nano until some other process writes
something to the fifo.
This fixes https://savannah.gnu.org/bugs/?61236.
Bug existed since before version 2.2.4.
Curses cannot function if not informed via TERM which type of terminal
is being used. As many terminals are mostly compatible with a VT220,
falling back to "vt220" when TERM is unset has a good chance of giving
the user a usable nano, instead of simply failing.
(Falling back to "vt100" is not good as it contains padding delays.)
This partially addresses https://bugs.debian.org/991982.
In the terminal font that I use nowadays (that deals well with
combining characters), the normal diamond exceeded the boundaries
of a single cell and thus partly covered the first character of
the relevant line.
When a segment of text is extracted, copy any anchors that it has
into the cutbuffer, so that they get saved in the undo item, so that
an undo will put these anchors back on the lines where they were,
instead of leaving an inherited anchor at the top of the segment.
And when text is pasted, clear any anchors in it, so that they will
not travel nor multiply.
This fixes https://savannah.gnu.org/bugs/?61162.
Bug existed since version 5.0, since anchors were introduced.
On most terminals "bold" also makes the relevant text lighter (or just
makes it lighter, like on a Linux console). Only some terminals allow
the user to switch this coupling of bold to light off.
Suggested-by: Hussam al-Homsi <sawuare@gmail.com>
It should be "bold,white,red" instead of "brightwhite,red"
because "bright" is deprecated and not documented.
Signed-off-by: Hussam al-Homsi <sawuare@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
That is: pause a little to jolt the user, and then leave the message
on the status bar.
This fixes https://savannah.gnu.org/bugs/?61147.
Bug existed since version 4.8, commit 416386ed.
This fixes https://savannah.gnu.org/bugs/?61146
Bug existed since version 2.3.2, since --locking was introduced,
and continued to exist since version 4.8 despite commit 497f126b
claiming to have fixed it.
These files haven't been updated in more than fifteen years and their
number of translated strings has dropped to below twenty percent.
Also, prevent them from coming back when next syncing with the TP.
The documentation (https://www.haiku-os.org/docs/api/libroot.html)
says that BSD extensions are enabled by default, but somehow this
does not seem to be the case on my system. With _DEFAULT_SOURCE
defined, though, src/files.c now compiles fine.
When safe_tempfile() returns a valid filename, it should also
return a valid open stream.
This fixes https://savannah.gnu.org/bugs/?61064.
Bug existed since version 1.3.8, commit 5e068c60.
Opening a file whose name starts with a plus is not a problem at all.
Instead describe how to get the Alt+Up keystroke to scroll on a Linux
console (on Debian and friends).
This addresses https://savannah.gnu.org/bugs/?57294.
Any error message will already have been written to the terminal by
statusline(). Also, "Buffer not written to" looked too much like
"Buffer written to"; one had to look closely to see the difference.
Having a local variable that gets assigned to just once looks rather
poor. To me it makes more sense to have two separate exit points: one
for failure somewhere in the middle, and one for success at the end.
This way it is completely clear which value gets returned when.
And make the wording for the --historylog option similar.
This fixes https://savannah.gnu.org/bugs/?60868.
Bug existed since version 2.3.0, commit 8e2a9307, since the
saving and restoring of the cursor position was introduced.
When something that is called from die() calls die() again,
there is nothing we can do any more but give up.
This would have prevented the spiralling as
seen in https://savannah.gnu.org/bugs/?60853.
This mitigates a problem seen sometimes among the Red Hat crash reports:
somehow wgetch() keeps returning ERR, as if it were in nodelay mode.
(I've seen this happen once after nano came out of suspension.)
Using a much larger error-count value gives the user a few seconds
to type something and hopefully get out of the error condition.
Removals:
- All eblits were dropped from Gentoo years ago.
- HDEPEND was never fully approved, superseded by BDEPEND.
- Keywords 'dohard' and 'dosed' have been banned since EAPI 4:
https://projects.gentoo.org/pms/5/pms.html#x1-130001r8
- Several arches are dead. For the currently supported list:
https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/arch.list
Additions:
- Two eapply functions replace the epatch functions, but epatch
is still supported until EAPI 6 is banned.
- Modern build systems (ninja and qmake5) have new functions.
- EAPI 7 added more builtins: dostrip, get_libdir, ver_*
- Highlight the cross-compiler boolean function. (There are too
many toolchain functions to add them all, but this one is very
common and has a long name, so highlighting it is useful for
catching typos early.)
The EAPI documentation:
https://projects.gentoo.org/pms/8/pms.html#x1-590007
An extensive write-up on EAPI 7:
https://mgorny.pl/articles/the-ultimate-guide-to-eapi-7.html
Signed-off-by: David Michael <fedora.dm0@gmail.com>
Add IDEPEND from EAPI 8, and also add more EAPI 7 roots so that all
of ROOT, EROOT, SYSROOT, ESYSROOT, and BROOT are supported.
Signed-off-by: David Michael <fedora.dm0@gmail.com>
In Dejavu Sans Mono the old pointing triangles had a decent size,
but in Noto Mono and in Ubuntu Mono (fonts that handle combining
diacritics better) those triangles were massive, visually taking
up more than a single cell, overlapping the closing parenthesis
when they are displayed in the second column. Not nice.
The new pointing small triangles look good in the Noto and Ubuntu
fonts, but are real tiny in Dejavu. :| Oh well, one can't have
everything.
(Other triangles are not an option, because they don't degrade to
actual arrows when on a Linux console.)
When the spotlighting needs to be cancelled, there is no need to do a
full refresh of the edit window -- redrawing just the relevant line is
enough. (And when there is just one row, it is enough too.)
Also, add the normal CUA bindings for Undo (^Z) and Redo (^Y),
and drop the M-X thinko.
With these more "usual" alternative bindings, ^X will now do a Cut
(putting the cut text into the cutbuffer) only when in the main menu
-- in the other places it did not put anything into the cutbuffer,
so it's better to have only the default ^K ("kill") for that.
Suspension is now accessible with ^E^Z, and the Speller with ^E^S.
This fixes https://savannah.gnu.org/bugs/?60766.
Bug existed since version 3.2, commit 33d67d5c,
since the more usual example bindings were introduced.
We want to reduce the size of the answer by one byte,
not keep the full answer (plus terminating NUL).
This fixes https://savannah.gnu.org/bugs/?60764.
Bug existed since version 2.9.8, commit f304b9ae,
since piping text to an external command was introduced.
When it is not specified, it defaults to the value for 'titlecolor'.
When not using --minibar, I want the title bar to be blue (as that is
how I've always had it), but with --minibar, I want this mini bar to
be grey, as otherwise it reminds me too much of the prompt bar.
Also, colorize 'set minicolor' as valid in a nanorc file.
Even though I know that spotlighted text is not selected, I still
regularly think for a fleeting instant that the spotlighted text
can be cut with a ^K. Mitigate this by dropping the spotlighting
after 1.5 seconds (or 0.8 seconds when using --quick).
This can be useful when wanting to search for the other occurrences
of some (long) string in the buffer: select, M-6, ^W, ^U, <Enter>.
Signed-off-by: Hussam al-Homsi <sawuare@gmail.com>
Nano already opens the relevant file (when needed) and puts the cursor
at the relevant spot -- including this information in the message shown
on the bottom bar is just clutter and makes the message harder to read.
Instead of quoting M- as 'M-', some translations use «M-» (Catalan),
(M-) (Croat), "M-" (Italian), „M-” (Romanian), or „М-“ (Serbian).
Those occurrences of M- nor its quotation marks should be colored.
Achieve this by excluding those quotation marks from the M- regex,
and then colorizing M-) and M-" only when at start of line (first
column of shortcuts) or when between parentheses (second column).
The die() has been there for more than a year and no one reported a
problem. And anyway, indenting does not create more than one group
-- this check was just to be certain.
Only the basic colors (like red, blue and yellow) can take the prefix
"light" or "bright", not the extra colors (like pink, lagoon and lime).
This fixes https://savannah.gnu.org/bugs/?60674.
Bug existed since version 5.0, since the extra colors were introduced.
Because "lightnormal" sounds strange, and can have unexpected effects.
This fixes https://savannah.gnu.org/bugs/?60668.
Bug existed since version 2.9.5, since the name "normal" was introduced.
When using +/ or +?, any minor feedback should be cleared,
to not distract from the highligted search result.
This fixes https://savannah.gnu.org/bugs/?60669.
Bug existed since version 5.5, commit b86f7868,
since the manner of grading status-bar messages changed.
After a "+" only c, r, C, and R are valid characters,
and only when immediately followed by / or ?.
This fixes https://savannah.gnu.org/bugs/?60667.
Bug existed since version 4.4, commit 2326bf6,
since searching at startup with +/ or +? was introduced.
The "^_" has always been poorly legible (the underscore melting into
the bottom of the terminal) and difficult to type (Shift+Ctrl+minus).
The "^/" is both more readable and easier to type.
In terminal emulators, "^/" is shown, but on a Linux console "^-",
as ^/ does a backspace in the default console key mapping.
Also, allow using "^-" when rebinding ^_ in a nanorc file.
This addresses https://savannah.gnu.org/bugs/?57393.
Simply adding the number of bytes in the quoting part is not entirely
correct, but... currently the indenting and commenting routines also
assume that the whitespace and commenting characters that are added or
removed are single-byte characters... It will require another patch
to make this all fully correct, but for the default configuration
(and probably most other cases) the current fix will work fine.
This fixes https://savannah.gnu.org/bugs/?60605.
Bug existed since version 4.4, commit 8fce33af from two years ago,
since this automatic copying of the quoting part was introduced.
This fixes https://savannah.gnu.org/bugs/?60596.
Bug existed since version 4.4, commit 8fce33af from two years ago,
since this automatic copying of the quoting part was introduced.
When on a one-row terminal a message gets automatically "dropped"
after a few moments, the subsequent waiting for a keystroke should
not think that there is still a message on the status bar.
This fixes https://savannah.gnu.org/bugs/?60591.
Bug existed since commit 8d974cd2 from two days ago.
When there is just one row and there is a message, it is not a good idea
to draw the contents of the buffer as it would overwrite the message.
This fixes https://savannah.gnu.org/bugs/?60582.
Bug existed since version 2.7.0, since nano allows very flat terminals,
and was made worse by commit 2cf28f9d from yesterday.
Redraw the content of the edit window (for the undone final completion)
before pushing out the "No further matches" message, so that the latter
will not get overwritten by the buffer content -- in case the terminal
has just one row.
This fixes https://savannah.gnu.org/bugs/?60581.
Bug existed since commit 2cf28f9d from yesterday.
Only important error messages (ALERT) and information that the user
requested (^C, M-D) should stay put until the next keystroke. Other
messages should be overwritten by the text of the buffer after just
a few moments, to make a one-row terminal slightly more friendly.
This addresses https://savannah.gnu.org/bugs/?60570.
When showing a message on the status bar, the cursor should be off.
This fixes https://savannah.gnu.org/bugs/?60510.
Bug existed since version 2.7.0, since nano allows very flat terminals.
When there is just one row, the text to be edited needs to be shown
there, not some meta information about the cursor position.
This fixes https://savannah.gnu.org/bugs/?60563.
Bug existed since version 2.7.0, since nano allows very flat terminals.
Since version 5.6, commit 76742cc1, nano highlights the search match,
which means that the screen gets refreshed anyhow, so this specific
refresh for a one-row terminal is no longer needed.
This prevents read() from returning unexpectedly and causing a crash.
This fixes https://savannah.gnu.org/bugs/?60537.
Reported-by: Filips Romāns <frfilips@gmail.com>
Bug existed since version 2.4.2, since the handling of SIGWINCH changed.
That is: call edit_refresh() right away, to prevent the edit_refresh()
in the main loop from overwriting the status-bar message.
This fixes https://savannah.gnu.org/bugs/?60516.
Bug existed since version 2.7.2, commit f920e0d3.
That is: call edit_refresh() right away, to prevent the edit_refresh()
in the main loop from overwriting the status-bar message.
This fixes https://savannah.gnu.org/bugs/?60518.
Bug existed since version 5.6, commit 76742cc1.
When there is just one row, the user wants to see text on this row,
not a bar with some meta info.
This fixes https://savannah.gnu.org/bugs/?60508.
Bug existed since version 5.5, since the minibar was introduced
with commit d31cc373.
In many places a carriage return is not valid whitespace and should
thus not be colored as such. In some of these places a vertical tab
or form feed is maybe valid whitespace, but it would be ugly or even
wrong to color them because they are not part of the subsequent
comment or keyword.
This fixes https://savannah.gnu.org/bugs/?60456.
Changes:
1. There may be zero spaces between 'include' and '<...>'.
2. Blanks and '=' may occur inside '<...>' but '>' may not.
3. There must be at least one character inside '<...>'.
References:
Change 1:
C: www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf#subsection.6.10.2
C++: www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf#section.19.2
Changes 2 and 3:
C: www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf#subsection.6.4.7
C++: www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf#section.5.8
Signed-off-by: Hussam al-Homsi <sawuare@gmail.com>
Since commits b0209374 and 1c010d8e from a month ago, nano does not use
mblen() and mbtowc() any more, so there is no need to check for their
presence.
Instead, add a check for iswalpha(), which we do use.
This reduces startup time by seven percent (when using the standard set
of syntaxes) when opening just one file that doesn't match any syntax,
and more than ten percent when opening multiple files. It takes some
extra memory, but... not wasting CPU cycles is more important.
This addresses https://savannah.gnu.org/bugs/?56433.
When undoing several actions, it is possible for the line at the top
of the screen to be removed, leaving 'edittop' pointing to a structure
that has been freed. Soon after, 'edittop' is referenced to determine
whether the cursor is offscreen... Prevent this invalid reference by
stepping 'edittop' one line back in that special case. This changes
the normal centering behavior of Undo when the cursor goes offscreen,
but... so be it.
When a single node is deleted, it is always possible to step one line
back, because a buffer contains always at least one line (even though
maybe empty), so if the current line could be deleted, there must be
one before it (when at the top of the screen).
This fixes https://savannah.gnu.org/bugs/?60436.
Bug existed since version 2.3.3, commit 60815461,
since undoing does not always center the cursor.
Since two commits ago, the position of the indicator shows the position
of the viewport relative to the full buffer in terms of actual lines,
not of visual chunks (to avoid excessive computation). But the size of
the indicator stayed constant, as if it always covered as many lines as
the edit window has rows. But the latter will not be the case when
softwrapping occurs. Therefore, when softwrapping, compute how many
actual lines are visible in the viewport, and adjust the size of the
indicator accordingly.
Whenever softwrap was toggled on or line numbers were toggled on/off or
the window was resized, the extra rows per line needed to be recomputed
for ALL the lines. For large files with many long lines this was too
costly.
(This change causes the indicator to have an incorrect size when there
are many softwrapped chunks onscreen, but that will be addressed later.)
This fixes https://savannah.gnu.org/bugs/?60429.
Problem existed since version 5.0, since the indicator was introduced.
This makes the handling of plain ASCII a tiny bit slower, but it
affects only the users of --constantshow without --minibar, so...
All other uses of mbstrlen() and collect_char() are not in speed-
critical code paths.
Since the previous commit, mbwidth() is used only to determine whether
a character is either double width or zero width. There is no need to
return the actual width of the character; a simple yes or no is enough.
Transforming mbwidth() into is_doublewidth() also allows streamlining
it and is_zerowidth() a bit, so that they become slightly faster.
The number of bytes in the character were determined twice: first in
mbwidth() and then in char_length(). Do it just once, in mbtowide().
Also, avoid calling is_cntrl_char(), because it does unneeded checks
when we already know that the high bit is set.
This duplicates some code, but advance_over() is called a lot, so it
is important that it is as fast as possible.
This shouldn't slow down plain ASCII, as the extra checks (use_utf8
and *string < 0xA0) are done only for non-ASCII (apart from DEL).
The 'start_index' was in index in the given text, while 'index' is an
index in the displayable string. Having both of them using 'index' in
their name was somewhat confusing.
For a normal file (without overlong lines) the strlen() wasn't much
of a problem. But when there are very long lines, it wasted time
counting stuff that wouldn't be displayed on the current row anyway,
and reserved *far* too much memory for the displayable string.
Problem existed since commit cf0eed6c from five years ago that traded
a continuous comparison (of the used space with the reserved space)
against a one-time big reservation up front involving a strlen().
In retrospect that was not a good trade-off when softwrapping.
The extra check (charwidth == 0) is incurred only by characters that
have their high bit set, so the average file (with only ASCII) is not
affected by this -- it just loses an unneeded call of strlen().
In UTF-8 valid multibyte characters are at most four bytes long,
and now that we no longer make use of mblen() and mbtowc() from
the underlying system, we won't get five- or six-byte sequences
mistakenly reported as valid (by glibc). So it is always enough
to reserve space for just four bytes per character.
Calling wctomb() with NULL as the first parameter returns zero in a
UTF-8 locale, meaning that there is no state, so there is no point
in resetting it either.
The two calls of draw_row() are each immediately preceded by a call to
display_string(), which has already determined from which x position
and until which x position in the relevant line the current row will
be drawn -- doing this again in draw_row() is a waste of time. Even
though it is ugly, pass the two data points from one function to the
other via global variables.
For normal files (without overlong lines), this saves on average some
fifty calls of advance_over() per row. When softwrapping a file with
overlong lines, the savings for each softwrapped chunk are much higher.
(Well, it now checks that ^G is still the first shortcut that is bound
to 'do_help', but that is good enough: if the user did any rebinding,
they probably do not need any reminder about how to invoke 'Help'.)
This fixes https://savannah.gnu.org/bugs/?60315.
Reported-by: Robert Goulding <goulding.2@nd.edu>
This saves a function call, and the passing and checking of the
MAXCHARLEN parameter, and the checking whether wc is maybe NULL
(which for nano is never the case), and who knows what other
overheads mbtowc() has, and our workaround for glibc.
Code was written after looking at gnulib/lib/mbrtowc-impl-utf8.h.
Most implementations of mblen() do a call to mbtowc(), which is
a waste of time when all we want to know is the number of bytes
(and when we already know that we're using UTF-8 and that the
first byte is at least 0xC2).
(This also avoids burdening correct implementations with the
workaround that was needed only for glibc.)
Code was written after looking at gnulib/lib/mbrtowc-impl-utf8.h.
The mblen() and mbtowc() functions will happily return 4 or 5 or 6
for byte sequences that start with 0xF4 0x90 or higher. But those
sequences encode for U+110000 or higher, which are not valid Unicode
code points. The libc of FreeBSD and OpenBSD and Alpine correctly
return -1 for such sequences. Make nano behave correctly also when
linked against glibc, so that invalid sequences are always presented
as a series of invalid bytes and never as a single invalid code.
This fixes https://savannah.gnu.org/bugs/?60262.
Bug existed since before version 2.0.0.
The call of this function in make_mbchar() does not add anything,
because wctomb() already returns -1 for codes U+D800 to U+DFFF,
and parse_verbatim_kbinput() already rejects anything that starts
with U+11.... or higher, so make_mbchar() is never called for codes
beyond U+10FFFF.
And the call in display_string() just needs to check for wc <= 0x10FFFF
because mbtowc() already returns -1 for codes U+D800 to U+DFFF.
That is, accept U+FDD0 to U+FDEF, and accept U+xxFFFE and U+xxFFFF
for xx from 00 to 10 hex, being the 66 reserved "non-characters".
It may not be wise of the user to input these "things" (by typing
their code after M-V), but the codes are valid Unicode code points
and should not be rejected.
See https://www.unicode.org/faq/private_use.html#nonchar8 et al.
This fixes https://savannah.gnu.org/bugs/?60263.
Bug existed since before version 2.0.0.
When inserting a file into the current buffer, the 'fmt' element will
already be set. When we avoid overwriting the current value of 'fmt'
(when it's other than UNSPECIFIED), we don't need to save and restore
the value when inserting a file.
When saving the buffer under a different name, it should by default
have the same format as the original file.
This fixes https://savannah.gnu.org/bugs/?60278.
Bug existed since version 2.6.0, commit 0293eac1.
This improves the fix for https://savannah.gnu.org/bugs/?60269,
by not dropping error messages that happen before a buffer is opened.
This basically reverts commit b63c90bf from a year ago, except that
it now always deletes the created buffer when the user does not want
to override the lock file, also when it is the only buffer.
Set the 'format' of a file only when it has been fully read in,
so that this field can be used to indicate that any later error
message cannot be meant for this buffer.
This fixes https://savannah.gnu.org/bugs/?60269.
Bug existed since commit 6bf52dcc from yesterday.
Make sure there is an 'openfile' record before trying to save an
error message in this record.
This fixes https://savannah.gnu.org/bugs/?60268.
Bug existed since commit ede64d7e from yesterday.
Labels may contain digits (after the first character).
And the colon after "default" should not be colored.
Inspired-by: Hussam al-Homsi <sawuare@gmail.com>
When opening multiple files and some of them had an error, only the
first message was shown and the others were lost -- indicated only
by three dots. Improve upon this by storing the first error message
for each buffer and showing this message when the buffer is first
switched to.
Requested-by: Mike Frysinger <vapier@gentoo.org>
That is: reserve for the current line and current character the number
of positions needed for the total number of lines and characters, and
reserve two positions for both the current column and the total number
of columns. This will keep all nine numbers in the output in the same
place -- as long as there are no lines with more than 99 columns. In
this latter case there will still be some jitter, but all-in-all the
output is much stabler than it was.
Suggested-by: Mike Frysinger <vapier@gentoo.org>
The number of lines in a group is the difference in line numbers
between the last line and the first line *plus one*.
This fixes https://savannah.gnu.org/bugs/?60104.
Bug existed since version 2.9.0, since indenting and unindenting
became undoable, and commit f722c532 formed a part of that.
When the version number is a trio, the version string will occupy
ten bytes and the terminating NUL byte would not be written (which
was not a problem as byte 12 of the lock data is zero anyway).
But it's better to not have the compiler complain, so allow writing
the terminating NUL byte outside of the ten bytes reserved for the
version string.
Full justification (like justification of a selection) is probably
a rather rare action -- and possibly even an unintended action --
so it's good to give feedback about what happened also when using
the minibar.
When a line is marked as JUSTONTHIS, there should be no second start
match on that line, because otherwise the line would have been marked
as STARTSHERE (unless there is also a second end match -- but it's
fine to do unnecessary refreshes in this unlikely case, as long as
the necessary refreshes are made).
This fixes https://savannah.gnu.org/bugs/?60074.
Bug existed since version 2.5.0, but has been masked (for the C syntax)
by unnecessary refreshes since version 4.1, commit c9605e73.
When a line is marked as NOTHING, then the existence or the appearance
of an end match is irrelevant: there is no unpaired start match, so no
recoloring would occur, so there is no need to refresh.
When a line is marked as WOULDBE, then the existence or the appearance
of a start match is irrelevant (for the lines after the first WOULDBE
line): there already is an unpaired start match, so another one will
not change anything, so no refresh is needed. Only the appearance of
an end match would recolor things and thus require a refresh. However,
start and end regexes could match the same thing, so an end might get
misinterpreted as a start. So the rule has to check for the absence
of both a start and an end match, like for WHOLELINE.
This addresses https://savannah.gnu.org/bugs/?60072.
A step forward needs to be forced not when both start match and
end match have zero length, but when the "full match" (all text
from the start of the start match to the end of the end match)
covers zero bytes. In other words: the start and end match are
both of zero length AND are at the same spot.
Now that a search match gets highlighted, the unsuspecting user might
think that the text is selected, because it is colorized the same way
as selected text. Avoid this by colorizing a highlighted search match
with its own specific color, black on yellow by default.
In addition, suppress the feedback for M-C also when --minibar
isn't used, as the feedback obscures the effect of the toggle:
showing information about the cursor position on the status bar.
This fixes https://savannah.gnu.org/bugs/?60019.
Bug existed since commit 7545eb5b from one week ago.
Highlighting an occurrence is so much clearer than just putting the
cursor on it. People seem to like it. So let's make this how nano
behaves by default.
Take two conditions that are relevant only for a rather unlikely case
(a start match without a corresponding end match) out of an inner loop.
Give the case its own, dedicated loop.
When leaving the multidata unset (as was done until now) and the
end match is offscreen, then this could lead to miscolorings later
when jumping over this end match instead of scrolling past it.
This fixes https://savannah.gnu.org/bugs/?60012.
Bug existed since before version 2.1.10.
When a large piece of text or code is pasted or inserted, it could
contain matches for start= and end= regexes, and backtracking from
the current screen could mistake an end for a start and could thus
miscolor things. Avoid this by recalculating the multiline cache
for pastes and insertions that cover more than a screenful.
This fixes https://savannah.gnu.org/bugs/?59982.
Bug existed since version 2.6.0, but existed also before 2.4.3.
This allows having an even leaner interface, and gives the M-C toggle
an appropriate function (instead of leaving it a "dead" keystroke).
Suggested-by: Sébastien Desreux <seb@h-k.fr>
If a paste (or insertion) is more than a screenful, it will not set
'focusing' to FALSE. In that case, and when line numbers are already
active, then 'focusing' should be kept set to TRUE, despite it getting
set to FALSE by ensure_firstcolumn_is_aligned(). That latter action
is meant to cushion size changes of the edit window, but in this case
the large paste (or insertion) should trump the size change.
This fixes https://savannah.gnu.org/bugs/?59981.
Bug existed since version 2.8.3, commit 2b385478.
Commit 43d94692 fixed a miscoloring bug [1] by doing proper backtracking
for multiline regexes. But this change also solves an older miscoloring
issue [2] without needing to recalculate all the multiline data. So...
just drop the old fix. (This isn't perfect: it's probably possible to
cook up a replacement scheme where things get miscolored, but... until
then, this is good enough.)
[1] https://savannah.gnu.org/bugs/?59948
[2] https://savannah.gnu.org/bugs/?58481
Also, there is no need to set 'refresh_needed' in do_replace_loop(),
because each replacement prompt will call edit_refresh() anyway, and
the functions that call do_replace_loop() will set it afterward.
The precalc_multicolorinfo() routine will assign a value to every
element for every line without looking at any current value, so
wiping the data first is a waste of time.
After having been allocated, the multidata will get computed
immediately, in precalc_multicolorinfo() and draw_row(), so
first setting each element to -1 is a small waste of time.
The initialization of -1 cannot possibly match with NOTHING or
WHOLELINE or the other available values.
(Also, put in a warning, as I don't think an onscreen line without
a multidata cache can occur at all.)
Backtracking from the first row is needed in case a start match was
added recently somewhere offscreen and the user jumped to the current
location (instead of scrolling) so that the CWOULDBE markings did not
reach the current lines.
Also, search for an end match only for the first screen row. For the
other rows, rely on the CENDAFTER, CWHOLELINE, and CWOULDBE values to
indicate whether there *is* an end match (the first two values) or not.
This saves considerable time when there is no end match in the large
remainder of a buffer: it will search in vain for the end match just
once, instead of for every row of the screen.
This fixes https://savannah.gnu.org/bugs/?59948,
and addresses https://savannah.gnu.org/bugs/?59945.
Bug existed since version 2.7.5, commit b3bcc8ee.
Like the other two fragments that advance over a zero-length match,
also this fragment should avoid the possibility of stepping beyond
the end of the line.
When a zero-length match is beyond the width of the screen, there
is no point in continuing evaluating the rule, so the check for
"offscreen to the right" needs to come first. The check for a
zero-width match needs to come second because otherwise we would
get stuck on such a match when it is offscreen to the left.
When the match of a coloring regex is beyond the width of the screen,
there is no point in continuing to evaluate the regex for the rest of
the line, because any other matches will be offscreen too.
This will save some time when there are several overlong lines.
A syntax has on average a dozen coloring rules, but on average maybe
three or four pieces of text (rough estimate) in a line get painted.
So, on average, it is cheaper to call wattron() and wattroff() only
when actually coloring a piece of text, instead of calling wattron()
before starting to evaluate each rule and wattroff() after finishing
its evaluation.
When reaching end-of-line after having found a zero-width end match,
nano should not continue at 'seek-an-end' but instead at 'step_two':
going on to seek a start match in the current line.
(There is no bug report, because I cannot figure out how to trigger
this issue and cause nano to misbehave. The problem was found while
reviewing the comments.)
Bug existed since commit 9a4a5454 from four years ago,
but the behavior was poorer before that commit.
When the filename, header-line, and magic regexes are first compiled
while reading in the rc files (to check their validity), REG_NOSUB is
used, but for some reason this wasn't done when each of these regexes
gets recompiled in order to be used. Fix this oversight. It shaves
some twenty percent off of each of these regexes' compiling time.
The combining characters (that are zero-width) start at U+0300.
After that it's pretty much chaos, width-wise.
The mbwidth() function is not called for control characters (whose
representation takes up two columns), as they are handled separately.
The calls of mbwidth() that *can* happen with a control character as
argument are only to determine whether the character is zero-width,
and then it doesn't matter whether the exact width is 1 or 2.
An invalid UTF-8 starter byte should not be represented in the same way
as a valid Unicode character.
This fixes https://savannah.gnu.org/bugs/?59832.
Bug existed since two weeks ago, since the mini-bar code was merged.
The first byte of a multi-byte UTF-8 sequence must be in the range
0xC2...0xFF. Any other byte cannot be a starter byte and can thus
immediately be treated as a single byte.
When the tail of the answer still fits exactly on the screen, the ">"
continuation character should not be shown -- also when the start of
the answer is "scrolled off" to the left.
This fixes https://savannah.gnu.org/bugs/?59816.
Bug existed in this form since version 4.0, commit 56181896.
When making small movements in the lower right corner, ncurses can
get confused about where the cursor actually is -- a double-width
character seems to throw its calculations off.
This addresses https://savannah.gnu.org/bugs/?59808.
Bug existed since version 5.4, commit 39705c60.
Show leading dots for the truncated part, or (if there is no room
at all) show just an underscore instead of the file name.
This fixes https://savannah.gnu.org/bugs/?59802.
Bug existed since version 2.9.3, commit 97cbbb0c.
Now all toggle functions have the same name as their corresponding
long command-line option. Also, all names now indicate the effect
of the toggle when it is invoked from a default setting.
When space is too tight to show all three elements, show the report on
the number of lines in preference to the current location and character
code. The latter two will be shown again upon the next keystroke, so
there is little harm in hiding them for a moment.
The list of bugs is quite short these days, and most of them are
feature requests, so asking the user to check whether a particular
problem has already been reported doesn't make much sense.
The distinction between a stable series (even minor number) and
a development series (uneven) was abandonned five years ago.
This information is no longer helpful.
Having a block cursor present when highlighting a match...
does not look nice. So... hide the cursor until the next
keystroke, unless --showcursor or 'set showcursor' is used.
Not only does the match get highlighted (for better visibility), but
this also allows deleting the match with a single keystroke (^K, or
<Del> or <Bsp> when --zap is used) and then type something else.
This https://savannah.gnu.org/bugs/?59655.
Requested-by: Noam Sondak <noamso@gmail.com>
Remarks are about unsurprising things but it's good to give feedback
on them; "mistakes" are unexpected things, and get colored like an
error; and information is something that the user requested and thus
needs to stay on the status bar until the next keystroke.
For some reason, calling halfdelay() undoes the ISIG mask.
So, mask keyboard interrupts again immediately after the call.
Reported-by: Peter Passchier <peter@passchier.net>
Instead of redisplaying the minibar only upon the next keystroke
(when some feedback message is shown on the status bar), time the
waiting for the keystroke out after four fifths of a second, then
redisplay the minibar and continue the wait.
The bottom window (the prompt bar and the shortcuts) does not shift
its position when line numbers are active, so mouse clicks in this
window should be not be compensated for the line-numbers margin.
This fixes https://savannah.gnu.org/bugs/?59749.
Indirectly-reported-by: ObeliX <ObeliX-@gmx.de>
Bug existed since version 2.7.0, since line numbers were introduced.
Clicking on the cursor toggles the mark, meaning that the flags in
the title bar should be updated when --stateflags is active.
This fixes https://savannah.gnu.org/bugs/?59747.
Indirectly-reported-by: ObeliX <ObeliX-@gmx.de>
Signed-off-by: OIX <ObeliX-@gmx.de>
The state flags are relevant only when editing.
This fixes https://savannah.gnu.org/bugs/?59744.
Indirectly-reported-by: ObeliX <ObeliX-@gmx.de>
Bug existed since version 5.3, since --stateflags was introduced.
This allows using <Esc> <Esc> <letter> in a macro as an alternative
for <Ctrl+letter>, but it does require that one does not type <Esc>
by accident when recording a macro as it might modify the subsequent
keystroke when the macro is replayed.
This fixes https://savannah.gnu.org/bugs/?58904.
Bug existed since version 3.0, commit ecc9211a.
The workaround was for https://savannah.gnu.org/bugs/?51335
(a cursor-misplacement bug), but both an recent Xfce Terminal
and a recent Konsole appear unaffected by the issue. So, drop
the workaround for modern systems.
Checking for the actual version of libvte is too complicated, so
assume that libvte is 0.58 or newer (where the problem is fixed)
when ncurses is 6.2 or newer.
It was only ever needed when the user lied about the size
of the terminal, which should be considered a user error.
It was a workaround for https://savannah.gnu.org/bugs/?48852.
This avoids unnecessarily truncating the last help item on the
very bottom row when there is still plenty of room.
This fixes https://savannah.gnu.org/bugs/?59550.
Bug has been visible since at least version 2.5.1.
Subtract one from the count only if all possible items in the menu
have been counted (item == NULL), meaning that the last item in the
Write-Out menu (the 'discard_buffer' function) has been counted too.
This fixes https://savannah.gnu.org/bugs/?59549.
Bug existed since version 4.5, commit b3ace4d8.
When getopt() does not recognize an option, it returns '?', which means
that '-?' cannot be used as a valid option because any invalid option
would be treated the same way as '-?'.
Spewing out the full help text drowns the "invalid option" message at
the beginning.
This fixes https://savannah.gnu.org/bugs/?59530.
Bug existed since version 5.3, commit 5bd92d4c.
This avoids poor wordings such as "Words: 1 Lines: 1 Chars: 1".
Also, display the numbers in a more logical, ascending order: lines
first, words second, characters third. This is what 'wc' uses, too.
This makes the cursor move smoothly left and right -- instead of
"stuttering" when passing over a zero-width character.
Pressing <Delete> on a normal (spacing) character also deletes
any zero-width characters after it. But pressing <Backspace>
while the cursor is placed after a zero-width character, just
deletes that zero-width character. The latter behavior allows
deleting and retyping just the combining diacritic of a character
instead of the whole character.
This addresses https://savannah.gnu.org/bugs/?50773.
Requested-by: Mike Frysinger <vapier@gentoo.org>
(Yes, the test is for 6.0, but the bug was actually fixed in 5.9,
as far as I remember -- I just wasn't sure and didn't want to bother
building different versions of ncurses myself.)
Those versions are more than five years old. If there are still
machines with those versions, people should upgrade ncurses too
if they want the newest version of nano.
Some linters report a column position (assuming a TAB to be 8 spaces)
instead of a byte index, so make sure that the cursor is not placed
out of bounds when interpreting such a column number as an index.
This fixes https://savannah.gnu.org/bugs/?59419.
Reported-by: Ava McWhorter <qwerty0s.e.m@gmail.com>
Bug existed since version 2.8.1, commit 2439e1e4.
This takes eight extra calls of copy_of(), but saves ten calls of
free(). But more importantly: it avoids an unneeded copying and
then freeing again of the argument after 'titlecolor' and friends.
HTML 4 knows only the four-letter abbreviations for the arrows.
Use those, so that also browsers with very limited knowledge
(like Dillo) will show the arrows correctly.
And in the bargain elide a variable, and make it clearer
what the return value is at two early exit points.
[This change makes use of the fact that TRUE (successful write) == 1
and FALSE (failed write) == 0. But this is already used twenty lines
earlier, for the other call of write_file().]
Web links and email addresses do not belong in the version information.
This has bothered me for a long time. The URL is in the man page, and
bug reports should go to Savannah.
The terminal window in the graphical Debian installer (the default)
produces the same escape sequences as xterm for F1 to F4. Though
TERM is set to xterm, the xterm terminfo data is not available, so
ncurses is unable to translate the sequences for us. :| Therefore,
recognize the relevant raw escape sequences.
Also, eat all bytes of the non-recognized modified function and arrow
keys, so that they do not enter junk into the buffer.
The tiny version is probably only ever used in the Debian installer,
on the bterm terminal, which produces escape sequences like those of
a Linux console. So, exclude all other raw sequences.
(After support for Slang has been removed, we can maybe even exclude
ALL raw sequences from the tiny version, and the corresponding option
(-K/--rawsequences) too.)
At least since version 229 of xterm (from August 2007), the escape
sequences for F1 to F4 have been "Esc O P" to "Esc O S". There is
no bracket in those sequences, and there probably never was -- most
likely the extra "[" in nano's code was a slip of the fingers.
Trying to determine which syntax to apply with the help of libmagic
can be a somewhat time-consuming and yet often still fruitless affair.
Therefore using libmagic should not be the default; it should require
an option to tell nano to try using libmagic when it can't determine
the applicable syntax from the file's name or first line.
This is better than having a --nomagic option (and using libmagic by
default), because when the user has 'set nomagic' in their nanorc or
--nomagic in their alias, then switching the use of libmagic back on
is troublesome. But with --magic (and not using libmagic by default),
when nano fails to recognize a file, it is a simple ^X, add -! to the
command line, and restart.
The short form of the option is -! because we have run out of letters.
This addresses https://savannah.gnu.org/bugs/?59028.
With --stateflags (short form: -%) or 'set stateflags', nano reserves
the righthand end of the title bar not for showing "Modified" but for
showing the state of auto-indentation (I), the mark (M), the breaking
of long lines (L), macro recording (R), and softwrapping (S).
When the buffer is modified, this is indicated with a star (*) after
the file name (shown in the center of the title bar).
This fulfills https://savannah.gnu.org/bugs/?57953.
Requested-by: Sébastien Desreux <seb@h-k.fr>
Typing ^H (by default equivalent to Backspace) at the start of the file
is not useful. When it happens, assume that the user is new and tried
to ask for Help. So... explain what the caret and the "M-" in the help
lines mean.
Also, to keep menu items nicely grouped in the Main, Search, Replace,
and Goto menus, reorder a few items when no help is available.
This addresses https://savannah.gnu.org/bugs/?59110.
When nano reports "Unbound key" or "Unknown sequence", this message
should stay onscreen only for the relevant keystroke, not for any
succeeding keystroke.
This addresses https://savannah.gnu.org/bugs/?59119.
Bug existed since before version 2.0.6.
Slang fails to translate the longer sequences, and then truncates
these sequences to just four bytes, effectively destroying them.
Therefore, when built with --with-slang, always activate --raw-sequences.
This avoids https://savannah.gnu.org/bugs/?49771.
Bug was visible since version 2.5.0, since bindings
for Ctrl+Left/Ctrl+Right were added.
In this way, any message that is on the status bar after the search
will be a response to this search and not some leftover.
This fixes https://savannah.gnu.org/bugs/?59109.
(This effectively reverts commit ba47abb4 from two days ago, but it
groups things better. It makes an unnecessary call to bottombars()
for M-Q and M-W, but this hardly matters: searching in a help text
does not need to be efficient.)
This fixes https://savannah.gnu.org/bugs/?59108.
Bug existed since commit ba47abb4 from two days ago.
The tiny version is about being small, not about convenience features
that hardly anyone uses anyway.
Also exclude the description of the "+line[,column]" feature -- it is
unneeded verbosity.
This addresses https://savannah.gnu.org/bugs/?59101.
The cursor would disappear after any message on the status bar --
for example, also when M-W is typed and nothing is found -- so the
mitigation trick needs to be performed in statusline() itself.
This addresses https://savannah.gnu.org/bugs/?59091.
In the tiny version (built with Slang and running on Debian's bterm)
the Ctrl+Left/Ctrl+Right keystrokes do not work. When the terminal
is wide enough, instead of showing ^B + ^F for Backward and Forward
(which are unneeded because the unmodified arrow keys work fine),
show M-B + M-N for Prev Word and Next Word.
(Listing ^Space and M-Space instead would cause "Prev Word" and
"Next Word" to be truncated. They are weird keystrokes anyway.)
Also, list M-Q + M-W for "Previous" and "Next" next to "Where Is"
and "Replace", so that it is slightly clearer what they refer to.
For some reason, when running a tiny nano built with Slang on the bterm
of a Debian installer image, the cursor disappears when certain things
are written to the status bar. Make the cursor reappear by rewriting
the two help lines with dummy items (and then rewriting it again with
the normal menu in the central loop). Of course, this does not help
when the user uses -x or --nohelp to suppress the help lines, but at
least in the default setup the cursor doesn't get hidden now and then.
This mitigates https://savannah.gnu.org/bugs/?59091.
Bug existed since before version 2.2.4.
For some reason the Romanian PO file contains a literal ^Q in one
of its translated messages -- currently at line 1984. This stray
^Q causes 'file' to classify po/ro.po as data.
Make such mistaken control codes easier to spot when using nano.
Slang apparently needs a call to SLsmg_refresh() to restore the screen
content and put the cursor in the right place. But call this function
only when the suspension was actually caused by an external SIGSTOP,
because otherwise the original screen (from which nano was invoked)
gets plastered with nano's interface and content -- upon exit, this
is annoying and confusing.
Do not stuff a dummy keystroke into the input stream, as it seems to
get placed *after* the first byte of the next keystroke from the user.
That would cause an "Unknown sequence" for some keystrokes.
This fixes https://savannah.gnu.org/bugs/?59077.
Bug existed since version 2.8.5, commit 84ff9ebb.
The previous commit fixed https://savannah.gnu.org/bugs/?59071.
That bug existed since version 5.1, commit cc6d1d59.
But before that, a capital Ñ could not be typed (when built with Slang)
and would enter an invalid byte upon the next keystroke.
That bug existed since version 2.8.6, commit 43a5c876.
Instead of stuffing 0x91 into the input stream, use 0xFF when built
with Slang -- the same code that Slang itself produces when resuming
from an externally induced suspension. This byte is ignored.
In a UTF-8 locale, it should be safe to ignore the byte 0xFF coming
from the keyboard, as no valid UTF-8 sequence can contain 0xFF.
In an ISO8859 locale, this change prevents ÿ from being typed on the
keyboard -- it can still be entered with <Esc> <Esc> 255, though.
My apologies to the people of Pierre Louÿs and L'Haÿ-les-Roses.
Trying to ignore an external SIGSTOP/SIGTSTP with SIG_IGN does not work,
so always install the SIGCONT handler so that it is possible to continue
from a SIGSTOP.
This fixes https://savannah.gnu.org/bugs/?59073.
Bug existed since before version 2.0.6.
Constants that consist of a single character are valid too.
And a lone hash character on a line by itself also.
Signed-off-by: Hussam al-Homsi <sawuare@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
This probing has been changed four times in the past:
git log --grep get_wch
In March 2005, commit 2161fa62 changed the probe from get_wch() to
wget_wch(), reasoning that "get_wch() might be a macro instead of
a function". (Four months earlier, commit 3ba9c351 changed it
from addwstr() to wget_wch(), probably for the same reason.) But
three months later, in commit 25799f68, the probe gets changed to
get_wch() again, because "it's a more generic function"...
It seems clear that the non-macro argument is the stronger one.
See the NOTES section in 'man get_wch' for its possible macroness.
This addresses https://savannah.gnu.org/bugs/?58997.
Reported-by: Randall S. Becker <rsbecker@nexbridge.com>
This is the opposite of what 'ls' does in a UTF-8 locale, but nano
has never followed the collating rules of Unicode (uppercase after
lowercase, ignoring punctuation, and so on) -- it would be strange
to change that now.
Until now, nano left such equivalent names unsorted, in a seemingly
random order.
This fixes https://savannah.gnu.org/bugs/?59059.
Bug existed since before version 2.0.6.
And mention that a background color does not work on libvte before 0.55.
To find out the version of libvte on your system:
ls -R1 /usr/lib | grep libvte | grep 00 | grep -o "0\..."
Do the same what the normal "research" code does: if nothing was
searched for yet during this session, and there is a history of
search items, then search for the last item in that history.
Make case-insensitive searching in a UTF-8 locale eight times faster
when the actual characters involved are plain ASCII.
This makes us faster than 'less', and as fast as Vim and Emacs.
The disadvantage of this change is that searching for a string that
begins with a multibyte character is nearly ten times slower than
searching for one that begins with an ASCII character. This may be
unsettling when searching a huge file first for a simple ASCII string
and later for a UTF-8 one. Doing this second search, the user might
get impatient: "Why is it taking so long?"
(This patch fell through the cracks four years ago, when I worked on
the searching code. It sat in a branch on top of other changes that
I never applied because I made different improvements. The speedup
at the time, on that machine, was only around sixty percent, though.
But measuring it now again on the same machine, it clocks in at an
82 percent reduction with -O0 and an 87 percent reduction with -O2.)
Those casts are redundant, and sometimes ugly. And as the types of
variables are extremely unlikely to change any more at this point,
the protection they offer against miscompilations is moot.
Signed-off-by: Hussam al-Homsi <sawuare@gmail.com>
The two functions findnextstr() and do_replace_loop() do not change
or even touch 'last_search', so there is no need to save and then
restore its value when doing corrections of misspelled words.
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.
Avoiding this leak is more trouble than it's worth: invocation_error()
will be called seldomly, and when it is called, the user will probably
quickly exit from nano to fix things.
Also declare the speller functions as const again, so they don't give
the impression that their result can be freed.
Suggested-by: Brand Huntsman <alpha@qzx.com>
Now you can have a look elsewhere in the buffer (and even delete
or paste stuff there) and when you return to the original line
and continue typing, any spillover from automatic hard-wrapping
will spill over onto the same line it spilled over to before.
You can even switch to a different buffer and return and continue
typing, and stuff will still spill over to the same line.
In the bargain, this gets rid of a bit of flag-resetting code
that was run for many keystrokes, in most cases needlessly.
This addresses https://savannah.gnu.org/bugs/?56189.
When automatic hard-wrapping causes some piece of a line to be pushed
to the next line, then a separating space needs to be added at the tail
of this piece only when this piece actually gets prepended.
This fixes https://savannah.gnu.org/bugs/?56185.
Bug existed since version 2.9.2, commit 29f7654a.
When typing a space causes both the succeeding word and the cursor to
be pushed to the next line, then this space (and any contiguous ones)
does need to be snipped (when --trimblanks is in effect).
This fixes https://savannah.gnu.org/bugs/?56180.
Bug existed since version 2.9.3, commit 91073be4.
Fuzzy strings don't contribute anything to the translations that the
users get to see. They are useful only for translators, but translators
fetch or receive their PO files from the TP. For nano, fuzzy strings
just bloat the distribution tarball.
These obsolete strings contribute nothing to the translations that the
users get to see. They are somewhat useful only for translators. But
as nano is registered at the Translation Project, translators fetch or
receive their PO file from there (or they keep their own archive), so
these obsolete strings are not getting lost. But for nano, they just
burden the distribution tarball.
Do the same as in the previous commit: re-evaluate the start of the
viewport when lines that are located above this viewport may have
changed. This is relevant when softwrap is on.
When only the trailing chunk of a line is displayed on the top row of
the screen, and the unindenting of this line leads to a reduction in
the number of chunks, then the starting point of the viewport needs
to be re-evaluated. For simplicity, do this always when something is
unindented.
This fixes https://savannah.gnu.org/bugs/?56102.
Reported-by: Devin Hussey <husseydevin@gmail.com>
Bug existed since around version 2.9.2.
All other options are off by default and can only be switched *on*
(either by a command-line option or a nanorc setting) -- there are
no command-line options to switch them off again. Except for the
--breaklonglines/--nowrap pair. So these need special handling.
This fixes https://savannah.gnu.org/bugs/?56119.
Reported-by: Sébastien Desreux <seb@h-k.fr>
Bug existed since version 4.0, commit 4d40bea5.
When the file starts with one or more blank lines, the first paragraph
doesn't start on line 1.
This fixes https://savannah.gnu.org/bugs/?56117.
Bug existed since version 4.0, commit ac8bd2a2.
It is still possible to use --jumpyscrolling on the command line or
'set jumpyscrolling' in a nanorc file, but a user will have to restart
nano when they decide they want chunky instead of smooth scrolling,
a decision that should be rather rare.
This frees up the M-S keystroke to be reused for toggling softwrap.
The error messages from gnulib need to be included into nano's POT file
so that those messages get translated when nano is built on a platform
where the modules that contain the messages get used.
This fixes https://savannah.gnu.org/bugs/?56107.
Bug existed since gnulib support was added in version 2.8.0.
The relevant modules were added by commits 3deec435 and 272345cc.
For relatively inexperienced users (as most users of nano probably are)
it is far better that nano produces POSIX text files by default, where
each line ends with a newline character. This means that these files
will "print" properly (not gluing the next prompt at the end of the
last line), tools will see and process each line of them, and, while
editing, adding text at the end is easier.
This addresses https://savannah.gnu.org/bugs/?55997.
Reported-by: Ralph Corderoy <ralph@inputplus.co.uk>
Instead of doing a check every time round the loop when it is useful
only the first time, duplicate a bit a code and do the check and its
related action beforehand.
Also, improve some comments.
Also, find_bracket_match() is only called when there is a bracket under
the cursor, so stepping forward will never go beyond the end-of-line,
so the central loop does not need to check for that.
Also, improve a comment and shorten another, change a 'for' to a 'while'
(as the end point is not known), and rename a parameter from a single
letter to a word.
Some of these directives are now colored in their entirety, while for
a few others it's still just the keyword itself that is colored.
Signed-off-by: Liu Hao <lh_mouse@126.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The reading order must be predictable, otherwise things might get
colored differently from system to system.
This fixes https://savannah.gnu.org/bugs/?56012.
Otherwise the user could do something like
^R^X sed -i 's/a/surprise!/g' name-of-current-file <Enter>
and the file being viewed would be modified anyway.
The word "buffer" in relation to undo has been confusing to translators.
Also, drop the exclamation mark, as there is nothing important or urgent
about these messages.
The keystrokes are recognized and acted upon, but they are not visible
in the menu nor in the help text, and they cannot be rebound. They are
there just to avoid frustrating the muscle memory of long-time users.
This fixes https://savannah.gnu.org/bugs/?56002.
Reported-by: Peter Zwegat <peterzwegat@yopmail.com>
Because somehow something goes wrong when SIGWINCHes are handled while
reading from a pipe.
This fixes https://savannah.gnu.org/bugs/?56011.
Bug existed since version 2.4.2, commit 75d64e67.
Some commands can take a little while to execute; showing just the prompt
during that time could give the impression that nothing is happening.
This addresses https://savannah.gnu.org/bugs/?56041.
The lack of initialization caused a nasty bug on some targets (such as
ARMv7) which would make it so that ^S would just say "Cancelled".
While x86 (both 64 and 32 bits) seems to initialize 'response' to zero or
a positive number, ARM does not, and there is usually a negative value in
its place, which triggers the 'if (response < 0)' check and, as a result,
the code says "Cancelled".
This fixes https://savannah.gnu.org/bugs/?56023.
Reported-by: Devin Hussey <husseydevin@gmail.com>
Bug existed since version 4.0, commit 0f9d60a3.
Signed-off-by: Devin Hussey <husseydevin@gmail.com>
When nano was configured with --enable-tiny --enable-speller, the
block_sigwinch() function should be available, to mask SIGWINCHes
during a spell check.
The blocking is needed only during the wait(), so unblock SIGWINCH
again right after the wait() -- also to have the unblocking before
a possible error exit.
Somehow a SIGWINCH pushes nano past the wait() in do_alt_speller(),
even though the external spelling program hasn't finished.
This fixes https://savannah.gnu.org/bugs/?56010
by reverting commit 1f39f60b.
Bug existed since version 3.2.
Also because most of nano has meanwhile been written by other people
than Chris. And because authorship is meta-information, irrelevant
for knowing how to operate nano.
Since commit 4c6ec637 from about half a year ago, the 'action' parameter
of update_undo() is unused. Verify that this parameter matches the type
of the item at the top of the undo stack, so that in another half year
the parameter can be safely removed.
When the mark is off, initialize not just 'bot_x' but also 'top_x'.
This fixes https://savannah.gnu.org/bugs/?55898.
Bug existed since the justifying of a marked region was introduced,
four days ago, with commit f7f5514e.
When there is a dash among the files on the command line, nano will read
data from standard input, which means that the latter is not connected to
a terminal and thus cannot be recognized as a Linux VT until nano has
finished reading the input and has reconnected the input source to the
terminal.
The first probe for a Linux VT is kept in place for now, so that nano
can stop when there are errors in an rcfile while running on a VT.
(This stopping will not work when data is read from standard input,
of course, but that is a smaller fish.)
This fixes https://savannah.gnu.org/bugs/?55912.
Reported-by: Enrico Mioso <mrkiko.rs@gmail.com>
Bug existed since the recognition of modified cursor keys on a Linux
console was introduced, in version 2.6.3, commit 290d278f.
This matches Pico's behavior. However, Pico doesn't add the quoting +
indentation to the line in which the selection ends, but this is wrong,
so nano does add it. Also, Pico doesn't account for partial quoting +
indentation at the start or end of a selection, but this is wrong, so
nano does.
Unlike a regular paragraph, marked text may have different quotes and
more than two types of indentation. Handle this by replacing deviant
quotes with the quote of the first line, and deviant indentation with
the indentation of the second line.
This is modelled after Pico's behavior. However, Pico won't do anything
if you do a full-justify while the mark is on. But this is unnecessarily
limiting, so, when the mark is on, nano will handle a full-justify and a
plain justify the same.
This currently does not handle the lead (quoting + indentation) in
justified selections, does not put mid-line justified selections onto
separate lines, and does not strip whitespace after the lead in justified
selections, the latter two of which Pico does. These behaviors are
forthcoming.
concat_paragraph() concatenates a paragraph into a single line, and
rewrap_paragraph() rewraps that line into multiple lines again.
These two will be needed when the justifying of marked text is added.
Instead of passing 'quote_len' to these functions, calculate it directly
in them.
This will be needed when the justifying of marked text is added. When
unmarked text is justified, it is a single paragraph and by definition
has a uniform quoting part. But marked text may be a jumble of lines
that have different quoting parts.
Option -J (--guidestripe) takes a column number as argument and then
shows a vertical, colored bar over the entire height of the buffer,
to aid the user in regulating the width of the text when the terminal
is wider than this desired width.
This fulfills https://bugs.debian.org/916392.
Requested-by: Arturo Borrero González <arturo@debian.org>
And fulfills https://savannah.gnu.org/bugs/?55315.
Requested-by: Bryan Christ <bryan.christ@gmail.com>
When the right half of a two-column character gets overwritten by the
">" continuation character, then represent its left half as "[" also
when spotlighting a replacement candidate. Achieve this by calling
display_string() in the overshooting case with 'isprompt' set to TRUE,
which also makes this function reserve space for the ">" continuation
character so spotlight() doesn't need to do this any more.
This fixes https://savannah.gnu.org/bugs/?55679.
Improved-by: Benno Schulenberg <bensberg@telfort.nl>
The change in commit edc0d628 was flawed. The old logic covered
every case but one: having reached the end of 'buf' but 'column'
still having overshot the screen width. Now cover this latter
case too.
This fixes https://savannah.gnu.org/bugs/?55638 properly,
allowing the next commit to fix another buglet.
Condensed-by: Benno Schulenberg <bensberg@telfort.nl>
In this way, for single-width characters, one can see what character is
ahead of the cursor before actually moving the cursor to that position,
and, for double-width characters, the cursor never sits on a placeholder
but always shows the character that is actually there.
This addresses https://savannah.gnu.org/bugs/?55716.
In the tiny version the feature toggles are absent, so most of the
Meta-key combinations do nothing, and when --with-slang was used, the
<Ctrl+Left/Right> keystrokes do not work (as they produce truncated
escape sequences under Slang), and the <Ctrl+Space> and <Alt+Space>
keystrokes are awkward to type and make no sense. So... use some
of the free Meta combinations to jump a word to the left or right,
since these functions *are* present in the tiny version.
The reload_positions_if_needed() routine can free the existing
'position_history' and allocate a new one. Using the old one,
from before the reload, could lead to a crash.
This fixes https://savannah.gnu.org/bugs/?55792.
Reported-by: Enrico Mioso <mrkiko.rs@gmail.com>
Bug existed since the reloading of the position-history file was
introduced, a year and a half ago, in commit bfc53f30.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
That is: keep nibbling off characters until a character is eaten that
takes up at least one column.
This fixes https://savannah.gnu.org/bugs/?55759.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Bug existed since version 2.8.0, commit 5283acdc.
On small terminals (80 columns or so), ^S and ^Q would be in
the last position of the help lines. But some terminals might
intercept ^S and stop all output (until ^Q is pressed), which
could be unexpected and frustrating. So, rearrange things for
the tiny version so that ^S appears only on very wide terminals.
Also, having two keystrokes for saving the current buffer
(^O and ^S) in the two help lines is wasteful, more so as
in the tiny version there are no ^G help texts.
So, show the more useful M-Q and M-W instead.
This addresses https://bugs.debian.org/915017.
Reported-by: Steve McIntyre <steve@einval.com>
If these two command-line options would override an rcfile setting of
their counterpart new option, the user might come to expect being able
to do this also in the future. But these old options will be obsoleted
at some moment, so... better start ignoring them right now.
The start-of-paragraph and end-of-paragraph seeking functions are only
vaguely related to searching, and have nothing to do with replacing --
the functions make more sense in the Goto-Line menu.
Also, the Goto-Line menu is much less crowded, so the functions are
more likely to be noticed there. Furthermore, this makes harmless a
typo that I sometimes make: typing ^W again when I've already done so.
Jumping to the first or last line of the buffer doesn't have anything
to do with searching, so these functions shouldn't be present in the
search menus. They make perfect sense in the Goto-Line menu, though.
To make it obvious that they are not actual characters in the file.
The default highlighting is in reverse video, but this can be changed
to bold by using --bold or 'set boldtext'.
This fulfills https://savannah.gnu.org/bugs/?55571.
The angular brackets look a bit like arrows and thus hint much more
at the idea of continuation than a dollar sign.
With-help-from: David Lawrence Ramsey <pooka109@gmail.com>
When the screen's edge leaves just one column for a two-column
character, then show its left half as "[" and its right half as "]".
(They used to be shown as ">" and "<", but these characters will be
repurposed in the next commit.)
This addresses https://savannah.gnu.org/bugs/?55657.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
The get_history_older_void() and get_history_newer_void() functions
are mere names, they don't actually do anything. So... don't bother
to execute them, so the 'finished' variable doesn't have to be reset
after calling them.
Also, normalize the order of those two empty functions.
When doing replacements or fixing misspelled words, and edit_refresh()
is called to highlight the relevant word, then the current menu can be
anything from MREPLACEWITH, MYESNO, MSPELL, or MMAIN. Make sure it is
always set to the latter just before calling edit_refresh(), so that
display_string() will use the full length and the word gets properly
highlighted.
This fixes https://savannah.gnu.org/bugs/?55680.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Bug was introduced by the previous commit, 56181896.
It needs to be trimmed and substituted with a single-width placeholder
to prevent the continuation character ">" from getting pushed to the
next row.
Also, use the correct width for the answer so that the continuation
character is only displayed when the answer does not fit any more.
This fixes https://savannah.gnu.org/bugs/?55620.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Original-patch-by: David Lawrence Ramsey <pooka109@gmail.com>
When a line ends with a two-column character, and this character straddles
the edit window's edge, then, although we've reached the end of 'buf', we
have exceeded the 'beyond' column and this two-column character needs to
be trimmed from the 'converted' string, otherwise it would get printed on
the next row.
This fixes https://savannah.gnu.org/bugs/?55638.
Bug existed since version 2.8.0, commit 5283acdc.
Also, enable smooth scrolling by default, and don't waste the row
directly below the title bar. The use of the latter also serves
as a small visual reminder that this nano is different.
This addresses https://savannah.gnu.org/bugs/?55067.
This signals our break from trying to be as compatible with Pico as
possible. We were already incompatible with modern Pico in the -n
and -W options, and in several character-set and color options, so
ignoring those five options brought us very little.
Anyway, soon some of those options will be reused and will have the
effect of making nano look and behave more like Pico.
Using the cursor keys for movement-related functions makes more sense
than using them for jumping to the previous or next occurrence of the
search string.
(For searching another occurrence backward the M-Q binding has become
available, while M-W will search another occurrence always forward.)
Now also comment blocks in Fortran, Lisp, Lua, Postgres, and TeX
can be rewrapped with ^J.
This partially addresses https://savannah.gnu.org/bugs/?55435.
Kind-of-requested-by: David Griffith <dave@661.org>
After a series of escapes, also <Shift+Meta+letter> should be recognized
as a command keystroke, not just <Meta+letter>.
This fixes https://savannah.gnu.org/bugs/?55442.
Bug existed since the ignoring of <Escape>s before a valid command
keystroke was introduced in version 3.0, commit ecc9211a.
When the user switches backups on later (with M-B in the ^O menu),
the specified folder should have been checked for validity.
This fixes https://savannah.gnu.org/bugs/?55423.
Bug existed since the check for a valid backup directory was introduced
in version 2.8.7, commit 751e7f0f.
The reduced file size should be stored not just when joining two lines
but also when simply a character in the middle of a line is deleted.
This fixes https://savannah.gnu.org/bugs/?55352.
Bug existed since version 2.5.0, commit 66e21416.
All tested systems (FreeBSD, NetBSD, OpenBSD, Alpine, and Ubuntu)
support the GNU-style word boundaries (\< and \>), either natively
or through using the regex module from gnulib.
If this change breaks regexes containing \< or \> on your system,
please report a bug: https://savannah.gnu.org/bugs/?group=nano
This addresses https://savannah.gnu.org/bugs/?55207.
Reuse the WAS_FINAL_LINE flag to signal a cut that added a magicline,
for both a marked cut and cut-to-eof.
This fixes https://savannah.gnu.org/bugs/?55305.
It's not just about the numeric keypad, but about the interpretation
of all editing keys (arrows, Home, End, PageUp, PageDown, Insert, and
Delete), of the escape sequences that they produce.
When using --raw, ncurses does not catch and convert any mouse event,
and thus the coordinates of a mouse click would get inserted into the
buffer as seemingly random characters. So, let --rawsequences override
and disable --mouse, to prevent the accidental entering of junk.
This fixes https://savannah.gnu.org/bugs/?55303.
To better describe what it does, and to have full contrast with the
--rebinddelete option: the latter can now be shortened to --rebind
without getting a conflict, and --rawsequences can be abbreviated
to simply --raw and still make sense.
When the terminfo selected by TERM does not match the terminal and
the <Delete> key behaves the same as <Backspace> (deleting leftward)
or the <Backspace> key behaves the same as <Delete> (deleting without
moving the cursor), then using just -d or --rebinddelete should make
the deviant key behave correctly again without affecting the other.
ASCII code BS should always do a backspace, also on systems where the
"^H" string gets redirected (for rebinding purposes) to KEY_BACKSPACE.
This fixes https://savannah.gnu.org/bugs/?55247.
Reported-by: Norton Warner <nortonwarner@gmail.com>
When not unbinding it from its earlier function (in the same menu),
it would result in showing the keystroke twice in the help text.
This fixes https://savannah.gnu.org/bugs/?55239.
Bug was introduced a month ago, by commit f81d174f.
The direct call was a leftover of the old unjustify mechanism.
Also, move two statements to the end of the do_justify() routine,
since that is their place in comparable routines.
Suggested-by: David Lawrence Ramsey <pooka109@gmail.com>
When multiple buffers are open, the edit window says "Close" for ^X
instead of "Exit" (when one buffer is open). In the help viewer ^X
says "Close". Apparently the idea is that ^X should say "Exit" only
when pressing ^X leads to exiting from nano. Pressing ^X in the file
browser does not exit from nano, so make it say "Close" instead.
(The help viewer says "Close" since version 2.8.6, commit 934a2192.)
When using --preserve, ^S and ^Q are "eaten" by the terminal and
do not reach nano: they have no effect in nano, so the help lines
and the help texts should not mention these shortcuts.
Also, to keep the help lines in the help viewer neatly arranged,
^L is not bound there when --preserve is used.
Not stepping beyond the last line of the paragraph means that the
length of the paragraph is always the difference in line numbers
(between first and last line of the paragraph) plus one.
When leaving the mark on while justifying and then undoing the
justification, things are likely to get messed up. My applying
David's patches only partially caused this breakage.
This fixes https://savannah.gnu.org/bugs/?55074.
Only the first search for a paragraph needs to check whether we're
currently in the middle of a paragraph. When the 'while' loop for
a full justify is executed, all calls of find_paragraph() start
either on the first line of a paragraph or between two paragraphs.
To find a paragraph, what needs to be done is:
a) When not in a paragraph, move forward until we find one, if any.
b) When in a paragraph but not at its start, move back to its start.
c) Move forward to the end of the paragraph, if any.
When, in the 'while' loop for a full justify, 'filebot_inpar' becomes
TRUE, it means that EOF has been reached and find_paragraph() should
not be called again. To allow 'filebot_inpar' to convey this meaning,
it should not be set to TRUE elsewhere, so another boolean is needed
for setting the correct length of the final line of the cutbuffer.
This fixes https://savannah.gnu.org/bugs/?55086.
The removal of the x-coordinate handling affected this. Reshuffle things
so that we can check for it after we have moved (the same way we check for
it at the beginning of the function before we move) without having to set
'quote_len' and 'par_len' unnecessarily.
Also, adjust some comments accordingly.
Move detecting the final line of the paragraph to find_paragraph(),
since a paragraph of which the final line is the last line of the
buffer will still be that way after being justified.
Also, move all x-coordinate handling to do_justify(), since it only
applies to the current buffer.
Move a few references to the current buffer to do_justify(). Also,
the check for being at the end of the buffer needs to be done after the
first paragraph is found, so that the existing behavior of finding an
initial paragraph regardless of cursor position is preserved.
The functions do_para_begin() and do_para_end() can now move through any
buffer, while the functions do_para_begin_void() and do_para_end_void()
operate on the current buffer. The latter function also returns TRUE
if the last line in the buffer is part of the paragraph.
Remove the handling of 'edittop', 'totsize', and the mark, to make the
function more general, which is needed to make it undoable eventually.
This breaks the function somewhat. Fixes for this are forthcoming.
The function assumes that it works on the current buffer by handling
'totsize' and the mark. Remove this handling to make the function
more general, which is needed to make it undoable eventually.
This breaks the function somewhat. Fixes for this are forthcoming.
The new binding will be put at the head of the list and thus will
be the one that is found -- the old binding will never be seen, so
rubbing it out is just a waste of time.
Further down, the <Backspace> key is bound to do_page_up() for MHELP
and MBROWSER, so this earlier binding should exclude MBROWSER.
This partially fixes https://savannah.gnu.org/bugs/?54978.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Bug existed since version 2.9.2, commit 8581e702.
Set the Meta flag only for the regular Meta keystrokes: "M-" plus a
printable ASCII character. The special keycodes are unique and do
not need any extra flags to differentiate them.
This works for xterm, rxvt, Eterm, Konsole, and xfce4-terminal, which
generate "Esc [ 3 ; 3 ~", but not for urxvt, which generates one of
its double-escape sequences, "Esc Esc [ 3 ~".
Using --zap or -Z on the command line, or 'set zap' in a nanorc file,
makes the <Bsp> and <Del> keys erase selected text (a marked region)
as they do in some other editors, and without affecting the cutbuffer.
This fulfills https://savannah.gnu.org/bugs/?54837.
Requested-by: Liu Hao <lh_mouse@126.com>
Signed-off-by: Brand Huntsman <alpha@qzx.com>
This function allows the user to "make space": annihilating lines or
regions while keeping intact for pasting the stuff in the cutbuffer
that was cut or copied earlier.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
Return immediately to editing mode when there are no messages for
the original file and the user does not wish to open any of the
included files that do have messages.
Also, reword the message that the linter gives then, and leave it
on the status bar (just like when Cancel is pressed).
The bindings for F1 to F12 are there for compatibility with Pico.
But Pico does not know anything about F13 to F16; for unknown reasons
they were added to nano. They seem hardly useful: normal keyboards
do not have the F13 to F16 keys, and very few people know that they
can "produce" those keys by holding Shift with F1 to F4. But typing
Shift plus F1 to F4 are just as "hard" as, for example, M-G and M-W,
so why anyone would want to use the first ones...? Especially since
many other functions of nano can only be accessed through Meta and
Control combinations.
Furthermore, F13 to F15 haven't been shown in the help texts since
version 2.3.3, so for more than four years no new user will have
learned about those keystrokes.
The rare user who wants these strange bindings can easily make them
herself.
The help lines will help differentiate this mode from normal editing
mode, and will tell the user how to jump to other messages.
This is a third step to address https://savannah.gnu.org/bugs/?54714.
When --view is used without --ignorercfiles, the user could view
other files anyway if they had 'set multibuffer' in their nanorc.
So, just make this the default when --view is used, also because
"multibuffer" cannot be toggled once nano is running in view mode.
When the viewing of other files in view mode should not be allowed,
one should now additionally use --restricted.
The 'wrap_at' variable, removed in commit e90b7cf4, is actually needed
to store the original value of the --fill option when it is negative.
Otherwise, changing the screen width will not update the wrapping point
properly.
This fixes https://savannah.gnu.org/bugs/?54861.
Reported-by: Brand Huntsman <alpha@qzx.com>
The ^P and ^N keystrokes for Older and Newer are relevant to searching
and should be visible in the help lines. FullJustify, paragraph jumps,
and top/tail jumping are there only for compatibility with Pico but
don't make any sense there, so it's no problem if they are pushed out
of view.
Rename not only the bindable functions, but more importantly reword the
tags that are shown for ^P and ^N in the help lines: "Older" / "Newer",
because these are clearer and not awkward abbreviations.
When using --view --multibuffer --restricted, it is the latter option
that forbids reading in another file, so that is what the status bar
should say.
This fixes https://savannah.gnu.org/bugs/?54824.
Bug existed since version 2.9.5, commit 8b8c6bb8.
When something is spotlighted, it should survive a refresh of
the screen and an excursion to a help text, so the spotlight
should get painted whenever the edit window is drawn.
This fully fixes https://savannah.gnu.org/bugs/?54721.
It would result in having both <Delete> and <Backspace> behaving as
Backspace, which seems senseless -- unless the <Delete> key produces
ASCII DEL and --rebinddelete is needed to make it behave as Delete.
In the latter case it would make more sense if --rebinddelete made
both rebindings: ASCII DEL to Delete and KEY_DC to Backspace, like
it used to be in the distant past, before commit 79a33bb3.
Ask ncurses for the codes for the Shift+arrow keys, so that also
<Shift+Up> and <Shift+Down> can be recognized, for which ncurses
doesn't have standard codes.
This fixes https://savannah.gnu.org/bugs/?54790.
Reported-by: Javier Valencia <javiervalencia80@gmail.com>
Move the unsetting of some options further down, to prevent the user's
nanorc enabling things that are not permitted in restricted mode.
Also, in restricted mode, suppress error messages about functions not
being present in the requested menus, so that a nanorc that is valid in
normal mode does not cause unnecessary messages when using --restricted.
This fulfills https://savannah.gnu.org/bugs/?54732.
Requested-by: Mark Webb-Johnson <mark@webb-johnson.net>
The new function, justify_paragraph(), takes a quote length and a
paragraph length (which it should get from find_paragraph()), and
runs the paragraph at (current, current_x) through justify_format().
Move some fragments out of the justifying loop, and adjust/clarify comments
to account for the changes. This will allow some of the code to be cleaned
up and simplified in the next commits.
This allows running the speller (default binding: ^T) also on files for
which a linter has been defined. This makes it possible to spell check
comment blocks in source files, for example.
This fulfills https://savannah.gnu.org/bugs/?54711.
Requested-by: Mike Frysinger <vapier@gentoo.org>
Only for BACK and DEL was the first call to update_undo() -- all other
types of action would call add_undo() first, so for them the action in
update_undo() would never be different, but the line number might have
changed (like for ENTER and INSERT), so for them exceptions needed to
be made, which was wasteful.
This addresses https://savannah.gnu.org/bugs/?54728.
The binding was made only to have *something* bound by default to the
'cutwordleft' function. But now that <Ctrl+Shift+Delete> is available
*and* visible in the help text, the M-| binding is superfluous.
When using the internal spell checker, the message gets overwritten
immediately by "Creating misspelled word list...", and when using
the external spell checker, nano immediately exits from curses mode
and thus the message disappears (when in a terminal emulator) or it
soon gets wiped by the spell checker (when on a Linux console), thus
creating a little flash on the bottom row, which we can do without.
In the past, SIGWINCHes were responded to immediately (which was madness),
but since commit 75d64e67 all a SIGWINCH does is set a flag so that, when
the time comes to update the screen, nano knows the dimensions may have
changed. The mentioned commit removed most blockings and unblockings of
SIGWINCH, but not this one.
Assume that 'print' and 'exec' are statements when they are followed
by whitespace, and are functions otherwise. This does not highlight
"print'x'" nor "print{x}", but these statements are poor style.
Signed-off-by: Benjamin Mintz <bmintz@protonmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
So that the user can do 'bind ^H cutwordleft all' in their nanorc
to make ^H (and sometimes also <Ctrl+Backspace>) delete the word
to the left of the cursor while <Backspace> continues to delete
just one character.
As the statusbar() function will write the position directly to the
terminal when not in curses mode, the final part of this position
message will seem to be after the prompt when exiting from nano.
The cursor position will get written correctly to the status bar
anyway, because returning from suspension enters a fake key into
the keyboard buffer, and this key elicits an update of the display.
This fixes https://savannah.gnu.org/bugs/?54639.
Reported-by: Lauri Kasanen <cand@gmx.com>
Bug existed since version 2.4.2, commit 75d64e67.
Most of these toggles just change the appearance of things, and
all of them are harmless -- none of them modify the contents of
the buffer.
This fixes https://savannah.gnu.org/bugs/?54650.
Reported-by: Liu Hao <lh_mouse@126.com>
Bug existed since version 2.9.4, commit 54103d8e.
(The offending commit meant in the previous commit was 60f1090d.
My mistake.)
When curses gives no code for Ctrl+Shift+Delete, do not fall back
to KEY_BACKSPACE, because then ^H and/or <Backspace> get bound to
'cutwordleft'.
This fixes https://savannah.gnu.org/bugs/?54642.
Bug was introduced with version 3.0, commit e6429e78.
That is, wait with deleting words until they start under cursor,
so the user can see which word is goin to be eaten, and join lines
only when the cursor already sits at the edge of a line.
On FreeBSD and NetBSD (when reached through ssh from a Linux machine)
this has the absurd effect of making <Ctrl+Backspace> do a 'cutwordleft'
by default, out of the box, without needing any rebindings. Weird, but
wonderful, because the ideal behavior.
Also ensure that <Shift+Delete> always does a Backspace.
This makes that we have the following set of "congruent" keys:
<Tab> moves text to the right,
<Shift+Tab> moves text to the left,
<Delete> "eats" a character to the right,
<Shift+Delete> "eats" a character to the left,
<Ctrl+Delete> "eats" a word to the right,
<Shift+Ctrl+Delete> "eats" a word to the left.
Also, don't partially color "..." as an operator, because it isn't,
and color also the unary operator "#".
Signed-off-by: Mark-Weston <markweston@cock.li>
Adding "[abc]*" does not restrict the recognized header line in any way.
Also, improve the header-line regex for shell scripts, because it should
not match "barunscript" (for example).
If find_paragraph() detects that we're not in a paragraph, it moves
forward a paragraph and then backward to that paragraph's beginning.
Make it check whether we're in a paragraph before moving backward
(since there might not *be* any more paragraphs), to prevent going
forth-and-back and never reaching the end of the buffer.
This fixes https://savannah.gnu.org/bugs/?54573.
These are available in the menus where they are relevant: the Write-Out
and the Insert menu, respectively. Having them duplicated in the main
menu is inconsistent and eats precious keystrokes. (Sorry, Chris.)
When 'inhelp' is true, there are at least two buffers open: an
edit buffer and the help-text buffer.
And bottombars() already does a full refresh of the bottom window.
And restore the cursor to this position when redoing the cut+insert.
Also remove two unneeded conditions.
This fully fixes https://savannah.gnu.org/bugs/?54466.
When piping the buffer (or the marked region) to an external command,
we should wait not only for the external command to terminate but also
for the data-sending process, so that it will release its resources.
This fixes https://savannah.gnu.org/bugs/?54499.
With-help-from: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
When undoing/redoing an alternate spell check (of the entire file
or of a backwards marked region), put the cursor back where it was
when the spell check was invoked/finished.
This fixes https://savannah.gnu.org/bugs/?54466.
On a Linux VT, refuse to start when there are errors in a nanorc file,
so that the messages no longer get overwritten -- which prevented the
user from seeing and reading them.
This fixes https://savannah.gnu.org/bugs/?54442.
Since the last version, the user can filter an entire buffer through
an external command. This external command can also be a formatting
program, so there is no longer any need for this specific and special
formatter command.
(In the Search and Replace menus Cancel is not essential. And in the
Goto Line menu Cancel is not needed at all: a simple <Enter> after an
empty answer works fine.)
This fixes the second part of https://savannah.gnu.org/bugs/?54447.
There are at least three other ways to achieve the thing that it did:
^End, M-/, and ^W^V. No need to have a fourth way by default.
For symmetry, also unassign the corresponding binding for M-|.
The 'cutwordright' function has gotten ^Delete as its default binding,
so the 'cutwordleft' function needs a default binding too -- also to
keep the items on the two help lines nicely paired. M-| was chosen
because it is close to the Backspace key on many keyboard layouts.
Print routines are not asynchronous-safe.
But... the only reason the call of kill() could return an error code
is when the relevant process has already terminated -- which is not
a problem, because that was the goal of calling kill().
This fixes https://savannah.gnu.org/bugs/?54409.
Reported-by: Daniel Kozovsky <dkozovsk@redhat.com>
As the help viewer is almost a normal buffer, commands that make sense
-- like searching backwards, and searching the previous occurrence --
should work in the help viewer too.
In addition, show all Search commands prominently in the help lines of
the help viewer, so that users are likely to notice them and will maybe
infer that they work in the editor itself too.
This fixes https://savannah.gnu.org/bugs/?54368.
With-help-from: David Lawrence Ramsey <pooka109@gmail.com>
Put "Where Was" in its place, to make the symmetry of ^W/M-W/^Q/M-Q
somewhat clearer. Also, conditionally reshuffle "Save File", to try
and keep menu items nicely paired.
Bind the until-now unbound function 'cutwordright' to <Ctrl+Delete>.
The complementary function, 'cutwordleft', is not bound by default
because on many terminals the keystroke <Ctrl+Backspace> generates
^H -- the canonical ASCII backspace character. We cannot change the
existing action of ^H without upsetting some users.
Signed-off-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
To match the documentation and to match what the nanorc.nanorc
colors as valid.
In theory it would be possible to allow rebinding also F17...F63,
but nano does not recognize escape sequences for these high-order
function keys. As no one ever complained about unknown sequences
when pressing function keys, I am guessing that no one has these
high-order keys, or at least that no one uses them.
This fixes https://savannah.gnu.org/bugs/?54332.
Instead of being entirely silent when ^] is hit after whitespace
or punctuation, report what is lacking -- similar to M-] saying
"Not a bracket" when the cursor is not sitting on a bracket.
This makes the ^] keystroke more discoverable.
This makes things symmetrical: ^W starts a forward search, ^Q starts
a backward search, M-W searches the next occurrence forward, and M-Q
searches the next occurrence backward.
The Tabs-To-Spaces toggle is moved to M-O, and thus the More-Space
toggle is no longer bound by default.
When using option -K on an xterm-like terminal, pressing <Shift+Del>,
<Alt+Del>, or <Ctrl+Del> would enter "2~", "3~", or "5~", respectively,
into the buffer. Now it will just report an "Unknown sequence".
The crawl needs at least five rows to be perceived as a crawl, and
the widest line is 31 characters (ignoring translations, which might
be even longer). Formerly, when only two or three rows were available,
nothing was shown at all, which was puzzling. So, better do the credits
only when there is room enough for them, and print a message otherwise.
When switching to a different buffer, don't just show its name but
also the number of lines it contains. This is useful extra info.
Then use this same message when at startup multiple files are opened
and (after reading them all) we switch back to the first buffer.
(This loses, when multiple files are opened, the information about
format conversion that nano still shows when a single file is opened,
but... this bug has shown that people don't really look at this line
anyway, so... let it be. The info can still be seen when writing out
the file with ^O.)
This addresses https://savannah.gnu.org/bugs/?54047.
Just like an <Esc> before a Ctrl+letter keystroke is ignored, an <Esc>
before an Alt+letter keystroke should be ignored too -- it should not
be interpreted as if the user had typed <Esc> <Esc> letter.
This fixes https://savannah.gnu.org/bugs/?54301.
Even when we don't act on most of these combinations, at least eat up
the whole sequence so the unknown keystroke doesn't enter things like
"3~" into the buffer.
This fixes https://savannah.gnu.org/bugs/?54291.
Unlike glibc, which in getc() locks the file only when it is needed,
FreeBSD and Bionic libc will always lock the file, causing a massive
slowdown, as the system has to create and destroy a mutex each time
getc() is called.
Avoid that massive overhead by locking the file before starting to read
and unlocking it after reading is complete, and using getc_unlocked() to
read each byte. This makes reading on FreeBSD/macOS and Android anywhere
from 2 to 6 times faster, and on glibc roughly seventy percent faster.
This partially addresses https://savannah.gnu.org/bugs/?50406.
Signed-off-by: Devin Hussey <husseydevin@gmail.com>
Also, consistently refer to Latin letters and ASCII characters
where needed, and document more accepted characters.
This addresses https://savannah.gnu.org/bugs/?54071.
The 'statusbar_x' variable does not refer to a position in the status
bar, but to a position in the answer that is currently being typed at
the prompt. So... let's call it 'typing_x', for lots of contrast.
The Alt key together with Shift is a special workaround for when
Shift+PgUp and Shift+PgDn don't work on the user's terminal. But
probably it is more common to use the Ctrl key together with Shift
to select larger pieces of text. So mention this possibility.
And in the bargain get rid of some duplicate code.
This makes a binary without UTF-8 support slightly slower, but that's
not important -- it is more than fast enough anyway. Important is that
the most used and longest code path, the UTF-8 case, becomes faster.
Note that 'is_cntrl_mbchar()' will fall back to 'is_cntrl_char()' for
a non-UTF-8 build, so the deleted piece of code really was equivalent
with the remaining piece for that case.
Take our cue from undoing/redoing line joins: when they take place on
the magicline without --nonewlines, they produce undo/redo items that
don't do anything to the text, but still position the cursor properly.
Reshuffle a bit of code so that we can do the same for magicline cuts.
This fixes https://savannah.gnu.org/bugs/?54032.
Again, if the most significant bit of a UTF-8 byte is zero, it means
the character is a single byte and we can skip the call of mblen(),
*and* if the character is one byte it also occupies just one column,
because all ASCII characters are single-column characters -- apart
from control codes.
This partially addresses https://savannah.gnu.org/bugs/?51491.
For UTF-8, if the most significant bit of a byte is zero, it means the
character is just a single byte and we can skip the call of mblen().
For files consisting of pure ASCII bytes (between 0x00 and 0x7F), this
change reduces the counting time of mbstrlen() by ninety six percent.
This partially addresses https://savannah.gnu.org/bugs/?50406.
When mbtowc() is never called with anything less than MAXCHARLEN as
the length parameter, it will apparently not get confused and will
not need to be reset.
The variable 'last_action' is set at the end of these functions,
serving to prevent a fresh action from being merged with an older
action further down on the stack. Setting 'last_action' before
exiting from undo()/redo() makes no sense.
Also adjust a sideways related old Changelog item.
The macro stuff, however, is basically my code: I told him exactly
how to do it, and I changed most of the patch before applying it.
Also, put myself in second place, as I've just about overtaken David
in the duration of maintainership.
Otherwise the first line of a multiline /*...*/-comment would be
seen as quoted and thus *not* as the first line of a paragraph.
In the code, use "/{2}" to prevent the remainder of the line
getting colored as a comment.
The paragraph-aware indenting is needed only when automatic long-line
wrapping is on (that is, when not using 'nowrap': when writing prose).
When writing code, the user most likely uses --nowrap, which will make
nano indent a new line always to the same amount as the preceding line
-- when --autoindent is in effect, of course.
The only time that feedback about the number of lines written is *not*
wanted is when writing a temporary file.
This fixes https://savannah.gnu.org/bugs/?54025.
Plus one that automake recognizes: if. Color them only at the start
of a line. Also color all possible assignment sequences (surrounded
by spaces to not color the ones in shell fragments), and add some
comments.
When doing autoindentation, and the next line is not the start of
a new paragraph, then use the indentation of that line for the new
line, as it is more likely to have the desired indentation -- the
current line might be the start of the paragraph and thus could
have a deviant indentation.
Pico wraps at the last blank character before or on the target column;
if there is no such blank, then it will wrap at the first blank *after*
the target column -- when it can wrap, it will wrap. Nano should do
the same (and judging from the comments, it intended to do the same),
instead of turning the paragraph into a single unwrapped line.
This fixes https://savannah.gnu.org/bugs/?53986.
First step to the next buffer, and then iterate until we either
find a match or are back at the buffer where we started.
This fixes https://savannah.gnu.org/bugs/?53970.
Signed-off-by: Marco Diego Aurélio Mesquita <address@hidden>
The two help lines will be redrawn in main() only when the current
menu is not MMAIN. So, set it to MLINTER as soon as the help lines
are cleared, just before preparing to invoke the linter.
This fixes https://savannah.gnu.org/bugs/?53967.
Reported-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
Recognize not just "Makefile" but also "makefile" and "GNUmakefile".
And recognize these only when they are the full filenames, not when
they are the tail part of a longer name.
Signed-off-by: Cristian Caloghera <cristi.caloghera@gmail.com>
When executing a command in the current buffer and piping this buffer
(or marked region) to that command, then the cutting of the existing
text and the insertion of the new text should be undone and redone
together, as to the user they appear as a single operation.
With-help-from: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
In the past, the argument could be either a regex or a literal string,
so the wording was kind of vague. But nowadays we can count on having
regex support (through gnulib), so be more precise in the description.
Since version 2.8.0, nano will use (wnen needed) the regex routines
from gnulib, so mentioning the quotestr for when regex support is
lacking, has been obsolete and pointless for more than a year.
Also, remove some superfluous backslashes, use a non-breaking space
in the texinfo document, and order the regex consistently.
If the edit window consists of a single row, then the do_up() call has
already brought the desired line into view -- which means that trying
to scroll then (when already on the first line of the file) would fail.
This fixes https://savannah.gnu.org/bugs/?53891.
Letters in other scripts than English often consist of multiple bytes.
When in a UTF-8 locale, correctly gather these bytes from the input and
put them together as the single letter that they are, before comparing
this letter against the translated "Yy", "Nn" and "Aa" strings.
The tiny version contains much less code, so is less likely
to crash. And the users most likely use it for very simple
and short editing jobs, making the chance of a crash still
smaller. So the handler would just be bloat.
When 'afterends' is set and Ctrl+Right or Shift+Ctrl+Right is pressed,
nano will stop at the ends of words instead of their beginnings.
Signed-off-by: Mark-Weston <markweston@cock.li>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Upon a segmentation fault or an abort signal, instead of crashing,
losing all changes, and leaving the terminal in curses mode, nano
now calls die(), to save any changed buffers and to restore the
terminal to a usable state.
For the remote chance that nano segfaults in die(), the handler for
SIGSEGV and for SIGABRT is reset to its default value as soon as the
signal fires, to prevent a crash-handler loop.
Since a core dump is usually more helpful for debugging, the crash
handler is not included in a debug build.
This addresses https://savannah.gnu.org/patch/?9623.
Signed-off-by: Devin Hussey <husseydevin@gmail.com>
Also, add a period after the "Read nn lines" message, and
don't let the next shell prompt overwrite this message.
This addresses https://savannah.gnu.org/bugs/?53779.
This makes the names of these bindable functions equal to the names of
their corresponding options -- like for all the other toggles that have
a corresponding option.
Set the NO_NEWLINES flag to achieve this. And move the saving and
restoring of the global flags to the main speller routine, so the
flags aren't saved and restored for each internal spell fix.
This fixes https://savannah.gnu.org/bugs/?53742.
Acked-by: David Lawrence Ramsey <pooka109@gmail.com>
When the cursor is on the top or bottom line of the edit window, and
an <Up> or <Down> pushes the cursor offscreen, then use edit_scroll()
to bring it back into view, instead of using edit_redraw(), because
the latter would redraw *every row* on the screen, which is a waste
of time.
This addresses https://savannah.gnu.org/bugs/?53562.
Reported-by: Devin Hussey <husseydevin@gmail.com>
Bug existed since commit 30fc197b (a month ago) which changed the
type of 'i' from int to size_t, causing the comparison to do the
wrong thing when 'threshold' is negative.
This fixes https://savannah.gnu.org/bugs/?53722.
Reported-by: Devin Hussey <husseydevin@gmail.com>
The formatter or linter might have changed in the meantime -- when
the filename was changed to have a different extension, for example.
This fixes https://savannah.gnu.org/bugs/?53716.
When the keyboard buffer is empty, return a value that is not equivalent
to <Ctrl+Space>, so that typing a bunch of these while searching is going
on will not result in some of them getting executed afterward.
Indenting/unindenting always happens in a single contiguous block.
Lines that cannot or should not be indented or unindented do not
need to remembered separately as it follows from their content.
That is, do not fall back to the default background color when the
name for the background color is invalid, but reject the entire
color command, just like for an invalid foreground color.
In the preceding commit, open_buffer() was changed so that it gets
told whether to load into a new buffer or not, so it is no longer
needed to convey this information through a flag.
This fixes a regression introduced by commit 54103d8e: a crash that
can be triggered by running 'nano --restrict' and pressing <Insert>.
This addresses https://bugzilla.redhat.com/1558532.
When the file has just been read, it is in the state that it has
on disk, so there is nothing to undo.
This fixes https://savannah.gnu.org/bugs/?53387.
When the cursor is on the first or last row of the edit window, and
thus Scroll-Down or Scroll-Up would push it offscreen, first move
the cursor away from the edge row and then scroll.
This fixes https://savannah.gnu.org/bugs/?53376.
As, since commit 0e30177d, the scrollup and scrolldown commands
no longer intend to move the cursor, they should not be seen as
movement functions.
Also, it is not guaranteed that functions are ordered in the same
way in the binary as in the source code, so an ordered comparison
of function pointers will not always work.
This fixes https://savannah.gnu.org/bugs/?53333.
When just scrolling and the cursor does not need to change position
(that is: it is not on the first or last row of the edit window),
then edit_scroll() has handled everything and there is no need to
additionally redraw anything or update 'placewewant'.
Instead of keeping the cursor in the same spot on the screen,
let the cursor move with the text (whenever possible).
This makes these functions behave the same as in Vim and Emacs.
Help texts are shown without any line numbers, so the full width
of the screen should be used to display the text.
This fixes https://savannah.gnu.org/bugs/?53308.
First the two that add something (ADD, ENTER), then the three that
delete something (BACK, DEL, JOIN), and then the one that changes
something (REPLACE). Then the SPLITs, CUT, PASTE, and INSERT, and
then the INDENTs and COMMENTs, when they exist.
For cuts, pastes, and inserts, the lines have already been renumbered;
for indents, comments, and replacements, the line numbers cannot have
changed. (And anyway, variable 'f' is not set for those cases.)
Only when lines get split (ENTER) or fused together (JOIN) do the later
lines need to be renumbered. This mirrors what is done for do_redo().
The 'f' variable is used only in the ADD, BACK, DEL, ENTER, JOIN, and
REPLACE undo/redo cases. So, avoid making a somewhat costly call when
it is entirely superfluous. Rearrange the undo types to make checking
for the above six types easier.
This assumes that all movement functions are located together,
starting with to_first_line() and ending with do_right().
This fixes https://savannah.gnu.org/bugs/?53195.
Reported-by: Brand Huntsman <alpha@qzx.com>
The implant() function itself cannot be bound to anything, so it
is not in the linked list of functions -- trying to find it would
lead to a NULL pointer, and thus to a segfault.
This fixes https://savannah.gnu.org/bugs/?53233.
Instead of always calling sctofunc(), it is now only called when
in view mode OR when (after the keystroke's function has been run)
no need for a refresh has been established yet.
Commit bb667beb removed do_gotolinecolumn_void() from the MWHEREIS
menu (replacing it with the empty flip_goto() function), so there
is no longer any need to check for this one special case.
The slash is easier to read than the underscore (which almost
disappears at the bottom of the screen), and easier to type
(no Shift needed on a US keyboard), and it kind of harmonizes
with the ^\ for Replace and the M-/ for End-of-buffer.
When using --smooth or 'set smooth', the screen should scroll the
minimum amount needed to get the cursor back into view. (The only
exceptions are search, undo, and redo -- when there the cursor goes
offscreen, the cursor line is centered.)
This change brings the behavior of pressing <Enter> on the bottom
row into line with, for example, pasting a single line. See also
http://lists.gnu.org/archive/html/nano-devel/2018-02/msg00027.html.
When 'refresh_needed' is already TRUE, there is no need any more
to check whether it should be set.
[Those first two calls are leftovers from before the time that
reset_multis() morphed into check_the_multis().]
When characters are added via Verbatim Input or by pressing <Tab>,
the prepend flag should be retained, just like when characters are
typed directly.
This fixes https://savannah.gnu.org/bugs/?52956.
When copying a string, source and destination may not be equal --
complain loudly when they are, instead of failing to free memory.
Also, instead of freeing the destination string and then allocating
it afresh, just reallocate it -- that should be slightly quicker.
When doing for example: ^W xx ^R ^C ^W, the "xx" would again be shown
after the prompt. This is wrong -- when starting a new search, the
current answer should be empty.
Reported-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
Instead of weaving back and forth between do_search()/do_replace() and
search_init() every time that one of the options is toggled, just keep
looping in the latter function until the user presses <Enter>.
The weaving for the do_gotolinecolumn() function remains, but is
shortened to involve only search_init().
In this way a single keystroke can produce a fragment of text or a
series of commands, or a mix of the two. It is like a prerecorded
macro.
This fulfills https://savannah.gnu.org/bugs/?52931.
When a fragment of help text does not contain any whitespace that
we can wrap at, just advance the pointer, because returning zero
would mean we stay forever at the same place: nano would hang.
Instead of assuming that the entire contents of the keybuffer are an
escape sequence (even if this is far longer than any escape sequence
can be), remove from the keybuffer only those integers that actually
constituted a sequence, valid or invalid.
This fixes https://savannah.gnu.org/bugs/?48659.
Trimming trailing spaces is good, but we should not trim the space
(or tab or other blank) that the user just typed and that caused the
hard-wrapping to occur.
This fixes https://savannah.gnu.org/bugs/?52948.
Reported-by: Andreas Schamanek <schamane@fam.tuwien.ac.at>
The verbosity "hid" the really relevant information:
filename, line number, and the error message.
Valid values and other details can be found in the manual pages.
When the palette is getting initialized, it is too late to send any
error messages about the rcfile options to standard error.
This fixes https://savannah.gnu.org/bugs/?52871.
Reported-by: Brand Huntsman <alpha@qzx.com>
Signed-off-by: Brand Huntsman <alpha@qzx.com>
When we're just searching, we do want to report the occurrence at
the cursor (after coming full circle) as a match, so that we can
mention that this is the only occurrence. When replacing, we do
not want to replace this match twice.
This fixes https://savannah.gnu.org/bugs/?52888.
There shouldn't be two separate variables (but with the same name) that
count the number of digits seen. Fuse them into a single static var.
This fixes https://savannah.gnu.org/bugs/?52863.
The tabsize can vary by configuring editor or viewer, but
the text has some kind of intended alignment.
Also, change the indentation a bit, to make things line up
more neatly.
The fragment "\<\." can never match anything because \< matches the
beginning of a word but "." is not a word character.
Replace \< with \B (the empty string not at the edge of a word).
Signed-off-by: Tom Levy <tomlevy93@gmail.com>
The list now includes all the Lua 5.3 functions listed on
https://www.lua.org/manual/5.3/#index.
Also, remove the coloring of just the library name, so that
only known library functions get highlighted.
Signed-off-by: Tom Levy <tomlevy93@gmail.com>
Since a "0x" by itself is invalid. Also add word boundaries, so that
e.g. "00x1" (which is invalid) does not get partial highlighting.
Also remove some redundant backslashes from the strings regex.
Signed-off-by: Tom Levy <tomlevy93@gmail.com>
Each leading tab is converted to two tabs, and any leading four spaces
is converted to one tab. The intended tab size (for keeping most lines
within 80 columns) is now four.
When unindenting/uncommenting affected the bottom line of the marked
region, keep affecting this line also during subsequent consecutive
indenting/commenting.
This fixes https://savannah.gnu.org/bugs/?52718.
Functions such as "io.close" should only be highlighted when the
package name ("io") is a word by itself, otherwise code such as
"fooio.close" gets unexpected partial highlighting.
Signed-off-by: Tom Levy <tomlevy93@gmail.com>
Also, remove the coloring of special single-quoted strings as they
get recolored by the subsequent general string-coloring command.
And remove the coloring of all-uppercase words, as other editors
do not color those either.
If the marked region ends at the start of a line, do not include that
line in the indenting/undenting or commenting/uncommenting. This is
closer to what the eye would expect.
Unset the "Modified" marker only at the point where the file was last
saved -- if there is such a point, because it can be missing when the
undo stack was discarded.
This fixes https://savannah.gnu.org/bugs/?52689.
Reported-by: Liu Hao <lh_mouse@126.com>
Original-idea-by: Brand Huntsman <alpha@qzx.com>
The function get_keycode() should never return zero -- it should
return either the code from ncurses or the given fallback code.
This fixes https://savannah.gnu.org/bugs/?52682.
When the mark is on, instead of letting a <Tab> simply insert a Tab
character at the cursor position, let it indent the marked region.
Original-idea-by: Chris Allegretta <chrisa@asty.org>
And also allow it when lines are only partially indented.
This makes it possible to equalize the indentations of (accidentally)
unevenly indented lines: by first fully unindenting a group of lines,
and then reindenting them to the desired amount.
Suggested-by: Liu Hao <lh_mouse@126.com>
In this way we can delete things on the current line with ^K (after
Shift-selecting some text) without nano misdetecting a line change,
This fully fixes https://savannah.gnu.org/bugs/?52576.
Only when the cursor has moved off of the currrent line do we stop
prepending wrapped words to the next line.
This partially fixes https://savannah.gnu.org/bugs/?52576.
It's better to color some invalid things as if valid than the other
way around. So, as strings can validly contain any number of double
quotes, just accept *anything* between the delimiting double quotes
and demand that the closing quote is followed by whitespace or EOL.
When the WAS_FINAL_LINE flag is relevant (when NO_NEWLINES isn't set),
the only way for 'current' to be equal to 'filebot' is when 'current_x'
is zero.
When some or all edits have been undone, and the user starts to make
new edits, the old part of the undo stack is discarded, but this does
not mean that the undo stack doesn't go back to the very beginning.
This really fixes https://savannah.gnu.org/bugs/?52504.
On a freshly installed system, or for a new user, the default
XDG data directory may not exist yet. So, create it when not.
Reported-by: Brand Huntsman <alpha@qzx.com>
The softmark is now only cancelled when the cursor is moved without
Shift being held, not for things like ^L (Refresh), ^C (Position),
or ^G (Help).
This addresses https://savannah.gnu.org/bugs/?52470.
When a file is closed with the cursor on line 1, column 1, this
position is not recorded in file-positions history file -- if a
record for the file existed, it is deleted. In the latter case
the history file needs to be saved, so that other instances of
nano will know about the deletion.
This fixes https://savannah.gnu.org/bugs/?52505.
The pointer not being NULL is enough indication that the mark is set.
Also, rename the pointer from 'mark_begin' to simply 'mark', since
the former is kind of pleonastic.
Because the highlighting hinders the display of affected lines,
and, more importantly, only the highlighted part would be written
if the file was modified and the user answers yes to the "Save?"
prompt.
This fixes https://savannah.gnu.org/bugs/?52474.
Since file-5.10 (end of 2011), libmagic identifies a C file in most
cases as "C source" instead of as "C program". Nano's magic strings
for some other files didn't match any more what file-5.32 currently
produces, either. So, they have been adjusted, new ones added, and
old ones deleted.
This fixes https://savannah.gnu.org/bugs/?52445.
Adding the obscure A_PROTECT attribute to every color prevents an
occasional miscoloring of the first few rows on the screen -- when
ncurses is version 6.0 and dates from before October 17, 2015.
Original-idea-by: Brand Huntsman <alpha@qzx.com>
Tested-by: Brand Huntsman <alpha@qzx.com>
This fixes https://savannah.gnu.org/bugs/?52182.
When there are no help lines, there won't be any call to update the
actual contents of the bottom window, so... do it immediately after
blanking the row.
This fixes https://savannah.gnu.org/bugs/?52377.
Whenever a buffer is closed, check whether the positions file on disk
was modified, and if so, reload it. Then update the position for the
closed buffer and write out the positions file to disk.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The function get_key_buffer() assumes waiting_mode = TRUE, but stdin
can be in non-blocking mode when a program (before nano) turned stdin
to non-blocking mode and did not change it back (possibly because it
crashed). So, explicitly set stdin to blocking mode at startup.
Signed-off-by: Lion Yang <lion@aosc.io>
When not finding a .nanorc file in the user's home directory, nano will
look for a nanorc file in $XDG_CONFIG_HOME and in the ~/.config/nano/
fallback directory. And when not finding a .nano/ subdir in the user's
home directory, nano will look for (or create) the history files in
$XDG_DATA_HOME or in the ~/.local/share/nano/ fallback directory.
This is a partial implementation of the XDG Base Directory Specification:
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html,
for the purpose of reducing the clutter in a user's home directory, and
to make it easier to back up just the configuration files.
Signed-off-by: Simon Ochsenreither <simon@ochsenreither.de>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
If the user uses a single version of nano, they have no need for
--quiet. If they do sometimes use an older version and don't want
to see the warnings, they can use 2>/dev/null (they could make an
alias for that and put it before the call of nano).
Initialize 'breaking_col' to what it needs to be when the current chunk
consists of only a tab -- a tab that spreads across both start and end
of the chunk -- so that the last 'if' can move into the preceding one,
which allows the elision of 'char_len'.
In the tiny version, do_prompt() will now have an extra NULL
parameter, which will cost maybe twenty extra bytes of code.
That is acceptable when it saves thirty lines in the source.
The key sequence ^R ^X M-F <Enter> would cause nano to abort, because
it would try to add an empty string to a history list. (Furthermore,
simply don't execute an empty command, because it is pointless.)
Reported-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
After any replacements were made, the "not found" message is pointless
because it will be overwritten rightaway by "Replaced xx occurrences".
The message is confusing and annoying when using speech output.
This partially fixes https://savannah.gnu.org/bugs/?52282.
Reported-by: Chime Hart <chime@hubert-humphrey.com>
List "browser", "pageup" and "pagedown" in the manuals; the first
because it matches "speller", and the latter two because they are
what these functions are commonly known by. The names "tofiles",
"prevpage" and "nextpage" are now undocumented, but they are still
recognized by the code, as they match the tags for these functions.
Most people who make use of 'do_findprevious' and 'do_findnext'
will not make use of 'do_search' (the default binding of M-W),
so for them it is superfluous to remember the state of the
Backwards toggle in the Search menu. For the people that do
mix the usage of Alt+Up/Down with M-W, it means that M-W will
always search in the same direction as the last search. It is
a small change in behavior.
Allow the user to record and run a single macro. The default binding
for starting and stopping the recording is M-: (Alt + colon) and for
running the macro M-; (Alt + semicolon).
This fulfills https://savannah.gnu.org/bugs/?50314.
Requested-by: Peter Passchier <peter@passchier.net>
Signed-off-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
^S will be the first thing people will try for saving a file,
and ^Q is somewhat mnemonic because it is to the left of ^W:
it searches backward.
Make these keystrokes available also in the tiny version.
Before writing a file out, nano should check that the file on disk
hasn't been modified since it was read -- not only for the normal
"Write Out" action (^O), but also for "Save File" (future ^S) and
for "Save and Exit" (^X when --tempfile is used).
When writing fails and --tempfile is in effect, don't go on to prompt
for a file name; instead let the user decide what she wants to do.
This fixes https://savannah.gnu.org/bugs/?51040.
Signed-off-by: Viorel Bota <botaviorel@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Date and version are updated to match each release, so the user does
not have to wonder whether the man page really describes the binary.
Also remove a bit of superfluous markup.
When we've landed on a tab and we are moving down and the tab starts
before the current chunk, then push the index forward -- otherwise we
would not advance. When instead we're moving up and the end of the
preceding row is on the same tab as the target column AND the end of
the current row is not on that same tab, then there is some character
on this row that we can put the cursor on, so push the index forward
-- otherwise we would skip a usable row.
This fixes https://savannah.gnu.org/bugs/?52125
and fixes https://savannah.gnu.org/bugs/?52139.
The recent migration of the history routines forgot to add the new
file to the list of files from which strings should be extracted.
This fixes https://savannah.gnu.org/bugs/?52122.
In atblanks mode, if a softwrapped chunk ends with a double-width space
character (say, Unicode 003000, Ideographic Space), and that would put
half of the character past the edge of the screen, break before it.
This fixes https://savannah.gnu.org/bugs/?51671.
The basic idea is that the cursor is always off, except when it needs
to be on: when waiting for text input, and in a few other cases: when
something was searched and found in the help viewer, and in the file
browser when option -g is in effect.
This fixes https://savannah.gnu.org/bugs/?51923.
Reported-by: Mike Frysinger <vapier@gentoo.org>
When reducing the search string to at most half the screen width,
it should employ its width in columns, not its length in bytes.
Also adjust the type of a variable.
This fixes http://savannah.gnu.org/bugs/?52057.
The functions to read and write history files will not even be called
when the home directory is missing, so there is no need to check for
that eventuality again.
Populating the search, replace, and execute lists makes use of the
function update_history() which sets history_changed to TRUE, which
meant that the search_history file would always get written even if
nothing had changed.
When multiple files were open and [x/n] was being shown in the title
bar, don't show nano's name and version number when just one buffer
remains open, but show [1/1] instead. It is less surprising.
When multiple buffers are open, replace nano's name and version number
with an indication how many buffers are open preceded by the sequence
number of the current buffer.
Signed-off-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
This is modeled after the comment/uncomment code. Each line's
individual indent is saved in the string array of the undo
group structure.
This fixes http://savannah.gnu.org/bugs/?46860.
The function does not contain any comment-specific code, so it can
be used to handle any kind of multiline undo item.
Also, extend the undo group structure to contain an array of strings,
one for each line in the group. When indent/unindent is hooked up to
the undo/redo code, this will allow the latter to restore the exact
original indents.
Also, remove an unneeded null_at() -- the null byte has been copied,
and reallocating the string would recover very little memory.
Also, call charmove() without using the & operator.
This is modeled after the undo/redo code for commenting. do_indent() now
calls indent_a_line() on each line it covers. The latter function will
eventually be used by the undo/redo code.
When moving the cursor to the top-left corner, it is not necessary
to compute leftedge because firstcolumn IS the relevant leftedge.
Reported-by: Jordi Mallach <jordi@debian.org>
When the screen is narrower than a tab is wide, the cursor does not need
to be on the first/last line of the window before an <Up>/<Down> could
need to scroll the screen.
This fixes http://savannah.gnu.org/bugs/?51776.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Check the column number, not the character index, when suppressing the
line number on chunks other than the first, since the index can be zero
when in fact we're on a later chunk.
This fixes https://savannah.gnu.org/bugs/index.php?51790.
Using do_up() and do_end() when the user types <Left> at the start of
a line, and do_down() and do_home() when typing <Right> at line's end
can be problematic when tabs are wider than the screen, because those
functions convert indexes to columns and back again twice, thus causing
inaccuracies. Therefore, simply adjust current and current_x directly,
and then redraw the screen.
This fixes https://savannah.gnu.org/bugs/index.php?51778.
The preceding 'for' loop has already established that all the lines are
either unindentable or composed of only blanks. So if now a line cannot
be unindented, it means it is fully blank, so it can be simply skipped.
This fixes https://savannah.gnu.org/bugs/?51760.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Also, only unindent when all selected lines can be unindented,
which means that the relative indentation will be preserved.
For this purpose, it ignores empty lines and lines consisting
of only whitespace.
When unindenting is not possible, a message is shown.
This fixes https://savannah.gnu.org/bugs/?47684.
Instead of inserting the extra whitespace after the current indentation
of a line, add it to the start of the line. This causes a fixed amount
of visual whitespace to be added regardless of whether --tabstospaces
is used or not.
This fixes http://savannah.gnu.org/bugs/?51438,
and its ancestor https://savannah.gnu.org/bugs/?51408.
So that these functions have bindings by default, and easy bindings.
Add them to the help viewer too, so that searching backward becomes
possible there.
Tabs are of variable length depending on position, so allow them
to be displayed partially on one chunk and partially on another.
This fixes http://savannah.gnu.org/bugs/?51621.
Adding text plus whitespace while the cursor is at or near the topleft
corner of the edit window can cause a change in the preceding chunk,
throwing firstcolumn out of alignment. Catch this special case.
This fixes http://savannah.gnu.org/bugs/?51743.
It would be horrible if the user expects to find numbered backups
of all the files that were changed but they are NOT there because
the config file contains a typo or the relevant directory was moved
or renamed or something. So... if the specified backup directory
is not usable, nano should complain and simply not start up.
Discarding (in commit 6f9bb53b) the cap on the number of chunks to
move backwards had as an unforeseen side effect that the screen can
fail to scroll when the cursor is somehow pushed offscreen.
Fix this by setting the target row (for smooth scrolling) always to
the bottom row of the edit window when nano notices that the cursor
has gone offscreen.
This fixes https://savannah.gnu.org/bugs/?51676.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
The succeeding character was needed to avoid miscolorings due to nano
getting confused about starts and ends. But since commit 7ef5c532,
nano should be getting the starts and ends always right, so... undo
"temporary" commit 7b2ea405 from two years ago.
This addresses https://savannah.gnu.org/bugs/?51526.
Reported-by: <exodus6395@googlemail.com>
The new option 'set selectedcolor' applies to marked text, to the
currently selected file in the file browser, and to the highlighted
match during interactive search-and-replace.
Include the shortcut for 'Uncut' into most menus, and add an uncut
function for the status bar, so that it becomes possible to paste
the first line of the cutbuffer at any text-input prompt.
This fulfills https://savannah.gnu.org/bugs/?48501.
Requested-by: Benno Schulenberg <bensberg@telfort.nl>
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Assume that a linter line that contains an actual error message or
warning includes a colon followed by a space -- something that that
opening message from a modern gcc lacks.
Human column numbers are one-based, whereas x positions are zero-based.
Converting from the one to the other involves subtracting one. But when
the linter message does not provide a column number, the latter defaults
to zero. Catch that case and change the number to one.
This fixes https://savannah.gnu.org/bugs/?51550.
Commit 28beb3f added the 'forreal' parameter to prevent spotlight() from
placing the cursor wrongly due to an invalid placewewant. However, since
the variable-width softwrap overhaul (specifically, since commit 8490f4a),
place_the_cursor() no longer checks placewewant, so the parameter is no
longer needed.
Furthermore, dropping 'forreal' and thus always setting current_y won't
affect the operation of spotlight(), since the only functions that use
spotlight() (do_replace_loop() and do_int_spell_fix()) both call
edit_refresh() beforehand, which means that current_y will already
have been set to the value it will be set to again.
The function place_the_cursor() assumes that the viewport is up to date,
i.e., that current is in range of edittop. When uncutting or inserting,
however, place_the_cursor() gets called on the out-of-date viewport
first, and then a screen refresh is scheduled (which would put the
viewport up to date). This is backwards: the refresh should come before
the cursor placement, and the only reason it works anyway is because the
cap on the number of chunks to move backward papers over the problem by
keeping current_y in screen range regardless.
Fix this properly by simply setting current_y to the bottom row of the
screen instead of calling place_the_cursor(). This value of current_y
is only ever used when in smooth scrolling mode and the insertion (or
paste) pushed the cursor offscreen. In other situations, this value is
overridden when place_the_cursor() gets called after a screen refresh.
After that fix, the cap on the number of chunks to move backward is no
longer needed.
When not using --smooth (nor 'set smooth'), and a line near or beyond
the end-of-file is addressed with the + command-line argument, then
center the cursor, just like Pico does -- so in the default mode,
nano is again more like Pico.
This partially addresses https://savannah.gnu.org/bugs/?51489.
Counting the added number of rows is only relevant when inserting
a file into the current buffer. So don't waste time counting when
it's not needed.
This fixes https://savannah.gnu.org/bugs/?51479.
Since commit 8490f4ac, get_edge_and_target() depends on an up-to-date
current_x. So: make sure current_x is updated when we move to the
top left of the screen to start a non-smooth PageUp or PageDown.
This fixes https://savannah.gnu.org/bugs/?51480.
For some reason, when returning from suspension, SLang will produce
either a clipped error code (0xFF instead of 0xFFFF, when returning
from an externally induced suspension), or it will clip the code of
first subsequent keystroke to a single byte (when returning from a
normal, in-editor suspension: ^Z).
Side-step this by ignoring the clipped error code, and by using an
undefined control code as the first fake keystroke. Ignoring the
clipped error code is not possible when using a single-byte locale,
otherwise the user would not be able to type the character with
code 0xFF (although it could still be entered with Esc Esc 255).
This fixes https://savannah.gnu.org/bugs/?51477.
The help lines need to be redrawn one step after a justification
(whether it has been undone or not, to replace "Unjustify" with
"Uncut" again for ^U), and after switching buffers (to update a
possibly changed tag for ^T).
This fixes https://savannah.gnu.org/bugs/?51455.
The parameter 'cols', that indicates how many columns to indent or
unindent, is changed to be always positive, so the check for being
negative can go. And it could never be zero anyway.
This should eliminate all cases where the newline is pushed off the edge
of the screen in non-atblanks softwrap mode. Also, it allows the use of
the last column of the screen in atblanks softwrap mode when a piece of
text does not contain any blanks.
This avoids the unreachable end-of-line reported on the mailing list:
http://lists.gnu.org/archive/html/nano-devel/2017-06/msg00011.html.
Extend get_softwrap_breakpoint() to break softwrapped lines on
whitespace when a flag is set. This flag is controlled by the new
rcfile option "atblanks". The '>' characters marking two-column
characters at the edge of the screen are disabled when it's on.
If get_softwrap_breakpoint() can't find whitespace in screen range, it
will break the line on the screen edge. (In this case, a blank can be
on the last column of the screen, but text can't, so that a blank on the
last column doesn't become invisible and possibly break the display.)
This fulfills https://savannah.gnu.org/bugs/index.php?49959.
Requested-by: Nicholas Boel <axxisd@gmail.com>
spotlight() now displays softwrapped lines chunk by chunk instead of all
at once. Since softwrapped lines are no longer of constant width, the
latter approach would fail if softwrapping breaks the spotlighted text.
Instead of taking a string, spotlight() now takes the starting and ending
columns of that string. Also, its handling of softwrapped lines is now
split off into a separate function, spotlight_softwrapped().
get_chunk_row() and get_chunk_leftedge() now become wrappers around
get_chunk(); the latter is only used directly in place_the_cursor()
when we need to get both the row and the leftedge. get_chunk() now
uses the proper formula to implement varying chunk width.
Since chunk width now varies, place_the_cursor() sets the x position
relative to the leftedge in a different way that works regardless
of chunk width, update_softwrapped_line() loops until it gets all
softwrap breakpoints instead of calculating the full length in
advance and getting one full row at a time, the chunk iterators
now count leftedges instead of rows, and fix_firstcolumn() does a
full recalculation of the chunk that firstcolumn is on instead of
simply shifting it back.
Also, in update_softwrapped_line(), when a line's softwrap breakpoint
is before the last column of the edit window, a ">" is now added to
the end of it.
The workaround in place_the_cursor() for when two-column characters
straddle the edge of the screen is removed, as it's no longer needed
now that chunks end before such characters.
Furthermore, do_home() and do_end() use xplustabs() instead of
placewewant again when calculating the leftedge, since placewewant
refers to a column that may or may not be available (if it's not,
the cursor will be placed wrongly). Make get_edge_and_target() use
xplustabs() instead of placewewant for the same reason; this also lets
us simplify get_edge_and_target(), since xplustabs() will never be
greater than strlenpt(). Finally, since do_end() now has to calculate
rightedge as well as rightedge_x, use the former to implement the same
time-saving optimizations as in do_home().
The cursor is not yet adjusted when we try to go directly to a column
past the end of a softwrap breakpoint, and placewewant handling in the
vertical movement code is not yet adjusted for varying chunk lengths,
but fixes for these are forthcoming.
This fixes https://savannah.gnu.org/bugs/?49440.
get_chunk_row() replaces the formula "column / editwincols".
get_chunk_leftedge() replaces "(column / editwincols) * editwincols".
get_last_chunk_row() replaces "strlenpt() / editwincols".
get_last_chunk_leftedge() replaces "(strlenpt() / editwincols) * editwincols".
This prepares us for any changes in those formulas, and for more such
functions later.
The new function find_softwrap_breakpoint() returns the column number
of the last position in screen range where we can wrap the given text
without breaking a two-column character in half (as was done until now).
The returned column number is the leftedge of the next softwrapped chunk.
If the end of the text is reached while searching for a wrapping point,
the parameter end_of_line is set to TRUE.
The new function get_chunk() uses find_softwrap_breakpoint() to find the
row and leftedge corresponding to a given column of a given line.
Eradicate the need for backslashes, so that the start of the nanorc
manual becomes true, where it says that quotes inside strings don't
need to be escaped. In the bargain achieve that the empty string
always switches commenting off.
This fixes https://savannah.gnu.org/bugs/?51370,
and fixes https://savannah.gnu.org/bugs/?51394.
This avoids some warnings when compiled with -pedantic:
ISO C forbids comparison of ‘void *’ with function pointer
ISO C forbids empty initializer braces
When the active syntax contains a comment command that specifies the
empty string, this should override the default comment of "#" and
should disable the Meta-3 keystroke.
To achieve this, the comment string is now set by default to "#" for
all syntaxes, so that it will be set when no comment command is given
(including for the "none" syntax), and is unset only by explicitly
specifying «comment ""» in a syntax file.
This fixes https://savannah.gnu.org/bugs/?51355.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
When also --nohelp is active and the terminal is so narrow that the
message that --constantshow displays on the bottom row does not fit,
this causes the cursor to be pushed "offscreen". Some terminal
emulators don't handle this case correctly, and leave the cursor
in an invisible or mistaken position. Compensate for this by
moving the cursor back to the start of the row.
This fixes https://savannah.gnu.org/bugs/?51335.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
The extra variable is not needed, because when having read from
standard input, the filename will simply be empty. It will not
be empty for any other file that was read.
The dash doesn't have to be the first non-option argument: it can
be anywhere among the filenames -- there can even be multiple ones
(but don't mention this explicitly).
Negative arguments of 'fill' are bright green since a few commits.
So now color all valid numeric arguments in that same style -- the
yellow was hard to see on a dark background anyway.
Also, color a zero tabsize as invalid.
A recent change (8dffb00f) removed this ability. This change restores
it, and also allows reading from standard input multiple times -- maybe
not useful, but it works.
Also when a dash is the first "file" mentioned on the command line,
nano should show this buffer at startup and not the next.
This fixes https://savannah.gnu.org/bugs/?51207.
In the tiny version, Ctrl+Left and Ctrl+Right are available only
in the editor itself and in the file browser.
This fixes https://savannah.gnu.org/bugs/?51173.
The old praxis of calling total_refresh() upon a SIGCONT was confusing,
because the screen would look as if nano had returned from suspension,
but in fact the shell was still active.
Instead of calling total_refresh(), put a no-op key into ncurses' buffer,
so that, when nano actually does return out of suspension (through 'fg'),
this key will be read and discarded, upon which nano will go sit and wait
for the next key, just before which it calls doupdate(). The latter is
all we need to get the entire screen restored.
This also fixes https://savannah.gnu.org/bugs/?51131 for "tiny".
When receiving a SIGCONT, don't call regenerate_screen() directly
but act as if a SIGWINCH occurred. Also insert a dummy key, and
thus let the relevant input routine redraw the relevant subwindows.
Use KEY_F0 as the dummy key, as both Ncurses and Slang know it, and
it should normally do nothing at all.
This fixes https://savannah.gnu.org/bugs/?51124.
When we are in the file browser, browser_refresh() will take care of
redrawing the title bar and the file list, so total_refresh() should
leave those two subwindows alone in that case.
This fixes https://savannah.gnu.org/bugs/?51147.
Achieve this by making the suppression flag global, so that we can
just reset it instead of making an improper call of do_cursorpos().
This fixes the secondary part of https://savannah.gnu.org/bugs/?51134.
It is no longer necessary to assign up() and down() separately for
the help viewer because by now the movement keys have been sorted
in order of ascending stride also in the main menu.
The two string definitions are relocated just to reduce the number
of #ifdefs.
Most of the keywords listed on the following URL are now highlighted:
http://php.net/manual/en/reserved.keywords.php
Also color single-quoted strings, and require that //-type comments
are preceded by whitespace or are alone on a line.
With-feedback-from: M <taur@mail.com>
When spotlighting the string to be replaced, placewewant isn't valid,
so tell place_the_cursor() to ignore its value to avoid the cursor
getting mistakenly placed at the beginning of the next row.
This fixes https://savannah.gnu.org/bugs/?50997.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
When the column given in gotoline() is beyond the last available
column in the row of the last chunk, then set placewewant to the
actual end of the chunk, to prevent surprising jumps to the left
when moving up or down from there.
This fixes https://savannah.gnu.org/bugs/?50995.
Whenever 'make' is run, it should check whether the revision has
changed, and if so, it should update src/revision.h.
This portable FORCE mechanism should have been the replacement for
the phony target that was removed in a33a4f00, five commits ago.
This fixes https://savannah.gnu.org/bugs/?50956 in a better way.
Instead of always stepping back four bytes and then tentatively
moving forward again (which is wasteful when most codes are just
one or two bytes long), inspect the preceding bytes one by one
and begin the move forward at the first valid starter byte.
This reduces the backwards searching time by close to 40 percent.
Also when toggling the help lines back on or the extra editing space
back off, keep the cursor near the bottom of the screen if it /was/
there, instead of centering it -- if smooth scrolling is on, that is.
This supplements the fix for https://savannah.gnu.org/bugs/?50933.
When the editing space gets narrower, either by toggling line numbers on
or making nano's window smaller, and when the cursor is near the bottom,
it can be pushed offscreen. In that case, don't get it back onscreen by
centering the current line but by putting it on the bottom row. This
makes for a smoother experience.
This fixes http://savannah.gnu.org/bugs/?50933.
And hide the cursor again as soon as the user scrolls.
Achieve this through making the 'didfind' variable global.
Also, remove a superfluous call of wnoutrefresh(), as bottombars()
already does that.
This fixes https://savannah.gnu.org/bugs/?50918.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
The bottomwin has just been refreshed by update_the_statusbar(),
and it should not be the responsibility of the prompt routines
to keep the edit window up to date, as they don't write anything
there.
Things have morphed over time and display_buffer() no longer actually
displays the buffer -- it just displays the title bar, precalculates
the multiline color info, and schedules a refresh of the edit window.
If the length of the haystack is smaller than the length of the needle,
this means that also the length of the tail will be smaller -- because
pointer will be bigger than or equal to haystack -- so the pointer gets
readjusted to be a needle length before the end of the haystack, which
means that it ends up /before/ the haystack: thus the while loop will
never run.
On average, this saves some 200 nanoseconds per line.
This avoids https://savannah.gnu.org/bugs/?49912 while at the same time
avoiding to draw the edit window twice in a row -- the first drawing
would use a wrong margin, which results in a visible and irritating
shift left or right of the content upon the second drawing.
This fixes https://savannah.gnu.org/bugs/?50877.
We should measure the length of each /translated/ shortcut description,
not of the original English one.
This fixes https://savannah.gnu.org/bugs/?50899.
An iterator should not be called "start_col", because it is only the
starting column at the very beginning.
Also, start_col (after the rename) can never be /larger/ than column.
Since the help text is searchable, an <End> would go to the end of the
text but would leave a blank line above the statusbar -- a blank line
that wasn't there before, and that is not reached when simply holding
down <Down> all the way from the top.
When nano has multiple files open, closing a help buffer should
not switch to the next buffer in the ring but to the preceding one,
because it was from there that the help screen was invoked.
However, prefer moving the starting point of the text backwards over
moving it forward, so that of the same paragraph more text is shown
instead of less. But scroll an empty line out of view -- no text is
"lost" then.
Allow the user to search in a help text with ^W and M-W.
Achieve this by not writing the help text directly to the screen
but first writing it to a temporary file and then opening this file
in a new buffer, and treating it specially: the normal file-reading
feedback is suppressed, the titlebar shows the headline of the text,
the cursor is hidden, and the menu is limited to just the up and down
movements and searching.
This fulfills https://savannah.gnu.org/bugs/?28994.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Call something a buffer when it refers to a linked list of linestructs,
and call something a linestruct when it is a struct that describes a
single line.
File formats, appending and prepending, and backups are not available
when --enable-tiny is used, so prevent all relevant pieces of code from
getting compiled. And correct two misspelled ENABLE_TINY to NANO_TINY.
The cursor needs to be placed in its proper spot in the edit window
/only/ when nano is about to accept input from the user and needs to
show where this input will go.
(This might cause a scrolling issue to appear, because reset_cursor()
does not just place the cursor, it also recomputes current_y, which
is used in several places to determine whether and how much to scroll.
If it so happens, we'll deal with that fallout later.)
This also groups ^I and ^M together, and cutwordleft and cutwordright
(when they are bound). It furthermore makes that less pairs are now
mixed and instead consist of either two Ctrl or two Meta combos. In
short: it looks better in the default config. The only sacrifice is
that Verbatim is now split off from the other "inserting" keys.
When the user chooses not to open a file that some message refers to,
remove all messages for that file from the linting results, so the user
does not get asked about that same file again.
This fixes https://savannah.gnu.org/bugs/?47130.
The interval 2013-2017 for the Free Software Foundation is valid
because in those years there were releases with changes by either
Chris or David, and the GNU maintainers guide advises to mention
a new year in all files of a package, not just in the ones that
actually changed, and be done with it for the rest of the year.
To make dynamic Home and End work properly when double-width characters
straddle a chunk boundary, use the spot where the cursor is really shown
instead of the "actual x" position of the current character, because the
latter might be on the preceding row.
This fixes https://savannah.gnu.org/bugs/?50737.
On some terminal emulators, Ctrl+Home and Ctrl+End produce special
keycodes, distinct from plain Home and End. Make the users of those
emulators (and of the Linux console) glad by making ^Home and ^End
do the obvious thing, and the combinations with Shift too.
When Enter is pressed while the cursor is exactly on the current
indent width, remove the blank characters on that line to avoid
creating a line that consists only of trailing whitespace.
(When Enter is pressed somewhere in the middle of the blanks,
however, the whitespace is preserved.)
Suggested-by: Florian Zeitz <florob@babelmonkeys.de>
When a multi-column character straddles a chunk boundary, and the
preferred column (placewewant) for the cursor is zero, cheat: show
the cursor not where the character starts but on the beginning of
the next row. This makes the cursor move smoothly in the leftmost
column of the screen when using <Up> and <Down> and such, instead
of jumping around.
In this way the scrolling logic won't get confused and the screen
will scroll properly when stepping beyond the top or bottom row.
This fixes https://savannah.gnu.org/bugs/?50687.
If we're using the bundled gnulib regex module, then assume REG_ENHANCED
is not supported (since gnulib doesn't support it).
This fixes https://savannah.gnu.org/bugs/?50714.
When UTF-8 is available, use actual arrows instead of untranslated words
to indicate the cursor keys. This was already done for the combinations
with Ctrl but not yet for the plain cursor keys.
The unshifted shortcuts are easier to type, and also less confusing in
my eyes. Putting them first means they get shown in the help lines,
and get listed first in the ^G help text.
(I would also like to put ^- first instead of ^_ (because the latter
is hard to see when using the default inverse video for shortcuts),
but on several terminal emulators Ctrl+- reduces the font size.)
Use futimens() instead of utime() to change the timestamps on a backup
file. Otherwise, a non-privileged user could create an arbitrary symlink
with the name of the backup file and in this way fool a privileged user
to call utime() on the attacker-chosen file.
Import the relevant gnulib module to make sure futimens() is available.
If we're using the bundled gnulib regex module, then assume word boundary
support is available to avoid issues with the regcomp test. This also
unifies the different code paths a bit.
This fixes https://savannah.gnu.org/bugs/?50705.
If edittop is partially offscreen before we scroll, and it gets
scrolled more offscreen, we do need to compensate for the chunks
between firstcolumn and leftedge -- that is: the chunks between
the top row and the cursor row.
This fixes https://savannah.gnu.org/bugs/?50691.
When a two-column character cannot be shown because it straddles the
boundary between two chunks of a line, show the '>' placeholder for
its left "half", and '<' for its right "half".
This mitigates https://savannah.gnu.org/bugs/?49440.
Remove some things we're never going to do: allowing to replace
newlines, a regression framework, characterset conversions, or
jumping to various screen lines.
The number of rows to draw shouldn't be compensated for the chunks
of edittop that are before firstcolumn, because they are offscreen.
This completes the fix for https://savannah.gnu.org/bugs/?50621.
There is no need to always increase nrows by 1 or 2 -- an increase
of 1 is only needed when the line that borders on the scrolled region
needs to redrawn too: when this line was horizontally scrolled or when
the mark is on.
This fixes https://savannah.gnu.org/bugs/?50621.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
The complementary test on current_y should only be done when doing
a scroll-only, because only then the prior line can be offscreen.
This fixes https://savannah.gnu.org/bugs/?50658.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
When scrolling backward, it is not just the bottom line of the screen
that doesn't need to be redrawn: also the line /before/ the top line
doesn't need a redraw. Mutatis mutandis for scrolling forward.
This fixes https://savannah.gnu.org/bugs/?50657.
When determining the leftedge of the current chunk, it is not simply
the leftedge that corresponds to the placewewant, but the leftedge that
corresponds to the minimum of the placewewant and the full line span.
This fixes https://savannah.gnu.org/bugs/?50653.
When typing PageUp or PageDOwn in non-smooth-scrolling mode, the cursor
should be placed at the start of the top line of the edit window. This
means that, when the line at edittop is partially scrolled offscreen,
the cursor should be placed at openfile->firstcolumn, not at zero.
This fixes https://savannah.gnu.org/bugs/?50645.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
The iswspace() was only used when iswblank() was missing. The latter
is now provided by gnulib, so it is always available, so iswspace()
is not used at all anymore.
Mention the ability to use <Tab> in the search history, the ability
to restore the cursor position when reopening a file, the ability to
read output of a command, and the lack of file-managing commands in
the file browser.
The "./" is a shorthand for "current working directory".
It is better to specify it, because it differs from what
Pico does: reading always from the user's home directory
no matter where the editor was started.
Only use the "from" thing when an operating directory is in effect,
because /only/ then the indicated directory can be something other
than "./".
Also, make it so that there is no space before the colon.
Put all the movement keys together, in order of ascending stride.
Also, move the Undo/Redo keystrokes further up, so that, when the
user has a somewhat wider terminal than the usual 80 characters,
these keystrokes will be shown -- they are far more interesting
than the ^Y and ^V ones, for which PgUp and PgDn can be used.
If the number of columns in the edit window changes (which currently
only happens in two places: in regenerate_screen(), called when the
window is resized; and in main(), when line numbering mode is toggled),
the display will break if we're in softwrap mode and firstcolumn is
nonzero. This is because the column width of softwrapped chunks has
changed, and firstcolumn is no longer the starting column of a chunk,
an assumption that all code using firstcolumn relies on.
To fix this problem, add a new function, ensure_firstcolumn_is_aligned(),
to adjust firstcolumn to the starting column of the chunk it's on, and
use it when the number of columns in the edit window changes.
(Note that this function uses the simplest possible fix, and could
probably be made more sophisticated.)
In do_replace(), replacing text may change firstcolumn if the next match
is offscreen, and replacing text after that will not change it back. In
order to keep the viewport unchanged, we have to save and restore not
just edittop, but firstcolumn as well.
In do_int_spell_fix(), spell-checking text may change firstcolumn if
the next match is offscreen, and spell-checking text after that will
not change it back. In order to keep the viewport unchanged, we have
to save and restore not just edittop, but firstcolumn as well.
In do_justify(), justifying text may change firstcolumn if the paragraph
ends offscreen, and unjustifying the text again will not change it back.
In order to keep the viewport unchanged, we have to save and restore not
just edittop, but firstcolumn as well.
Copying text involves first cutting it and then quickly pasting it back.
However, cutting the text may change firstcolumn if the mark is offscreen.
To keep the viewport unchanged, copy_text() has to save and restore not
just edittop, but firstcolumn as well.
Now that we can add text to the bottom right corner of the screen
without scrolling the full line onscreen, do_output() needs to refresh
the screen in that case, since it would put the cursor offscreen
otherwise. Accomplish this by borrowing logic from do_right().
In do_up() when scroll_only is TRUE, if we're at the top of the screen
in softwrap mode, it's not enough to check that edittop is on fileage.
We also need to check that firstcolumn is zero.
In do_up() when scroll_only is FALSE, if we're at the top of the screen
in softwrap mode, current_y should be zero. This is equivalent to how,
in do_down() when scroll_only is FALSE, current_y is (editwinrows - 1)
at the bottom of the screen in softwrap mode. Since edittop can now
be partially scrolled off the screen even when it takes up the entire
screen, checking for edittop's being equal to openfile->current->next
there no longer applies.
The new function, update_softwrapped_line(), is called from inside
update_line() when softwrap mode is on, so that existing calls remain
unchanged. It takes no index, instead displaying edittop from column
firstcolumn, and all other lines from column zero.
If current is on edittop, it's displayed using the edittop rules, but
this is not a problem: if current[current_x] is above edittop at column
firstcolumn, it's offscreen, and that should be handled before calling
update_line() anyway.
Together with the preceding bunch of changes,
this fixes https://savannah.gnu.org/bugs/?47667.
Make current_is_above_screen() check for current[current_x] being above
edittop at column firstcolumn, and make current_is_below_screen() start
counting down from edittop at column firstcolumn instead of edittop at
column zero. This means that both functions now account for softwrapped
chunks properly.
Actually enable scrolling edittop partially off the screen by making
edit_scroll() and adjust_viewport() use firstcolumn properly when
iterating through softwrapped chunks in softwrap mode, or lines in
non-softwrap mode.
In non-softwrap mode, firstcolumn should still always be zero, because
it's initially set to that, and because passing it through the iterators
will maintain it at that.
This fixes https://savannah.gnu.org/bugs/?49100.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
We want to be able to scroll the line at edittop partially off the
screen. For this to be possible, the new variable firstcolumn stores
the starting column of the viewport -- the starting column in the line
that edittop points to.
Since firstcolumn is used by go_back_chunks() and go_forward_chunks(),
it can't be completely #ifdefed out when NANO_TINY is set, but outside
of softwrap mode it should always be zero.
Currently firstcolumn is initialized to zero, reset to zero when
toggling softwrap mode off, and reset to zero when switching buffers
while softwrap mode is off. It's otherwise unused, but its uses are
forthcoming.
Since all lines can be partially scrolled off the screen now
(except for the top line of the edit window, which is forthcoming),
ensure_line_is_visible() is no longer needed.
Since all lines can be partially scrolled off the screen now
(except for edittop, which is forthcoming), the maxlines global
variable and its computation mechanism are no longer needed.
Use go_back_chunks() and go_forward_chunks() to move a screenful of
lines or chunks up or down, instead of using special computations in
the softwrap case.
Use go_back_chunks() and go_forward_chunks() in do_up() and do_down()
(instead of using a special and complicated computation in do_down())
so that they now properly move vertically to the previous/next chunk
in softwrap mode. This also means that do_left() and do_right() will
now properly move vertically at actual line boundaries.
Use the new "unclever" functionality of Home and End to make do_left()
and do_right() move properly to the end of the previous chunk or to the
start of the next chunk in softwrap mode when crossing a line boundary.
(Furthermore, doing Up plus End, or Down plus Home, does all needed
screen updates, which simplifies the code.)
The do_left() and do_right() functions don't yet properly move vertically
at line boundaries, but that will be fixed once do_up() and do_down() are
updated for softwrap mode, which is forthcoming.
This fixes https://savannah.gnu.org/bugs/?49384.
Add the parameter be_clever to both functions. When be_clever is FALSE,
smart home and dynamic home are disabled in do_home(), and dynamic end is
disabled in do_end(), so that these functions only move to the beginning
or end of the current line or chunk.
This simple home and end functionality is needed to improve do_left()
and do_right()'s horizontal behavior with softwrapped chunks, which is
forthcoming.
Make do_end() more useful in softwrap mode: let it move to the end of the
current chunk instead of the end of the line; only when already at the end
of a chunk, let it move to the end of the line. This is "dynamic end".
Make do_home() more useful in softwrap mode: let it move to the beginning
of the current chunk instead of to the beginning of the whole line; only
when already at the beginning of a chunk, let it move to the beginning of
the line. This is called "dynamic home'.
The above rules are ignored when --smarthome is in effect and the cursor
is somewhere in the leading whitespace of a line -- then the cursor is
moved to the first non-whitespace character of the line.
These improvements will eventually make do_home() and do_end() take
parameters. Since the global function lists can hold only functions
without parameters, preemptively add do_home_void() and do_end_void(),
and make the global function lists use them.
Use go_back_chunks() and go_forward_chunks() to move from the row
current_y is on to the row mouse_row is on. Now softwrap mode and
non-softwrap mode will behave the same way when we can scroll edittop
partially off the screen, which is forthcoming. Accordingly, remove
the call to ensure_line_is_visible(), as it no longer applies.
The old code did work, but it behaved differently between softwrap mode
(which counted down from edittop) and non-softwrap mode (which counted
up or down from current_y to take less time, and used a double loop to
keep current from going to NULL).
The new code counts up or down from current_y in both softwrap mode and
non-softwrap mode. In non-softwrap mode, it also avoids the double loop,
since go_back_chunks() and go_forward_chunks() keep the filestructs they
operate on from going to NULL.
Use go_back_chunks() to adjust edittop, instead of special casing
the computation of goal when softwrapping. Now softwrap mode and
non-softwrap mode will behave the same way when edittop can be
partially scrolled off the screen, which is forthcoming.
(Note that the top line of the screen can't be partially scrolled
yet, so we have to work around that for now.)
Use go_back_chunks() and go_forward_chunks() to adjust edittop and to
move up or down to the scrolled region before updating the rows there.
Now softwrap mode and non-softwrap mode will behave the same way when
we can scroll the top line of the screen partially off the screen,
which is forthcoming.
(Note that the top line of the screen can't be partially scrolled yet,
so we have to work around that for now.)
Not drawing a line on a row if we're on the top row and scrolled down,
or if we're on the bottom row and scrolled up, will only work properly
if the line on that row takes up only that row. The latter might not
be the case in softwrap mode: if the line occupies multiple chunks and
begins on that row -- in that case none of the chunks would be drawn.
Add the new functions current_is_above_screen() (which doesn't account
for softwrapped chunks yet, but will when we can scroll edittop partially
off the screen, which is forthcoming), current_is_below_screen() (which
determines whether current[current_x] is past the softwrapped chunk at
the bottom of the screen), and current_is_offscreen() (the union of the
previous two functions).
edit_redraw() and edit_refresh() now use current_is_offscreen() to check
whether they should adjust the viewport, and adjust_viewport() now uses
current_is_above_screen() to determine whether current is on or below
the screen in FLOWING mode.
Add the new function less_than_a_screenful() to accomplish this.
It uses go_back_chunks() to count the number of softwrapped chunks
between the end point and the starting point of the paste.
Now softwrap mode and non-softwrap mode behave the same way when
uncutting fewer than editwinrows rows of text. Accordingly, remove
the call to ensure_line_is_visible(), as it no longer applies.
Use go_forward_chunks() to count softwrapped chunks between the current
cursor position and the bottom of the file. Now softwrap mode and
non-softwrap mode behave the same way when moving to a line and column
non-interactively, instead of the former's always centering the screen.
These functions, go_back_chunks() and go_forward_chunks(), take a number
of softwrapped chunks (screen rows) to move, a pointer to a buffer, and
a location (specifically, a starting column of a softwrapped chunk). If
they move successfully, they will update the buffer pointer and location
to point to the beginning of the softwrapped chunk they moved to.
Since non-softwrap mode is effectively just a subset of softwrap mode
in which every line takes up one chunk, these functions also work in
non-softwrap mode. In this case, their starting column will always be
zero, as it would be in softwrap mode on a line that takes up one chunk.
Nothing uses these functions yet, but that is forthcoming.
Instead of redetermining the entire span of the converted string,
simply move one character left, and then bite it off to make place
for the trailing $.
If the last two columns of a row would be taken up by a double-width
character (and the line is longer than that), don't print it, because
it wouldn't leave any room for the $ character.
This fixes https://savannah.gnu.org/bugs/?50491.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
On a system with up-to-date GNU tools, this does not change
the size of nano's binary.
We start off with importing only a few modules, although we
don't yet delete the fallback logic for them.
The gettext-0.18.3 release was made in Jul 2013, while the 0.11.5
release was made in Aug 2002. Time to update :).
Also drop all the bundled gettext m4 files. When you run autogen.sh,
these will get copied in automatically for you.
The autoconf-2.69 release was made in Apr 2012.
The automake-1.14 release was made in Jun 2013.
Update the requirements so we know we can rely on macros/features
available in those versions.
The mark only needs to be off when calling replace_marked_buffer(),
because this indirectly calls ingraft_buffer(), which fiddles with
the end points if the mark is on.
Running strlenpt() on a string that takes up more than 80 columns
(the width of an average terminal) takes /more/ time than simply
converting an extra character (the one that will be overwritten
by the "$" at the edge of the terminal). So... just convert one
more character than necessary when the line is overlong. In the
most common case, however, the line will fit fully onscreen, and
we save a whole call of strlenpt().
Since we only need span columns of the string, stop scanning the string
as soon as we have that many columns, instead of scanning the string all
the way to the end. This speeds up the conversion of very long lines.
Replace partitioning with calls to extract_buffer() and ingraft_buffer().
In addition to pasting the unjustified text back into the buffer at
current[current_x], ingraft_buffer() also deals with renumbering and
updating totsize, so do_justify() doesn't need to do those anymore
when unjustifying.
With read_file() revamped, it now uses partition_filestruct() indirectly
via ingraft_buffer(), so we can't use partition_filestruct() to replace
marked text in the alternate spell checker anymore without segfaulting.
Add the new function replace_marked_buffer() to accomplish this instead.
Based on replace_buffer(), it uses extract_buffer() to throw away the
marked un-spell-checked text, and then uses read_file() to insert the
spell-checked text at the position where the mark was.
Accordingly, remove unneeded partitioning and related stuff from
do_alt_speller(). Besides pasting the file into the buffer at
current[current_x], ingraft_buffer() also deals with renumbering,
updating totsize, and handling a magicline, so do_alt_speller()
doesn't need to do those anymore.
Move buffer handling and '\r' stripping from read_line() to read_file(),
so that the file gets its format determined and gets stored in its own
buffer entirely in one function. Then use ingraft_buffer() to insert
this new buffer into the current one.
In addition to pasting the file at current[current_x], ingraft_buffer()
also deals with renumbering, the updating of totsize, and the handling
of a magicline, so read_file() doesn't need to do those anymore.
Note that all this makes read_file() depend on the position of
current[current_x] to know where to insert the file. Accordingly,
set current_x to zero in initialize_buffer_text() instead of in
make_new_buffer(), so that replace_buffer() keeps working properly.
Add its explanation as a separate paragraph.
Also: improve the argument of the --syntax option, as this is a <name>
and not merely a bundle of characters like the other <str> arguments.
In this last loop of break_line(), the pointer 'line' is one step ahead
of the index 'lastblank'. So the loop should first add the length of
the preceding character to 'lastblank' before determining the length
of the current character (and using this to advance 'line').
(There is something wrong in the last loop: line is one character ahead
of lastblank, but the current character length is added to both of them.
It thus assumes that all blank characters are the same number of bytes.
For spaces and tabs this works fine. But for more exotic blanks...)
Also, rename a parameter to be less cryptic, and remove an entire
condition because the relevant block will never be reached when
getting called from the help routines: if blank_loc is negative,
the function will have bailed out in the preceding if.
In softwrap mode, the entire line is onscreen, so the word is never
partially offscreen, so we always have enough columns to show it.
This fixes https://savannah.gnu.org/bugs/?50389.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Instead of allocating enough space to convert the entire passed string,
just allocate space for converting the part that will be converted --
that is: starting from start_index. This still allocates far too much
(if the passed string is very long and its tail part won't fit on the
screen), but it's better than before.
Cap the number of pauses when displaying ALERT messages, to avoid
making the user wait for ages when tens or hundreds of files were
specified on the command line.
This fixes https://savannah.gnu.org/bugs/?50362.
Reported-by: Mike Frysinger <vapier@gentoo.org>
When in softwrap mode, no "$" continuation characters are displayed,
so the code that reserves space for them should be skipped then.
This fixes https://savannah.gnu.org/bugs/?50335.
As a small service to the user, reject empty regex strings,
because an entirely empty regex simply doesn't make sense.
Inspired-by: Elia Geretto <elia.f.geretto@gmail.com>
When the marked region covers only a single line (or a part of it),
its new endpoint is not simply the length of the last line of the
spell-checked text, but instead the old endpoint plus the /change/
in length.
This fixes https://savannah.gnu.org/bugs/?50316.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
The previous code only directly refreshed the screen when the margin
changed due to toggling line numbering on. When the margin changed
due to toggling it off, it would indirectly refresh via do_toggle().
When replacements are made, nothing needs to be reset any more
(it was done insufficiently anyway). Just make sure the screen
is refreshed when all is done -- this may be superfluous when
doing interactive replacements, but not when replacing all.
When coloring a line, look only at the multidata of the preceding
line, and based on that determine what to seek in the current line.
This fixes https://savannah.gnu.org/bugs/?50292.
When painting a line, the multidata of the line /before/ it is valid
in most cases: it was determined just a moment ago. And it tells us
all we need to know: whether there is an unpaired start match before
the current line or not.
The only exception is when painting the first line of the screen:
the multidata of the line before it might be stale. So for the
first screen line we will always have to do some backtracking.
But that is left for later.
This fixes https://savannah.gnu.org/bugs/?50121.
If we're somewhere deep into the file and do a spell check, and the
first misspelled word happens to be right there, onscreen already,
then this word does not need to be centered -- it /should/ not be
centered. We should scroll only when necessary.
After the changes to the search routine, it is no longer necessary to
take one step back before starting a replacement session.
This fixes https://savannah.gnu.org/bugs/?50147.
Even when a match falls within the marked region, this does not mean
that it is a true match when already the whole file has been searched,
because then this is the second time we find this match.
This fixes https://savannah.gnu.org/bugs/?50158.
The spell fixer does not provide a beginning line, so the search routine
should then not try to refer to any data of this line. Also, since the
changes to the search routine there is no need any more to retreat one
step before starting to search for a misspelled word.
This fixes https://savannah.gnu.org/bugs/?50159.
That is: remove the special treatment of BOW anchors, and instead make
regexes match against the whole line instead of against an artificially
shortened one, because the latter method creates ghost matches: matches
at the starting point of the search that aren't really matches when seen
in the context of the whole line.
This fixes https://savannah.gnu.org/bugs/?50030.
When the tail of a match falls outside of the marked region,
it is in fact not a match and should not be replaced.
This fixes https://savannah.gnu.org/bugs/?50136.
When a replacement happens right at where the cursor sits, the position
of the cursor should not be adjusted, because the real cursor position
is between the current character and the preceding one: the place where
the cursor is shown is in fact right /after/ the insertion point.
This fixes https://savannah.gnu.org/bugs/?50134,
and fixes https://savannah.gnu.org/bugs/?50135.
Just assign the 'CNONE' value upfront, instead of figuring out
at the end of the line whether anything has been assigned yet.
Also, the old logic would leave unmarked a line that contains a
start match without any terminating end match. Not serious, but
not right.
Don't blithely overshoot the end of a line when both start regex and
end regex match an empty string. Overshooting would let the matching
run on into uncharted country and thus ultimately cause a segfault.
This fixes https://savannah.gnu.org/bugs/?50056.
Reported-by: Elia Geretto <elia.f.geretto@gmail.com>
During precalculation and in step_two, we begin looking for an end
match only after the full start match, not merely one byte beyond
its starting point. So do that too when searching backward for an
unpaired start match.
Also, index can never be zero here, because if the match was of length
zero, this piece of code will have been skipped by the preceding goto.
So we can always use REG_NOTBOL here.
(That goto is wrong, by the way: https://savannah.gnu.org/bugs/?50078,
but that will follow later.)
A search should start at the place of the cursor, not one step beyond,
so that the non-word boundary between the current character and the next
will be found. Starting one step beyond the current character, as was
done until now, would find the non-word boundary between the next and
the overnext character as the first one.
If the given line is out of range of editwinrows, we don't display it
at all, so we obviously don't display more than one line of it. Thus,
the return value in this case should be zero, not one.
(The mistake becomes visible when you go to the end of a very long line
of double-width characters: the $ will be shown on the right edge, even
though you're already at line's end.)
This reverts commit 16a7fd4b from yesterday.
When there is no end match after a start, it is pointless to look
for any more starts because also they will not have any end match,
so nothing will get painted -- just cut the loop short.
The tiny version can do regex searches nowadays, so the user might use
the \< and \> anchors in their regexes.
This fixes https://savannah.gnu.org/bugs/?50008.
The renamed variable 'index' is not the start of a match (as some comment
mistakenly said), but from where in the line we start looking for a next
match.
Also, use one more goto to allow unindenting a big piece of code, and
shortcircuit two while loops for two more small unindents.
The setting of current_y in copy_from_filestruct() also appears to be
a holdover from the days of a more-common STATIONARY scrolling mode.
do_cut_text() uses the above function when copying text (uncutting
text again right after cutting it). Since the text is effectively
the same afterward, current_y doesn't need to change.
do_uncut_text(), however, does need current_y up to date in one case:
when uncutting a full screen or less' worth of lines, focusing will be
FALSE, and it uses edit_refresh(), so it will use STATIONARY scrolling
mode then. Take a cue from do_insertfile() and call reset_cursor() to
get an updated current_y.
(Note that the check for a full screen or less' worth of lines uses
incorrect values when in softwrap mode, but that's a separate problem.)
undo_cut(), do_redo(), and backup_lines() do not need set current_y
because they all result in edit_refresh() with focusing = TRUE, so
they do a CENTERING scroll which does not need current_y.
It is the misuse of "x_" to mean a column position on screen, and the
misuse of "_col" to mean a character position in a string that causes
this confusion.
All these different "start"s and "end"s are confusing. Use instead
'from_x and 'till_x' to remember which part of the current line is
visible now on screen and is thus represented in 'converted'.
In order to determine the correct multidata for a line that doesn't
have such data yet, the whole line must be examined, not just the
part that fits within the screen width.
This fixes https://savannah.gnu.org/bugs/?49978.
A tag begins not merely with a "<" but it must be followed by an
ASCII alphabetic character or one of "/", "!" and "?".
Further, color all the valid attribute names in red.
That is: only extend the current Del or Backspace undo item when the
cursor is still (or again) at the same spot.
This fixes https://savannah.gnu.org/bugs/?50006.
If the system on which nano is configured does not have the 'makeinfo'
program installed, the prebuilt and packaged nano.info and nano.html
should nevertheless be installed.
Also, the TEXINFOS primary has built-in rules for generating HTML files
from the texinfo sources, so an explicit rule is not needed.
This indirectly addresses https://savannah.gnu.org/bugs/?49969.
Instead of setting openfile->current_y (and wrongly so), just call
reset_cursor() to recompute current_y and place the cursor on that
line (if it is not offscreen).
The search routine begins searching right after the cursor and behaves
as if the line starts there, which means that a beginning-of-word anchor
(\< or \b) will match there also when in fact the cursor is sitting in
the middle of a word. To prevent finding a false match, verify that
for a regex that starts with a BOW anchor the found match is actually
the start of a word.
This fixes https://savannah.gnu.org/bugs/?45630.
Since do_mouse() uses edit_redraw(), openfile->current_y will be
immediately recalculated, so there's no point in changing it now.
Use a temporary variable instead.
The value of sameline doesn't change, so it can be initialized to that.
Since i holds openfile->current_y, it should be ssize_t, not size_t.
And it's better to do the most significant part of a calculation first.
Many of the adjustments of the value of openfile->current_y appear to be
a holdover from the days when certain functions had to account for what
is now called STATIONARY scrolling mode, which depends on the value of
current_y. Remove these adjustement where they are superfluous.
do_para_begin(), do_para_end(), and do_bracket_match() update the screen
through edit_redraw(), which uses either CENTERING or FLOWING scrolling
mode, so their setting of current_y is redundant and useless, as it will
be ignored and then overridden by the next call to reset_cursor().
findnextstr() is called by go_looking() [which calls edit_redraw(), see
above], and by do_replace_loop() and do_int_spell_fix(), which both call
edit_refresh(), which in this case only uses CENTERING scrolling mode
since focusing is TRUE.
(Additionally, the adjustments of current_y in findnextstr() and
do_bracket_match() use incorrect values when in softwrap mode.)
find_paragraph() doesn't need to save or restore current_y, because it
doesn't do any screen updates. do_justify() calls edit_refresh() with
focusing set to TRUE, so it uses the CENTERING scrolling mode.
do_alt_speller() and do_formatter() do not need to save and restore
current_y, because they don't modify it in any way.
This addresses https://savannah.gnu.org/patch/?9197.
This makes nano's cursor behavior consistent across 1) typing text by
hand; 2) pasting in text with ^U; 3) inserting text from a file; and
4) redoing with M-E that same typing or pasting or inserting.
This fixes https://savannah.gnu.org/bugs/?49968.
There are just a handful of source files for the documentation --
it is wasteful and cumbersome to have these in separate directories.
Also: remove the French man pages -- they are too far out of date.
(And anyway, we should acquire a general framework for translating
the documentation.)
The warning is wrong when the user has just saved a buffer under a
new name. And when --quickblank is used, the warning most likely
gets cleared off before it is seen, and the user would just hear
the beep and be left wondering what happened.
This avoids https://savannah.gnu.org/bugs/?49875.
This disallows entering a verbatim ^J (0x0A) when typing text or
search terms, and disallows a verbatim ^@ (0x00) when typing a
filename. Nano beeps when the disallowed code is attempted.
This addresses https://savannah.gnu.org/bugs/?49897.
Also at the yes-no prompt, a 0x0A byte should be displayed as a ^J
instead of splitting the prompt bar in two and spreading it over
two lines.
This fixes https://savannah.gnu.org/bugs/?49934.
After a call to the Formatter or the Alternate spell checker, the data
on the undo stack could refer to line positions that don't exist any
more -- the chance is small, but it is there. So... throw the whole
undo stack away, to prevent undoing things wrongly or even crashing.
(Changes made with the internal spell checker can be undone and redone
without a problem -- nano keeps full track of those. But the changes
made with a formatter or an external spell checker happen in another
process, so nano has no record of them.)
This fixes https://savannah.gnu.org/bugs/?49920.
When using an external spell checker or formatter, the line with
the cursor might become shorter, which might result in the stored
cursor position being beyond the end-of-line. So, when restoring
the x position, make sure to limit it to the length of the line.
This fixes https://savannah.gnu.org/bugs/?49923.
In path names and file names, 0x0A means an embedded newline and
should be shown as ^J, but in anything related to the file's data,
0x0A is an encoded NUL and should be displayed as ^@.
So... switch mode at the two main entry points into the "file system"
(reading in a file, and writing out a file), and also when drawing the
titlebar. Switch back to the default mode in the main loop.
This fixes https://savannah.gnu.org/bugs/?49893.
Decode 0x0A bytes to 0x00 when saving the search history, and encode
them again when reading the file back in, to prevent nano from hanging
or aborting when encountering 0x00 on a line by itself.
After updating the color palette, the corresponding new window content
should be drawn immediately, before some other part of the code calls
doupdate(), to prevent the old content being shown in the new colors.
This fixes https://savannah.gnu.org/bugs/?49912.
Reported-by: Mike Frysinger <vapier@gentoo.org>
In nano 2.7.1 and 2.7.2, pressing Shift+Ctrl+Arrow on a Linux console
would behave as if Shift wasn't held. It got broken three months ago,
by commit 08cd197b, messing up the proper order of the checks.
This fixes https://savannah.gnu.org/bugs/?49906.
On some systems, typing ^C apparently results in a KEY_CANCEL in
the input stream, which gets hard-bound to the do_cancel function.
But in the main menu there is no Cancel function. So... in that
case, let it fall back to the plain old Ctrl-C code: 0x03.
Reported-by: Liam Gretton <liam.gretton@leicester.ac.uk>
A filename might contain spaces, so we can't look for the numbers
(the second and third elements) starting from the head of the line
-- we have to start at the tail and work backward.
This fixes https://savannah.gnu.org/bugs/?49879.
So they will not break a line in the positionlog file in two.
(Strangely, the reading in of such a log file already decodes
nulls back into newlines.)
This fixes https://savannah.gnu.org/bugs/?49877.
The byte 0x0A means 0x00 *only* when it is found in nano's internal
representation of a file's data, not when it occurs in a file name.
This fixes the second part of https://savannah.gnu.org/bugs/?49867.
Most full paths are needed only temporarily and will be freed within
milliseconds. Only 'full_operating_dir' and 'backup_dir' continue to
exist for the whole current session. Any partition, too, will soon be
unpartitioned, so the extra reallocation is just a waste of time.
That is: elide a second test from the most travelled path: a valid
character. This adds a second call of mblen() when parse_mbchar()
is called on a terminating zero, but that should never happen.
The fsfromline() function is mostly used by the undo functions, which
are not present in the tiny version. It is also used by the comment/
uncomment feature, but this feature cannot be enabled when --enable-tiny
is in effect.
Convert digits() to take a ssize_t instead of an int, since it's
used on ssize_t line numbers. And properly use the long modifier
when displaying a line number.
Also, conditionalize the digits() prototype.
An added magic linefeed should be removed again /before/ restoring
the x position, as the latter needs to be calculated from the real
last line of the region.
This fixes https://savannah.gnu.org/bugs/?49817.
Reported-by: Mike Frysinger <vapier@gentoo.org>
When wanting to debug something, it is far more useful
to temporarily insert lines like:
statusline(ALERT, "name = %i", variable);
It provides instant feedback, and it slows things down,
so you can kind of see what happens.
The functions read() and fwrite() take size_t, not ssize_t.
And line numbers in the file should be displayed as a long type instead
of an int, since the effective type of ssize_t is not int, but long.
(The variable 'pletion_line' is not conditionalized with this option, as
it would become messy. The compiler will probably be able to elide it.)
When using --enable-tiny, it is not possible to use --enable-wordcomp,
because the word completion function uses the undo system.
Executing the 'complete_a_word' function will search from the start
of the current buffer for entire words that begin with the fragment
that is before the cursor, and will complete this fragment to the
first word that is found. Each consecutive call of 'complete_a_word'
will search for the next matching word and will complete the fragment
to that. By default the function is bound to the ^] keystroke.
Signed-off-by: Sumedh Pendurkar <sumedh.pendurkar@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Modern VTE-based terminals now produce codes for those keys and
no longer swallow them when nano is active.
This addresses https://savannah.gnu.org/bugs/?49746.
Achieve this by reusing the code that gives feedback when trying to
save a buffer while using --tempfile and the file has no name yet.
This fixes https://savannah.gnu.org/bugs/?48622.
Also for Delete, End, PageUp and PageDown (on some terminals)
the last byte in the sequence needs to be checked.
This fixes https://savannah.gnu.org/bugs/?49710.
If it would, the returned file descriptor would make nano crash,
because the corresponding stream has not been opened. And when
returning zero instead (as the code did originally), nano would
open an empty buffer, although it claims to be reading the file.
In short: I think this is a leftover of an attempted fix of
https://savannah.gnu.org/bugs/?25297, from commit 2823c99.
We should avoid defining color schemes that are unreadable on common
white-on-black or black-on-white terminals. Change the black in the
autoconf error strings to brightred for that reason.
When probing symbols provided by ncurses, use the sublibs that pkg-config
reported in case they're needed (like when libtinfo is a sep library).
URL: https://savannah.gnu.org/bugs/?49614
- make version highlight less blindly greedy and conform to real versions
- move version matching before USE matching to avoid hitting USE flags
that look like versions
- change USE regex to match the Gentoo PMS
- extend arch match to include more keywords
- make category matching more restrictive to avoid false positives
- drop operators =< and => that Gentoo doesn't support
URL: https://savannah.gnu.org/bugs/?49569
Reported-by: Konstantin Shakhnov <kastian@mail.ru>
Otherwise the user can override a 'set nowrap' in /etc/nanorc only
via the command line.
This fixes https://savannah.gnu.org/bugs/?49593 reported by Shirish.
When giving a line number on the command line, do_gotolinecolumn() needs
to know the width of the screen to be able to (roughly) place the target
line in the center of the screen.
This fixes https://savannah.gnu.org/bugs/?49462.
It does not update anything -- it just picks a new point from
where to start displaying the buffer. All actual updating of
the screen is done by edit_refresh() and edit_redraw() and such.
It can be activated with --linenumbers on the command line or with
'set linenumbers' in a nanorc file, and it can be toggled with M-#.
Signed-off-by: Faissal Bensefia <faissaloo@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Returning a zero would mean returning a ^Space -- the keycode that
by default is bound to the Next-Word function. So, unbinding the
keys to which the modified Arrow keys are hard bound would cause
the latter ones to mysteriously jump to the next word.
This partially fixes https://savannah.gnu.org/bugs/?49058.
Add the keycodes and routines to allow the user to forego setting the
mark explicitly (with M-A / ^6) and instead quickly select a few words
or lines by holding down Shift together with the movement keys.
(Some combinations with Shift are swallowed by some terminal emulators.
To work around some of those, the combinations Shift+Alt+Left/Right work
as Shift+Home/End and Shift+Alt+Up/Down work as Shift+PageUp/PageDown.)
This also prevents the message from spilling into the help lines
when the terminal is less than four columns wide. (Not that one
can read anything then, but it looks better.)
Even when the edit window consists of just one or two lines, the PageUp
and PageDown functions (^Y and ^V) should continue to move the window.
This fixes https://savannah.gnu.org/bugs/?48805.
When using the default speller or the formatter, the placewewant is
remembered. So it should be remembered too when the user specifies
a different speller.
(This behavior was inadvertently lost last year, in commit 82d737e.)
It is quicker to do a handful of superfluous compares at the end of
each line than it is to compute and keep track of and compare the
remaining line length the whole time.
The typical line is some sixty characters long, the typical search
string ten characters -- with a shorter search string the speedup is
even higher: some fifteen percent. Only when the string is longer
than half the average line length does searching become slower with
this new method.
All this for a UTF-8 locale. For a C locale it makes no difference.
Now that mbstrncasecmp() does the right thing, there is no need any
more to verify that only a valid multibyte sequence was matched.
(See https://savannah.gnu.org/bugs/?45579 for a test case.)
Also, this will make it possible to search for invalid sequences.
(Currently it isn't possible to enter a search string with invalid
characters, but... a user might edit the search history file. And
if pasting at the prompt is implemented, it will be trivial to enter
invalid sequences if you have a file that contains them.)
Persisting might lead to count 'n' reaching zero, which would mean that
the needle has matched, which is wrong when one of the strings contains
an invalid or incomplete multibyte sequence.
That is: don't run towlower() on the two differing bytes when having
reached the end of one of the strings.
This fixes https://savannah.gnu.org/bugs/?48700.
In the bargain, don't do the conversion to lowercase twice.
Furthermore, persist when encountering invalid byte sequences --
until finding bytes that differ.
The needle is never part of the hay -- it is always a separate string.
(And even if needle and haystack were identical, the routine works fine,
the case does not need special treatment.)
When doing an <Up> on the top line, or a <Down> on the bottom line of
the edit window, the affected lines have already been redrawn by the
scrolling code, so there is no need to do that again.
(However, that does not prevent the second line (or the last-but-one
line) from being redrawn unnecessarily when using the M-- (or M-+)
command elsewhere on the screen and /that/ line is horizontally
scrolled. But we'll let that pass for now.)
For horizontal scrolling, it is not the /desired/ column position that
is relevant for determining whether a line needs to be redrawn after a
cursor movement, but the /actual/ column positions before and after.
This fixes https://savannah.gnu.org/bugs/?48627,
and fixes https://savannah.gnu.org/bugs/?48629.
Leave the rest of any escape sequence to be processed normally, which
should be possible because those characters are all in ASCII range.
This fixes https://savannah.gnu.org/bugs/?48318.
Also, when a key string does not denote a Ctrl nor Meta nor Function key,
there is no point in assigning a keycode, because plain characters cannot
be used as a function shortcut.
And hard-bind the keys Ctrl+Up and Ctrl+Down to these functions.
Unlike the paragraph-jumping code, these new functions disregard
any indentation, treating only blank lines as separators. They
also do an automatic smart home when that option is set.
This fulfills https://savannah.gnu.org/bugs/?48291.
Also, compose the coloring attributes during initialization
instead of every time when painting something.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Instead of referring to a window that might have been deleted by a
resize, just turn the keypad back on for the two windows from which
input might have been requested.
Also: don't insert KEY_WINCH as the verbatim keystroke.
This fixes https://savannah.gnu.org/bugs/?48532.
This allows the user to specify which other characters, besides the
default alphanumeric ones, should be considered as part of a word, so
that word operations like Ctrl+Left and Ctrl+Right will pass them by.
Using this option overrides the option --wordbounds.
This fulfills https://savannah.gnu.org/bugs/?47283.
When the user changes her mind after having pressed Esc, she cannot
unpress Esc, so do that for her by ignoring the escape code when
the subsequent keycode is outside of the normal printable range.
This restores the behavior from before nano-2.3.5 -- except that
Ctrl+Alt+key continues to report an unbound key.
This fixes https://savannah.gnu.org/bugs/?48459.
This prevents many keycode sequences from being misconstrued when a
command key plus other keystrokes accumulate in the input buffer.
This fixes https://savannah.gnu.org/bugs/?48395.
Add them so that <Esc> followed by <Home> will simply do "Home" instead of
reporting an unbound key. The same for <End>, <PageUp> and <PageDown>.
This restores the behavior from before nano-2.3.5.
It is easy to type beside the comma key and hit instead "m" or ".", so
accept also these as a separator between line and column number. And
when being generous anyway, also accept space, slash and semicolon.
This fulfills https://savannah.gnu.org/bugs/?48305.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Precalculation of the multiline color data can be cut short when the
user is impatient and starts typing. But this would drop the first
byte of whatever was typed -- not nice when it was just plain text,
but surprising and worse when the first keystroke was a command.
This fixes https://savannah.gnu.org/bugs/?48388.
When for a multiline syntax-coloring rule the starting regex matches at
the exact same spot as the ending regex, do a second round of resets, so
that reevaluation starts further back and gets a few more things right.
This mildly fixes https://savannah.gnu.org/bugs/?47420.
When we get a ^J as verbatim input, it is not possible to include it
into the file buffer or the prompt answer, because this would mean
adding an encoded null to the buffer or answer, and that is not what
the user intended. One option would have been to simply ignore a ^J
in verbatim input. But the choice has been made to act the same way
as when the ^J (0x0A) is found in the file data: start a new line.
That is the same response as to the Enter key, yes -- but the code
for the Enter key is ^M (0x0D), not ^J. So, to be more precise,
rename the relevant variable from 'got_enter' to 'got_newline'.
When the user tab-completed a name at the Go To Directory prompt, this
name will end in a slash. Remove this slash, so the name can be found
in the file list (where directory names don't include the final slash).
This fixes http://savannah.gnu.org/bugs/?48353.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Invalid multibyte sequences get depicted with the Replacement Character,
and unassigned codepoints are shown as if they were a space. Both have
a width of one.
Just allocate ample space up front and thus discard the delaying 'if' for
each and every character. In most cases this will allocate far too much,
but that hardly matters: it is freed again as soon as the line is printed.
Keystrokes are single integers (aided by the flags meta_key and
func_key) but in the input stream they can be encoded as escape
sequences (a series of bytes). Characters are values in byte
range, but in UTF-8 one character can consist of multiple bytes.
Also rename two variables, because the secondary input buffer
that they refer to contains only characters (mostly just one),
never any shortcuts; and there are too many "kbinput" already.
Also, other messages that are about --operatingdir don't use the term
"confined" either.
Suggested-by: Mario Blättermann <mario.blaettermann@gmail.com>
Don't make it the responsibility of the executed functions to restore
the list of shortcuts of the edit window. Just detect whether another
menu was displayed, and if so, redisplay the main menu.
The way to update nano.pot is to run 'make nano.pot-update' in the po
subdir. Updating a specific PO file is then done with 'make xx.po'.
(The script mistakenly included all leading comments, not just the
ones marked with "TRANSLATORS:".)
It sounded like an instigation to upgrade, or like a list of
instructions on how to upgrade. But it is merely a list of
noteworthy changes -- what other packages put in the NEWS file.
To add a character, one does not need to allocate twice its size.
And the amount to be moved does not depend on the size of the new
character; it just needs to include the terminating zero.
(This fixes in do_output() the same logical mistakes that were fixed
in do_statusbar_output() last February, in acf19bd and 7c0e433.)
Specifying an operating directory should either lead to a successfull
confinement, or nano should fail to start.
(Also: save the terminal settings as soon as possible, so that an early
die() will not restore uninitialized values.)
This fixes the first part of https://savannah.gnu.org/bugs/?47798 properly.
This fixes https://savannah.gnu.org/bugs/?48103.
(The fix is wasteful -- it should only discard the multidata if actually
the name *did* change, *and* if the applicable syntax changed.)
By moving the test for the only situation where do_comment() does nothing
(when only the magic line is selected) further up front, the add_undo()
can be called before the commenting/uncommenting starts and two variables
and an extra function are made unnecessary.
That is: don't mix the number of lines read with a warning about the
file being unwritable -- the former is just convenience information,
the latter is a must-see.
This fixes https://savannah.gnu.org/bugs/?48047.
When running in a non-UTF locale, and when strncasecmp() suffers from
the same defect as strncmp(), make sure not to pass a length with the
high bit set.
This reverts commit df8c3de from six years ago, which prevented a crash
on the Armel/Maemo platforms but causes nano to lose history items.
The strncmp() function on those platforms treats size_t numbers with
the high bit set as if they were zero. To avoid that, use a number
that cannot be seen as negative, as suggested by <alpha@qzx.com>.
This fixes https://savannah.gnu.org/bugs/?48048.
Tested-by: Tito Ragusa <farmatito@tiscali.it>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Store the file sizes from before and after the commenting/uncommenting
in the undo struct, so they can be restored when undoing or redoing.
This fixes https://savannah.gnu.org/bugs/?48062.
Signed-off-by: Mike Scalora <mike@scalora.org>
When opening a file that was edited before, and the remembered position
is near the end of the file, then don't center the target line but show
the last line of the file on the bottom line of the screen, thus showing
as much of the file content as possible.
This addresses https://savannah.gnu.org/bugs/?46243.
Instead of parsing every multibyte character twice, first with
parse_mbchar() and then with mbtowc(), just let mbtowc() do all
the work. This makes searching for a fixed string twice as fast.
This also gets rid of four variables and lots of memory allocations.
(And, more importantly: it stops nano messing up the internal state
of the multibyte-to-wide character conversion, and thus would make
the calls to mbtowc_reset() superfluous.)
This allows for commenting or uncommenting a line or a bunch of lines
with a single keystroke (default binding: M-3). The characters used
for commenting/uncommenting are specified by the active syntax file.
Reviewed-by: Benno Schulenberg <bensberg@justemail.net>
Signed-off-by: Mike Scalora <mike@scalora.org>
Move the initialization of the operating directory to after the
initialization of the screen, so that the above error can be shown.
This fixes the first part of https://savannah.gnu.org/bugs/?47798.
Between the first stat (that sets 'realexists') and the second stat
(directly after), the file might have disappeared, which would mean
that current_stat would be NULL. Prevent dereferencing this further
down.
Only when the user decides not to override an existing lockfile should
loading the corresponding file be skipped. Any failure to write the
lockfile should be ignored -- the file itself should be loaded anyway.
This fixes https://savannah.gnu.org/bugs/?47945.
Error messages about lock files should not get overwritten by purely
informational messages, only by alerting ones.
This fixes https://savannah.gnu.org/bugs/?47963.
The variable 'namecopy' has been passed to dirname(), so it is likely
to have been changed when it contains a slash. So, use a new variable
instead. Also, free the result of display_string().
This fixes https://savannah.gnu.org/bugs/?47956.
Having just opened a fresh buffer, 'openfile->next' will never be NULL,
because the list is circular.
Second, when compiled with --disable-nultibuffer, and deciding not to
override an existing lock, the 'return FALSE' should *not* be skipped,
because otherwise the named file will be opened after all.
This fixes an unreported bug.
Either the selected file was changed, or a file or directory was chosen
(and the Enter key virtually pressed), or a shortcut was executed. So,
just go and read the next key.
This fixes https://savannah.gnu.org/bugs/?47944.
If during startup there are multiple error messages, currently only the
last one remains and can be read. To improve on that, introduce a short
pause between error messages -- even if it's not enough to read them all,
at least the user will be aware that there are multiple ones.
This also causes a few error messages to beep that currently don't beep,
such as when a file is unwritable.
When doing a PageUp or PageDown in the browser, don't move the highlight
to the first line in the same column, but keep it in the same relative
position of the screen. If we're already on the first or last page,
move the highlight to the first or last line, but keep it in the same
column. If we're already on the first or last line, only then move it
to the first or last entry.
CONST_UPDATE is only relevant when in the main menu, not when in the
browser. So, check for that condition, instead of saving, changing,
and then restoring the setting.
There is no need to iterate through all the file names, as we already
know the length of the longest. From this it's easy to calculate how
many names fit on a line.
Also rename some things to be more fitting. And make sure that something
will be selected even when many files, including the selected one, have
disappeared.
When refreshing the screen (and thus the file list), use the prev_dir
mechanism to reselect the file that was selected before the refresh,
to prevent the selection from changing when files were added or deleted.
Also, when the selected name has disappeared, move the highlight one step
back, so that it is obvious that the selection has changed. (Decrementing
'selected' will never make it negative, because selected == 0 means the
'..' entry, and every directory has a '..' entry, so it will be found.)
This fixes https://savannah.gnu.org/bugs/?47812.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
When during searching we look at the keyboard, then don't look at
just the first keystroke, but check if there are more, and if so,
check each one until we find a Cancel -- or until all keystrokes
have been consumed and we can continue.
This fixes the first half of https://savannah.gnu.org/bugs/?47438.
Cancelling a search should restore waiting mode for the keyboard,
just like at the other exit points of the search routine.
And when the input routine has read in multiple keystrokes, it
should not blindly switch back to waiting mode, but only when
that mode was on before.
This fixes the second half of https://savannah.gnu.org/bugs/?47438.
When the terminal is very narrow, there is little point in showing only
part of the version string -- and chewing off one or two digits from the
version number might even give someone a wrong idea. The user is better
served with always showing the full filename, as long as it fits in the
available screen width.
This fixes https://savannah.gnu.org/bugs/?47703.
Also remove the item about one Replacement Character per invalid UTF-8
sequence, because how many bytes form a sequence? Two? Three? Four?
Better just put one Replacement Character per invalid byte, like is
done now.
When fixing a misspelling and not answering 'All' (but 'Yes' or 'No'),
the chance is quite substantial that one will type y or n at the end of
the next word. Diminish this chance by showing for a moment a message
on the statusbar.
Partitioning the file makes the undo system lose track, so that undoing
things has a good chance of losing data. Instead, just make sure that
the region is marked "backwards", with current at the top and the mark
at the bottom, and then let the replace loop take care of not going
outside of the marked region.
This also has the effect that if the marked region fits entirely on the
screen, or all the misspellings are onscreen, then the screen will not
be scrolled at all. Which makes for a smooth experience.
This fixes https://savannah.gnu.org/bugs/?47836,
and fixes https://savannah.gnu.org/bugs/?45573.
Since nano-2.4.1, reading in or pasting a large piece of text would put
the cursor on the bottom line, leaving only one line of the non-read or
non-pasted text visible. This is different from the centering behavior
of Pico, and somewhat disorienting, as you can't see "where you are" any
more in relation to the file as it was.
So now center the cursor whenever the read or pasted text is larger than
the screen, but don't center it when the text fits entirely on the screen.
(The latter avoids the effect of the screen jumping unnecessarily when
inserting just a few lines while the cursor is near the bottom.)
To achieve this behavior: default to focusing, and temporarily set it to
FALSE when the focusing effect is unwanted.
This fixes https://savannah.gnu.org/bugs/?47841.
For some reason the keyboard code seems to assume that all integers
waiting in the keybuffer form a single sequence. But this isn't the
case: when there is an escape (0x1b) among them, then that is where
a new sequence starts. So, prevent the input code from considering
an escape after a non-escape as part of the current sequence.
This fixes https://savannah.gnu.org/bugs/?47839.
When starting to replace misspelled words, pass the actual position
of the cursor instead of the position of the first found occurrence,
so that the cursor position will be updated for changed lengths.
This fixes https://savannah.gnu.org/bugs/?47834.
When verifying that a match is a separate word (during spell checking),
instead of first copying out the word, then passing the word, and then
measuring its length, just pass its length straigtaway.
When we're spell checking, we don't need a special mechanism to detect
we have come full circle: reaching the end-of-buffer means we're done.
So don't bother to reset came_full_circle when we're spell checking
(when begin == NULL) but simply ignore its value.
Add a global variable, 'present_path', so that 'cwd_tab_completion()'
knows where the user is in the browser, so that it can try completions
against names in that directory instead of always against names in the
current working directory (where nano was invoked).
This fixes https://savannah.gnu.org/bugs/?47234.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
The internal spell checker starts searching/replacing always at the top
of the buffer, so reaching the end of the buffer means we're done with
the current search/replace. This prevents the "Search Wrapped" message
from flashing over the statusbar at the end of a spelling replacement.
Commit 8704dde mistakenly removed this part of code -- it is not dead,
it is just that it will only fire when the user answered No at some of
the replacement prompts. So... when we've rereached the starting line,
a found occurrence is invalid when it is beyond the starting x (either
after or before it, dependending on the direction of search).
This fixes https://savannah.gnu.org/bugs/?47816.
Included files are meant to contain only syntax definitions; they may
not set or unset options, nor rebind keys, nor include other files.
This fixes https://savannah.gnu.org/bugs/?47391.
For a little contrast with the function edit_refresh() -- it's
annoying that when you search for the latter you get to see all
the settings of the flag too.
The function edit_update() is called by edit_refresh() itself, so it is
silly that the first sets 'edit_refresh_needed' to TRUE. This setting
is needed only in a few cases -- in the others it's not needed because
the screen does not need to be refreshed (it was just about positioning
the cursor), or 'edit_refresh_needed' has already been set by a call to
goto_line_posx(). So, just set the flag in the five places that need it
and spare the other four calls.
Since commit 41ed690, cancelling a prompt after tabbing would sometimes
leave the list of file names on the screen. When testing this first,
it worked fine -- I was fooled again by 'edit_refresh_needed' already
being TRUE when nano has just started up and sits waiting for the first
key stroke. I have to hunt this down and kill it.
Since commit dac0aa1, nano would leave edittop at current after reading
data from standard input, meaning that everything that had been read in
was invisible, "scrolled off" the top of the screen. Correct this by
explicitly setting edittop.
The above does not happen for ^R (^X) because it has a special mechanism
to save and restore edittop. Nor does it happen for ^R ^X M-F because it
sets current to the top of the file and refreshing the screen will make
edittop follow, or -- in case just one unterminated line was read in --
edittop will already be equal to current.
A normal lock file is apparently 1024 bytes in size, so the second
attempt at reading bytes from the file would try to read 8192 more
bytes into a buffer that has room for only 7168 left. According to
valgrind, the read() function doesn't like that -- and true: if for
some reason the lock file had suddenly expanded, the buffer would
overflow.
This fixes https://savannah.gnu.org/bugs/?47156.
Commit 36ec76a made the wrong change: after a tab that did not list any
file names on the screen, a refresh /is/ needed, because a previous tab
might have listed things on the screen. But at the end of the prompt,
it is not necessary to refresh the edit window if things were listed,
because the window will be refreshed anyway after reading in a file.
Use 'slash' to point at a possible slash, use 'filename' just to
point at the real file name, and use 'wasdirname' just to point at
the dir's name before expanding it in order to be able to free it.
Also, remove two superfluous asserts: 'dirname' cannot be NULL
because it has just been mallocstrcpy'd, and checking 'num_matches'
is pointless as it would crash on the next statement anyway.
This is a remnant from 2001, when things were different. Now, there
is no need to refresh the edit window when tabbing produced no list.
When it did produce a list, it is cleared off later.
If for some reason opening the spell-checked or formatted file fails,
don't throw away the current contents of the buffer.
(It should also give proper feedback about the failure, but we'll leave
that for some other time.)
Also, store the input character earlier, so we don't have to use len - 1.
Furthermore, len increments in steps of 1, so it cannot pass the value of
bufx unnoticed, so use a comparison for equality.
Most of the time NO_CONVERT will not be set, the number of lines will
not be zero, and the format of the file will be zero. Rearrange the
conditions so that they will evaluate as FALSE as soon as possible.
Index i follows almost synchronously the value of len. Since we're
adding characters to the intermediate buffer always only at the end,
just use len as the index.
Until now (when not leaving files unconverted), nano would fumble and
drop the final carriage return of a Mac file, and would thus treat the
last line of such a file as an unterminated line and prepend it to the
current line of the buffer. Correct that, and delete the dead piece
of code that was meant to do this.
This fixes https://savannah.gnu.org/bugs/?47716.
When we don't set edittop in read_line(), we don't need to readjust it in
read_file(), because in that particular case it will still be pointing at
current. And since fileptr is a new, freshly created line, it can never
be equal to filebot, so there is no point in comparing them.
If more than one line was inserted at the beginning of the file, leave it
up to the screen handling to set edittop to what it should be.
Move the setting of fileage a bit down, to its sister setting: the line
at current gets "connected" either to the top-of-file pointer or to the
last line of the inserted file.
The number of lines to scroll is: the y position of the start of the
current line, plus the extra lines that this line occupies, plus the
extra lines that the next line occupies, plus one, minus the y position
of the last window line.
The y position of the start of the current line is current_y -
xplustabs() / COLS, the extra lines are strlenpt(data) / COLS,
and the y position of the last window line is editwinrows - 1.
Note that we first compute the amount to scroll before actually moving
to the next line, because we need the current value of current_x, not
the one that it will have in the next line. The placewewant value is
not good either, because it might be beyond where we actually are.
This fixes https://savannah.gnu.org/bugs/?47665.
Doing a chdir("..") will not fail when the root directory is reached,
and when getcwd() keeps failing too, we have no way of knowing when
to stop. So, simply limit the number of attempted chdirs, to avoid
getting into an endless loop.
This avoids the hang in https://savannah.gnu.org/bugs/index.php?47659.
Reported-by: Chris Renshaw <osm0sis@outlook.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Also, don't force a full refresh of the edit window simply because the
current line needs to be horizontally scrolled. And further, when the
adjustment of edittop has determined that a full refresh is needed,
get out and don't bother scrolling some lines first.
When in softwrap mode and scrolling down a line, and thus going to
do a full refresh, get out and don't bother redrawing the current
and prior lines first.
When moving the cursor up or down one line, redraw the new current
line only when the target column (placewewant) is beyond the screen,
or when the mark is on.
(This still redraws the current and prior lines unnecessarily when
they are in fact shorter than the screen is wide and the mark is off,
but we'll let that pass for now.)
Also, when softwrap is on, we don't have have to redraw the current
and prior lines at all (when the mark is off): they are in full view,
there is nothing to show or hide.
When scrolling down a line, a full refresh of the edit window is only
needed when softwrap is on, because only then the movement is irregular.
When each file line takes up just one screen line (softwrap is off),
edit_scroll() is perfectly able to scroll and redraw only the necessary
lines.
(But... when doing a full refresh anyway with softwrap, why bother
scrolling at all? Why not just adjust edittop and call refresh?)
The old_current line needs to be redrawn only if it differs from current,
and if it wasn't drawn already by the iteration for when the mark is on.
Also make the conditions involving horizontal scrolling more precise.
Instead of saving the current value of placewewant, then setting the
new value, and then passing the old value to edit_redraw() in seven
different places, just let edit_redraw() do this saving and setting.
In the bargain placewewant is now only recalculated when it matters
-- when allow_update is TRUE -- and not when it's superfluous.
Nano doesn't start doing anything with the edit window or the keyboard
until all files have been read in or a blank buffer has been opened, so
the case of openfile->current == NULL will never occur.
Also correct the comment -- because with multibyte characters, it is
very well possible that the screen column corresponding to current_x
is smaller than current_x itself.
Instead of allocating a fixed amount of 128 bytes, which will overflow
and segfault, adjust the allocation to the length of the file name, and
if necessary trim the file name to make the prompt fit on the screen.
This fixes https://savannah.gnu.org/bugs/?47511.
Reported-by: Aapo Rantalainen <aapo.rantalainen@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
In the innermost search loop, don't set placewewant, because this loop
is also used for replacing and spell fixing, when we don't really want
to be there: we are just passing through. Not setting placewewant means
we don't need to save and restore it in those passing-through routines.
The value of placewewant is only relevant when doing cursor movement,
which doesn't happen during replacing nor spell checking, so there is
no need to keep placewewant up to date -- it is set when it matters:
at the end of go_looking().
Stop keeping track of the vertical screen position when searching for
something. If nothing is found, current_y doesn't change, and all the
incrementing/decrementing was a waste of time. If something is found
and it is onscreen, it is easy to calculate the new current_y. And if
something is found and it is offscreen, then current_y is irrelevant,
because we will be either centering the found occurrence (searching)
or putting it on the top or bottom line (bracket matching).
(The above does not take softwrapping into account, but neither did
the old code, so this doesn't introduce any new bugs.)
(Also, when the search wraps, and the viewport is away from head or
tail of the file, and the found occurrence is within the viewport,
then the incremented/decremented current_y would be way wrong, but
this didn't have any adverse effects as far as I could tell. It
seems that current_y is irrelevant in most cases.)
Add a third mode of scrolling, FLOWING, besides CENTERING and STATIONARY.
This is used for word and paragraph jumping (and for bracket matching,
but that worked correctly already), and only when focusing is FALSE.
The new mode prevents the screen from scrolling too many lines when
there are several blank lines at the bottom of the edit window and
the next word or paragraph is out of view.
This fixes https://savannah.gnu.org/bugs/?47194.
On iTerm2 on OS X, the Option+Arrow keys produce special sequences
that start with two escapes. Catch these sequences and interpret
them appropriately as WordLeft / WordRight / Home / End.
Signed-off-by: Mike Scalora <mike@scalora.org>
Signed-off-by: Thomas Rosenau <thomasr@fantasymail.de>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
When finding a misspelled word, the length of the match is simply the
length of that word, and its span in columns is simply the number of
columns that it occupies. Compute it thus directly.
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
When searching for a misspelled word takes a while, and the user
stops this search with ^C, then abort the spelling-checking session.
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
that is taking too long. This fixes Savannah bug #47439.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5776 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
(The measurable effect (during long searches, for example) is zero, though.)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5773 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
an operating directory is not the same as restricted mode.
(In restricted mode, the file browser is not available at all.)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5772 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
invalid escape sequence, and when entering a verbatim keystroke.
But leaving the cursor off during Unicode input, for extra feedback.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5771 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
anyway, and it will be placed back when it's needed: in the main loop.
This prevents a segfault laid bare by r5763: when trying, at startup,
to open a directory, there really is no open buffer yet.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5766 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
variable for a little optimization.
Openfile can never be NULL -- it should have been called openbuffer, and
before we start fiddling with the cursor, we will always have an open buffer.
Edittop might be NULL, but that's okay.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5763 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
a misspelled word twice. And deleting the piece of dead code that was meant
to do this. This fixes Savannah bug #47188.
When we've reached again the same line where we started and we find an
instance there, then this can only be /before or at/ the position from
where we started, otherwise we would have found it when we commenced
searching. And so... that little piece of dead code does absolutely
nothing -- it will never fire.
It's so nice... nano is full of Easter Eggs! :)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5760 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
using it when it's available (which it is on OS X systems).
This completes the fix for Savannah bug #47325.
Patch by Thomas Rosenau.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5759 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
been set to 'answer' in search_init() when 'answer' isn't empty, and when
'answer' /is/ empty we use 'last_search' anyway.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5755 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
deletion of words like the pressing of Backspace/Delete, so they don't
overwrite the lines you cut elsewhere and want to paste into the place
of the cut words.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5751 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and the next time a Search or Replace is run, this answer is overwritten
with an empty string.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5749 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
return with -2 when answer is empty, so when answer is empty
i cannot be zero.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5747 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
We will need this again when one day we make a toggle between
jumping to a directory and searching for a filename fragment,
just like the ^T toggle that exists in the Search / Go-to-line
menus. But for now, we don't need this.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5745 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
functions that could be executed -- other than the line-edition ones,
which are executed under do_prompt(). So the latter won't return
unless either it was cancelled or an answer was given. Also, if it
/had/ returned with a value bigger than zero, it tried to put back
the key sequence for do_gotolinecolumn_void(), which does not exist
in the MBROWSER menu, so this would not have done anything.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5744 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
the idea that it might have something to do with 'end_regex'.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5733 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
non-GNU systems. This is a partial fix for Savannah bug #47325.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5731 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
not for every added color, thus saving some 15 microseconds.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5729 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
a leading underscore as the only difference is not enough.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5726 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
comes first, so that a search can stop at the first match instead of always
having to run through the entire list.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5716 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
instead of the first syntax that matches a certain magic string
(forgotten in the previous commit).
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5705 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
name given on the command line, not from the name of the target file.
This fixes Savannah bug #47307.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5703 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
an rcfile ends or when an invalid syntax command is found.
This fixes Savannah bug #47207
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5696 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
to file extensions, but also to header lines and magic strings.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5690 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
the first element, and the insertion of a new element) directly.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5678 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
And not minding when the column number is zero or negative.
This partially fixes Savannah bug #47131.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5669 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
there is no need to put one in. Just trim the allocation.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5666 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* Add ability to kill the trailing spaces when justifying
code. New nanorc option kill_spaces_on_wrap, we'll see
whether this warrants a command line flahg or not.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5664 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
(Note that openfile cannot be NULL here. And in case it is,
nano should crash because DEBUG is enabled.)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5658 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
when the first Tab added the part that all matches have in common.
So now two Tabs in a row will always show the list of possible
completions -- if there /are/ any completions. Which means that
a second Tab will either: 1) do nothing, when the name is complete
and exists; 2) beep, when nothing in the current directory starts
with the current string; 3) show the list of matches.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5656 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
instead of in the given string. This fixes Savannah bug #47199.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5654 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
history. This fixes Savannah bug #47124 reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5653 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
This fixes Savannah bug #47129 reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5647 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and also when it is the first and only line.
This fixes Savannah bug #47153 reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5646 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
because 'allow_cntrls == FALSE' meant that controls were being filtered.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5644 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
iteration through search matches: showing them centered when found offscreen.
This fixes Savannah bug #47127.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5641 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
needed), so that it no longer shows in the help screen nor in the file list.
This fixes Savannah bug #47126.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5640 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
error messages upon reentry. And, if there are any messages,
allowing the user a little time to read them.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5632 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
With this option, nano would simply refuse to write to any symlinked file;
if anyone really used this option, they would certainly have complained.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5608 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
mentioning how to enter Unicode and that regular expressions are line oriented.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5605 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
This fixes a segfault reported in Savannah bug #47011.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5596 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
of the environment (which can lead to a root-owned .nano/ directory in
the invoking user's home directory). This addresses Ubuntu bug #1471459.
(See https://bugs.launchpad.net/ubuntu/+source/nano/+bug/1471459.)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5580 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
any more, not a SIGWINCH either. And deleting an always-FALSE 'if'.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5577 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
a setting or making an excursion to the file browser.
This fixes Savannah bug #46945.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5576 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
(So that most likely not more than two hundred plus a handful
will be written out. This was the easiest to implement.)
See https://lists.gnu.org/archive/html/nano-devel/2016-01/msg00050.html.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5571 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
This fixes Savannah bug #46904 reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5567 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
There's a bunch of return cases where we don't free the new full filename
which leads to leaks when writing out new files. One way to reproduce:
$ rm -f foo
$ nano foo
<hit enter>
<ctrl+o to save>
<ctrl+x to exit>
-> memory leak
Patch by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5563 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
This fixes Savannah bug #26977 -- a hang on start="^" end="$".
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5538 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
needed (for the sake of multiline regexes), instead of doing it always.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5524 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
needed, before doing a redraw of the current line.
This fixes Savannah bug #46794
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5523 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
as it colours some things wrong and is a glutton on time.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5513 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
changed buffer after all, as the buffer may not have a name yet.
This fixes Savannah bug #46752.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5512 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
there's an error saving history state at exit is pointless and annoying.
Just notify the user and move on.
Patch by Mike Frysinger, tweaked and extended by Benno.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5507 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Use plain AC_CHECK_HEADERS() instead, so ./configure will not check
for magic.h and zlib.h when --disable-libmagic is given.
Patch by Christian Weisgerber.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5505 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
routine isn't getting something from somewhere but just converting it.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5503 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
And making the checking for an impatient user into a separate routine.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5501 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
not just for the first. This fixes Savannah bug #46511.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5500 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
four different places. It is not a problem that the history routines
also use these functions, as history nodes will never equal filebot.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5491 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Users who want an immediate save, can bind the function 'savefile'.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5489 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
when trying to undo edits after an indentation change.
This works around Savannah bug #46591.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5474 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
making mistakes) when trying to undo edits after a justification.
This works around Savannah bug #45531.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5473 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Original file by Arturo Borrero Gonzalez.
This addresses Debian bug #805288.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5465 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
(Note that there can only be colorstrings when there /is/ a syntax,
so there is no need to check for the latter here.)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5452 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
also when the coloured part is horizontally scrolled off.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5451 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
directly on the statusbar instead of as an undid or redid message.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5442 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and checking for this just once for every burst of keystrokes.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5439 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
command line does not exist. This fixes Savannah bug #46503.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5436 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
ncurses for the keycodes. This addresses Debian bug #800681.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5434 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
This now mirrors unlink_opennode() and delete_opennode().
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5433 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
override the value of a "set fill" option in an rcfile.
This fixes Savannah bug #46492.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5428 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
because the latter behaves differently depending on the setting of autoindent.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5400 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
(Finally I understood what valgrind was complaining about.)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5398 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
more symmetrical: wrapped in add_undo() + update_undo() where needed.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5390 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and recalculating the mark's x coordinate only when the mark comes after it.
Also correcting the recalculation in one case.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5384 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
last action. Necessary for when typing text is broken by an undo+redo.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5379 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
writing out the file immediately, without prompting.
Patch by David Lawrence Ramsey.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5378 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
'u->mark_begin_lineno' is being used as the length of the insertion.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5375 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
instead of to the beginning of the preceding word, to match the
behaviour of Pico and of most other editors. It also rewrites
the entire routine.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5372 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
as that is the only known situation where things go wrong. This spares
all regular text a significant slowdown.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5370 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Apparently there is /some/ state somewhere after all. Don't have time
now to figure out where exactly.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5369 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
nor bothering with a separate initialization function when it's used only once.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5365 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Appending, Prepending, making Backups, and opening the File Browser.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5357 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
(It will always be false, so it is apparently unneeded.)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5355 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
has not been built in, since the default values are quite usable.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5348 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
without adding confusing single quotes to the Info document.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5346 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
the standard order, and giving the Savannah URL for bug reporting.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5344 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
--version, and to distinguish it more from the description of ^G.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5337 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
to clarify some keys and to see which ones can be rebound.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5336 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
from the cursor to the preceding or succeeding word start.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5334 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
two superfluous checks for the definition of a formatter.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5325 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
first asking for its name. Patch was suggested by Seiya Nuta.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5318 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
opening an empty buffer when the name of a directory is specified.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5304 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and avoiding warnings about too large bit shifts.
Patch by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5303 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Removing an unneeded condition -- 'added_magicline' can only be
true when NO_NEWLINES isn't.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5297 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
at the end-of-file; just adding a token undo item to be able to put the
cursor back at the very tail of the file.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5285 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
<ahref="#2.4">2.4. By subversion (for the brave).</a></p></blockquote>
<h2><ahref="#3">3. Installation and Configuration</a></h2>
<blockquote><p><ahref="#3.1">3.1. How do I install the RPM or DEB package?</a><br>
<ahref="#2.4">2.4. By git (for the brave).</a>
</p></blockquote>
<h3><ahref="#3">3. Installation and Configuration</a></h3>
<blockquote><p>
<ahref="#3.1">3.1. How do I install the RPM or DEB package?</a><br>
<ahref="#3.2">3.2. Compiling from source: WHAT THE HECK DO I DO NOW?</a><br>
<ahref="#3.3">3.3. Why does everything go into /usr/local?</a><br>
<ahref="#3.5">3.5. nano should automatically run strip on the binary when installing it!</a><br>
<ahref="#3.6">3.6. How can I make the executable smaller? This is too bloated!</a><br>
<ahref="#3.7">3.7. Tell me more about this multibuffer stuff!</a><br>
<ahref="#3.8">3.8. Tell me more about this verbatim input stuff!</a><br>
<ahref="#3.9">3.9. How do I make a .nanorc file that nano will read when I start it?</a></br>
<ahref="#3.9.1">3.9.1. How about in Win32?</a></p></blockquote>
<h2><ahref="#4">4. Running</a></h2>
<blockquote><p><ahref="#4.1">4.1. How do I open a file with a name beginning with '+' from the command line?</a><br>
<ahref="#4.2">4.2. Ack! My Backspace/Delete/Enter/Meta/double bucky key doesn't seem to work! What can I do?</a><br>
<ahref="#4.3">4.3. Ack! My numeric keypad's keys don't work properly when NumLock is off! What can I do?</a><br>
<ahref="#4.4">4.4. Ack! When I hold down a Meta key combination for a while, the character of the held key gets inserted now and then. What gives?</a><br>
<ahref="#4.5">4.5. How do I type the F13-F16 keys shown in the help browser? My keyboard only has F1-F12!</a><br>
<ahref="#4.6">4.6. nano crashes when I type <insert keystroke here>!</a><br>
<ahref="#4.7">4.7. nano crashes when I resize my window. How can I fix that?</a><br>
<ahref="#4.8">4.8. [version 1.3.12 and later] I'm using glibc 2.2.3, and nano crashes when I use color support or do regular expression searches. How can I fix that?</a><br>
<ahref="#4.9">4.9. [version 1.1.12 and earlier] Why does nano show ^\ in the shortcut list instead of ^J?</a><br>
<ahref="#4.10a">4.10a. [version 1.1.12 and earlier] When I type in a search string, the string I last searched for is already in front of my cursor! What happened?!</a><br>
<ahref="#4.10b">4.10b. [version 1.1.99pre1 and later] Hey, the search string behavior has reverted, it's now like Pico, what happened to the consistency?</a><br>
<ahref="#4.11">4.11. How do I make nano my default editor (in Pine, mutt, etc.)?</a><br>
<ahref="#4.12">4.12. I've compiled nano with color support, but I don't see any color when I run it!</a><br>
<ahref="#4.13">4.13. How do I select text for or paste text from the clipboard in an X terminal when I'm running nano in one and nano's mouse support is turned on?</a><br>
<ahref="#4.14">4.14. When I paste text into a document, each line gets indented further than the last. Why does nano do this, and how can I avoid it?</a><br>
<ahref="#4.15">4.15. On startup I get a message that says "Detected a legacy nano history file". Now older nano versions can't find my search history!</a></p></blockquote>
<h2><ahref="#5">5. Internationalization</a></h2>
<blockquote><p><ahref="#5.1">5.1. There's no translation for my language!</a><br>
<ahref="#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. Alt+Up does nothing on a Linux console. How can I make it scroll?</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. How do I remove an unwanted Byte Order Mark?</a><br>
<ahref="#4.4">4.4. Where did Ctrl+T in the Search menu go?</a><br>
<ahref="#4.5">4.5. How do I select text for or paste text from the clipboard when nano's mouse support is turned on?</a><br>
<ahref="#4.6">4.6. When I paste text into a document, each line gets indented further than the last. Why? And how can I stop this?</a><br>
<ahref="#4.7">4.7. When I paste from Windows into a remote nano, nano rewraps the lines. What gives?</a><br>
<ahref="#4.8">4.8. I've compiled nano with color support, but I don't see any color when I run it!</a><br>
<ahref="#4.9">4.9. How do I make nano my default editor (in Pine, mutt, git, ...)?</a><br>
</p></blockquote>
<h3><ahref="#5">5. Internationalization</a></h3>
<blockquote><p>
<ahref="#5.1">5.1. There's no translation for my language!</a><br>
<ahref="#5.2">5.2. I don't like the translation for <x> in my language. How can I fix it?</a><br>
<ahref="#5.3">5.3. What is the status of Unicode support?</a></p></blockquote>
<h2><ahref="#6">6. Advocacy and Licensing</a></h2>
<blockquote><p><ahref="#6.1">6.1. Why should I use nano instead of Pico?</a><br>
<ahref="#5.3">5.3. What is the status of Unicode support?</a>
</p></blockquote>
<h3><ahref="#6">6. Advocacy and Licensing</a></h3>
<blockquote><p>
<ahref="#6.1">6.1. Why should I use nano instead of Pico?</a><br>
<ahref="#6.2">6.2. Why should I use Pico instead of nano?</a><br>
<ahref="#6.3">6.3. What is so bad about the older Pine license?</a><br>
<ahref="#6.4">6.4. Okay, well, what mail program should I use then?</a></p></blockquote>
<ahref="#7.2">7.2. I want to send the development team a big load of cash (or just a thank you).</a><br>
<ahref="#7.3">7.3. How do I submit a bug report or patch?</a><br>
<ahref="#6.4">6.4. Okay, well, what mail program should I use then?</a>
</p></blockquote>
<h3><ahref="#7">7. Miscellaneous</a></h3>
<blockquote><p>
<ahref="#7.1">7.1. Where can I ask questions or send suggestions?</a><br>
<ahref="#7.2">7.2. How do I submit a bug report or patch?</a><br>
<ahref="#7.3">7.3. I want to send the development team a big load of cash (or just a thank you).</a><br>
<ahref="#7.4">7.4. How do I join the development team?</a><br>
<ahref="#7.5">7.5. Can I have write access to the subversion tree?</a></p></blockquote>
<h2><ahref="#8">8. ChangeLog</a></h2>
<ahref="#7.5">7.5. Can I have write access to the git tree?</a>
</p></blockquote>
<hrwidth="100%">
<h1><aname="1"></a>1. General</h1>
<h2><aname="1.1"></a>1.1 About this FAQ</h2>
<blockquote><p>This FAQ was originally written and maintained by Chris Allegretta <<ahref="mailto:chrisa@asty.org">chrisa@asty.org</a>>, who also happens to be the creator of nano. It was then maintained by David Lawrence Ramsey <<ahref="mailto:pooka109@gmail.com">pooka109@gmail.com</a>>. Maybe someone else will volunteer to maintain this FAQ someday, who knows...</p></blockquote>
<h2><aname="1.2"></a>1.2. How do I contribute to it?</h2>
<blockquote><p>Your best bet is to send it to the nano email address, <ahref="mailto:nano@nano-editor.org">nano@nano-editor.org</a> and if it is useful enough it will beincluded in future versions.</p></blockquote>
<h2><aname="1.3"></a>1.3. What is GNU nano?</h2>
<blockquote><p>GNU nano is designed to be a free replacement for the Pico text editor, part of the Pine email suite from <ahref="http://www.washington.edu/pine/">The University of Washington</a>. It aims to "emulate Pico as closely as possible and perhaps include extra functionality".</p></blockquote>
<h2><aname="1.4"></a>1.4. What is the history behind nano?</h2>
<h1id="1">1. General</h1>
<h3id="1.1">1.1. What is GNU nano?</h3>
<blockquote><p>GNU nano was designed to be a free replacement for the Pico text editor, part of the Pine email suite from <ahref="http://www.washington.edu/pine/">The University of Washington</a>. It aimed to "emulate Pico as closely as is reasonable and then include extra functionality".</p></blockquote>
<h3id="1.2">1.2. What is the history behind nano?</h3>
<blockquote><p>Funny you should ask!</p>
<p><b>In the beginning...</b></p>
<p>For years Pine was THE program used to read email on a Unix system. The Pico text editor is the portion of the program one would use to compose his or her mail messages. Many beginners to Unix flocked to Pico and Pine because of their well organized, easy to use interfaces. With the proliferation of GNU/Linux in the mid to late 90's, many University students became intimately familiar with the strengths (and weaknesses) of Pine and Pico.</p>
<p><b>Then came Debian...</b></p>
<p>The <ahref="http://www.debian.org/">Debian GNU/Linux</a> distribution, known for its strict standards in distributing truly "free" software (i.e. software with no restrictions on redistribution), would not include a binary package for Pine or Pico. Many people had a serious dilemma: they loved these programs, but the versions available at the time were not truly free software in the <ahref="http://www.gnu.org/philosophy/free-sw.html">GNU</a> sense of the word.</p>
<p>The <ahref="https://www.debian.org/">Debian GNU/Linux</a> distribution, known for its strict standards in distributing truly "free" software (i.e. software with no restrictions on redistribution), would not include a binary package for Pine or Pico. Many people had a serious dilemma: they loved these programs, but the versions available at the time were not truly free software in the <ahref="https://www.gnu.org/philosophy/free-sw.html">GNU</a> sense of the word.</p>
<p><b>The event...</b></p>
<p>It was in late 1999 when Chris Allegretta (our hero) was yet again complaining to himself about the less-than-perfect license Pico was distributed under, the 1000 makefiles that came with it and how just a few small improvements could make it the Best Editor in the World (TM). Having been a convert from Slackware to Debian, he missed having a simple binary package that included Pine and Pico, and had grown tired of downloading them himself.</p>
<p>Finally something snapped inside and Chris coded and hacked like a madman for many hours straight one weekend to make a (barely usable) Pico clone, at the time called TIP (Tip Isn't Pico). The program could not be invoked without a filename, could not save files, had no help text display, spell checker, and so forth. But over time it improved, and with the help of a few great coders it matured to the (hopefully) stable state it is today.</p>
<p>Finally something snapped inside and Chris coded and hacked like a madman for many hours straight one weekend to make a (barely usable) Pico clone, at the time called TIP (Tip Isn't Pico). The program could not be invoked without a filename, could not save files, had no help text display, spell checker, and so forth. But over time it improved, and with the help of a few great coders it matured to the (hopefully) stable state it is in today.</p>
<p>In February 2001, nano was declared an official GNU program by Richard Stallman. nano also reached its first production release on March 22, 2001.</p></blockquote>
<h2><aname="1.5"></a>1.5. Why the name change from TIP?</h2>
<h3id="1.3">1.3. Why the name change from TIP?</h3>
<blockquote><p>On January 10, 2000, TIP was officially renamed to nano because of a namespace conflict with another program called 'tip'. The original 'tip' program "establishes a full duplex terminal connection to a remote host", and was included with many older Unix systems (and newer ones like Solaris). The conflict was not noticed at first because there is no 'tip' utility included with most GNU/Linux distributions (where nano was developed).</p></blockquote>
<h2><aname="1.6"></a>1.6. What is the current version of nano?</h2>
<blockquote><p>The current stable version of nano *should* be 2.2.6. Of course, you should always check the nano homepage to see what the latest and greatest version is.</p></blockquote>
<h2><aname="1.7"></a>1.7. I want to read the man page without having to download the program!</h2>
<h3id="1.4">1.4. What is the current version of nano?</h3>
<blockquote><p>The current version of nano <i>should</i> be <b>9.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>
<h3id="1.5">1.5. I want to read the man page without having to download the program!</h3>
<p>You can also have a look at the <ahref="ftp://ftp.debian.org/debian/pool/main/n/nano/">Package Pool</a> to see all the available binary and source packages.</p>
<p>You can also have a look at the <ahref="http://ftp.debian.org/debian/pool/main/n/nano/">Package Pool</a> to see all the available binary and source packages.</p>
</blockquote>
<h2><aname="2.4"></a>2.4. By subversion (for the brave).</h2>
<blockquote><p>For the 'bleeding edge' current version of nano, you can use subversion to download the current source code. <b>Note:</b> believe it or not, by downloading code that has not yet stabilized into an official release, there could quite possibly be bugs, in fact the code may not even compile! Anyway, see <ahref="http://svn.savannah.gnu.org/viewvc/trunk/nano/README.SVN?root=nano&view=markup">the nano SVN document</a> for info on anonymous SVN access to the nano source.</p></blockquote>
<h3id="2.4">2.4. By git (for the brave).</h3>
<blockquote><p>For the "bleeding edge" current version of nano, you can use <b>git</b> to download the current source code. <i>Note:</i> 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.hacking">the hacking document</a> for info on getting and building nano from git.</p></blockquote>
<hrwidth="100%">
<h1><aname="3"></a>3. Installation and Configuration</h1>
<h2><aname="3.1"></a>3.1. How do I install the RPM or DEB package?</h2>
<blockquote><p>It's simple really! As root, type <b>rpm -Uvh nano-x.y.z-1.i386.rpm</b> if you have a RedHat-ish system or <b>dpkg -i nano_x.y.z-1.deb</b> if you have a Debian-ish system, where <b>x.y.z</b> is the release of nano. There are other programs to install packages, and if you wish to use those, knock yourself out.</p></blockquote>
<h2><aname="3.2"></a>3.2. Compiling from source: WHAT THE HECK DO I DO NOW?</h2>
<h1id="3">3. Installation and Configuration</h1>
<h3id="3.1">3.1. How do I install the RPM or DEB package?</h3>
<blockquote><p>It's simple really! As root, type <b>rpm -Uvh nano-x.y-1*.rpm</b> if you have a RedHat-ish system or <b>dpkg -i nano_x.y-1*.deb</b> if you have a Debian-ish system, where <b>x.y</b> is the version number of nano. There are other programs to install packages, and if you wish to use those, knock yourself out.</p></blockquote>
<h3id="3.2">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>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>
<pclass="indented"><b>cd nano-x.y/</b><br>
<b>./configure</b><br>
<b>make</b><br>
<b>make install</b>(as root, of course)</p></blockquote>
<h2><aname="3.3"></a>3.3. Why does everything go into /usr/local?</h2>
<b>make install</b> #(as root, of course)</p></blockquote>
<h3id="3.3">3.3. Why does everything go into /usr/local?</h3>
<blockquote><p>Well, that's what the <b>configure</b> script defaults to. If you wish to change this, simply do this:</p>
<p><b>./configure --prefix=/usr</b></p>
<p>to put nano into /usr/bin when you run <b>make install</b>.</p></blockquote>
<h2><aname="3.5"></a>3.5. nano should automatically run strip on the binary when installing it!</h2>
<blockquote><p>Actually, it does, but you have to use <b>make install-strip</b>. The default make install does not, and will not, run strip automatically.</p></blockquote>
<h2><aname="3.6"></a>3.6. How can I make the executable smaller? This is too bloated!</h2>
<p>This will put nano into /usr/bin when you run <b>make install</b>.</p></blockquote>
<h3id="3.4">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>
<h3id="3.5">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>
<b>--disable-wrapping</b> Disable all wrapping of text (and -w flag)</pre>
<p>There's also the <b>--enable-tiny</b> option which disables everything above, as well as some larger chunks of the program (like the marker code that you use with Control-^ to select text). Also, if you know you aren't going to be using other languages you can use <b>--disable-nls</b>to disable internationalization and save a few K to a few dozen K depending on if you have locale support on your system. And finally there's always good old <b>strip</b> to strip all debugging code and code that exists in libraries on your system.</p>
<p>With<b>--disable-wrapping-as-root</b> you can disable any hard-wrapping by default when the user is root, useful to prevent accidentally changing long lines in system configuration files.</p>
<b>--disable-browser</b> Disable the built-in file browser
<b>--disable-color</b> Disable color and syntax highlighting
<b>--disable-comment</b> Disable the comment/uncomment function
<b>--disable-extra</b> Disable the easter egg
<b>--disable-formatter</b> Disable the formatting tool
<b>--disable-help</b>Disable the built-in help texts
<b>--disable-histories</b>Disable the saving of search strings and cursor positions
<b>--disable-justify</b> Disable the justify/unjustify functions
<b>--disable-libmagic</b> Disable the use of libmagic for determining a file's syntax
<b>--disable-linenumbers</b> Disable line numbering
<b>--disable-linter</b>Disable the linting tool
<b>--disable-mouse</b> Disable mouse support
<b>--disable-multibuffer</b> Disable the opening of multiple file buffers
<b>--disable-nanorc</b> Disable the use of .nanorc files
<b>--disable-operatingdir</b> Disable the setting of an operating directory
<b>--disable-speller</b> Disable the spell-checking tool
<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 undo/redo code and the code for selecting text). Also, if you know you don't need other languages, you can use <b>--disable-nls</b> to disable internationalization and save a few kilobytes. And finally, there's always good old <b>strip</b> to remove all unneeded symbols.</p>
</blockquote>
<h2><aname="3.7"></a>3.7. Tell me more about this multibuffer stuff!</h2>
<blockquote><p>To use multiple file buffers, you must be using nano 1.1.0 or newer, and you must not have configured it with <b>--disable-multibuffer</b> nor with <b>--enable-tiny</b> (use <b>nano -V</b> to check the compilation options). Then when you want to insert a file into its own buffer instead of into the current file, just hit <b>Meta-F</b>, then insert the file as normal with<b>^R</b>. If you always want files to be loaded into their own buffers, use the <b>--multibuffer</b> or <b>-F</b> flag when you invoke nano.</p>
<p>You can move between the buffers you have open with the <b>Meta-<</b>and<b>Meta-></b> keys, or more easily with<b>Meta-,</b> and <b>Meta-.</b> (clear as mud, right? =-). When you have more than one file buffer open, the ^X shortcut will say "Close", instead of the normal "Exit" when only onebuffer is open.</p></blockquote>
<h2><aname="3.8"></a>3.8. Tell me more about this verbatim input stuff!</h2>
<blockquote><p>To use verbatim input, you must be using nano 1.3.1 or newer. When you want to insert a literal character into the file you're editing, such as a control character that nano usually treats as a command, first press <b>Meta-V</b> (if you're not at a prompt, you'll get the message "Verbatim Input"), then press the key(s) that generate the character you want.</p>
<p>Alternatively, if you've enabled Unicode support (see section <ahref="#5.3">5.3</a>), you can press <b>Meta-V</b> and then type a six-digit hexadecimal code (from 000000 to 10FFFF, case-insensitive), and the character with the corresponding value will be inserted instead. The prompt will change to "Unicode Input" when you do this.</p></blockquote>
<h2><aname="3.9"></a>3.9. How do I make a .nanorc file that nano will read when I start it?</h2>
<blockquote><p>It's not hard at all! But, your version of nano must not have been compiled with <b>--disable-nanorc</b>, and must be version 1.1.12 or newer (use nano -V to check your version and compiled features). Then simply copy the <b>nanorc.sample</b> that came with the nano source or your nano package (most likely in /usr/doc/nano) to .nanorc in your home directory. If you didn't get one, the syntax is simple. Flags are turned on and off by using the word <b>set</b> and the getopt_long flag for the feature, for example "set nowrap" or "set suspend".</p></blockquote>
<h2><aname="3.9.1"></a>3.9. How about in Win32?</h2>
<blockquote><p>If you're using the official nano .zip file and have extracted all the files, you should take the filenano.rc and place it somewhere on your Win32 system (for example if you have write permission to do so, at the top of C:\). Then you must create an Environment variable called HOME which points to the directory where you put nano.rc. In Windows XP, you can get to Environment variables by right-clicking "My Computer" either on the desktop or in the Start Menu, and selecting Properties. This should bring up the System Properties panel. Then click the Advanced Tab, and there should be a button called Environment Variables. Click that to bring up the Environment Variables section. Now, under User Variables you should be able to click the New button, and make a new Variables Name called HOME, with the Variable Value of whatever path you copied nano.rc into (just the directory name; don't add nano.rc onto the end).</p>
<p>We're still working on documentation for enabling synax highlighting on Win32; please bear with us.</p>
<p>Note that the nano.rc file must remain Unix-formated in order for nano to understand it. In other words, you should probably use only nano to edit its config file. Other programs like Wordpad and Notepad will convert the file to DOS format when saving, and the latter does not even properly read Unix-formatted files to begin with.</p></blockquote>
<h3id="3.6">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>.</p>
<p>If you want files to be loaded always 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. (Since nano-9.2 these options are named <b>--newbuffer</b> and <b>set newbuffer</b>.)</p>
<p>You can switch between open buffers with <b>Meta-,</b> and <b>Meta-.</b> (Alt+comma and Alt+period).</p>
<p>When you have more than one buffer open, the help lines will say "<i>Close</i>" instead of "<i>Exit</i>" for the <b>^X</b> shortcut.</p></blockquote>
<h3id="3.7">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>
<h3id="3.8">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>
<h3id="3.9">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 reads <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 simply configure your nano with <b>--sysconfdir=/etc</b>.</p></blockquote>
<hrwidth="100%">
<h1><aname="4"></a>4. Running</h1>
<h2><aname="4.1"></a>4.1. How do I open a file with a name beginning with '+' from the command line?</h2>
<blockquote><p>If a command-line option that begins with '+' is followed by another option, the former is always treated as a starting line and column number, and the latter is always treated as a filename. If a command-line option that begins with '+' isn't followed by another option, it's always treated as a filename. Examples:</p>
<p>To open '+filename.txt' starting on line 1: <b>nano +filename.txt</b><br>
To open '+filename.txt' starting on line 10: <b>nano +10 +filename.txt</b><br>
To open '+filename.txt' starting on line 1, column 20: <b>nano +,20 +filename.txt</b><br>
To open '+filename.txt' starting on line 10, column 20: <b>nano +10,20 +filename.txt</b><br>
To open '+filename.txt' starting on line 1 and 'filename.txt' starting on line 40 (if nano has been compiled with multibuffer support): <b>nano +1 +filename.txt +40 filename.txt</b></p></blockquote>
<h2><aname="4.2"></a>4.2. Ack! My Backspace/Delete/Enter/Meta/double bucky key doesn't seem to work! What can I do?</h2>
<blockquote><p>Try setting your $TERM variable to 'vt100'. nano doesn't yet support every term entry under the sun.</p>
<p>Bourne shell users (bash and sh): <b>export TERM=vt100</b><br>
C Shell users (tcsh and csh): <b>setenv TERM vt100</b></p></blockquote>
<h2><aname="4.3"></a>4.3. Ack! My numeric keypad's keys don't work properly when NumLock is off! What can I do?</h2>
<blockquote><p>You can use the <b>-K</b> or <b>--rebindkeypad</b> option on the command line, or add the line <b>set rebindkeypad</b> to your .nanorc. However, nano's mouse support won't work properly if you do any of these things.</p></blockquote>
<h2><aname="4.4"></a>4.4. Ack! When I hold down a Meta key combination for a while, the character of the held key gets inserted now and then. What gives?</h2>
<blockquote><p>This is a bug in the terminal, not in nano. When a key is repeating faster than nano can process it, the keyboard buffer becomes full and starts dropping incoming keystrokes. Unfortunately, it doesn't just drop whole keystrokes; it can also drop parts of multibyte key combinations, resulting in nano's receiving a wrong key.</p></blockquote>
<h2><aname="4.5"></a>4.5. How do I type the F13-F16 keys shown in the help browser? My keyboard only has F1-F12!</h2>
<blockquote><p>It depends on the terminal type you're using. On some terminals, such as the FreeBSD console, xterm, konsole, and gnome-terminal, Shift-F1 to Shift-F4 will generate F13 to F16. On other terminals, such as the Linux console, rxvt, and Eterm, Shift-F3 to Shift-F6 will generate F13 to F16.</p></blockquote>
<h2><aname="4.6"></a>4.6. nano crashes when I type <insert keystroke here>!</h2>
<blockquote><p>If you aren't trying some bizarre keystroke combination with some bizarre $TERM entry, chances are you have found a bug. You are welcome to submit it to the <ahref="mailto:nano-devel@gnu.org">nano-devel</a> list or in the <ahref="https://savannah.gnu.org/bugs/?group=nano">bug database</a> on Savannah.</p></blockquote>
<h2><aname="4.7"></a>4.7. nano crashes when I resize my window. How can I fix that?</h2>
<blockquote><p>Older versions of nano had this problem, please upgrade to a newer version (at least 0.9.9, but 2.2.6 is recommended).</p></blockquote>
<h2><aname="4.8"></a>4.8. [version 1.3.12 and later] I'm using glibc 2.2.3, and nano crashes when I use color support or do regular expression searches. How can I fix that?</h2>
<blockquote><p>It's a bug in glibc 2.2.3. You should upgrade to at least glibc 2.2.4.</p></blockquote>
<h2><aname="4.9"></a>4.9. [version 1.1.12 and earlier] Why does nano show ^\ in the shortcut list instead of ^J?</h2>
<blockquote><p>The help (^G) and justify (^J) functions were among the last to be written. To show the improvements that nano had over Pico (go to line number, and replace), ^_ and ^\ were put on the shortcut list. Later, ^G came back in place of ^_ as it proved to be very valuable for new Unix users.</p></blockquote>
<h2><aname="4.10a"></a>4.10a. [version 1.1.12 and earlier] When I type in a search string, the string I last searched for is already in front of my cursor! What happened?!</h2>
<blockquote><p>Since nano version 0.9.20, the default was to have a completely consistent user interface across all user input functions. This means that regardless of whether you're being asked for a filename to insert or write, or a string to search for, the previous value is already inserted before the cursor.</p></blockquote>
<h2><aname="4.10b"></a>4.10b. [version 1.1.99pre1 and later] Hey, the search string behavior has reverted, it's now like Pico, what happened to the consistency?</h2>
<blockquote><p>It was decided that consistency was nice, but people are used to Pico's inconsistent behavior. Also, in version 1.1.99pre1, search and replace history was introduced. If you wish to edit your previous search/replace entry (or any previous entry), you can do so by hitting the up arrow to cycle through your history. This method allows the best of both worlds: You don't need to erase the previous string if you want to enter a new one, but you can with one keystroke recall previous entries for editing. Therefore there is now no "Pico mode", nano is and has always been a Pico <b>clone</b>, and clones by default should be compatible.</p></blockquote>
<h2><aname="4.11"></a>4.11. How do I make nano my default editor (in Pine, mutt, etc.)?</h2>
<h1id="4">4. Running</h1>
<h3id="4.1">4.1. Alt+Up does nothing on a Linux console. How can I make it scroll?</h3>
<blockquote><p>On Debian and its derivatives, the <b>Alt+Up</b> keystroke on a Linux console
produces by default a 'KeyboardSignal', which normally does absolutely nothing and is useless
for the average user. To get the keystroke to do what it ought to do (scroll the viewport
one row up), run this in a Linux console:</p>
<pclass="indented"><b>dumpkeys --full | sed s/KeyboardSignal/Up/ | sudo loadkeys -</b></p>
<p>You will need to run this command whenever you first switch to a Linux console.</p>
<p>Or you can (as root) execute the following little script just once:</p>
<pclass="indented"><b>for file in /etc/console-setup/cached*.kmap.gz; do<br>
<h3id="4.2">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-Home: \033[1;3H
URxvt.keysym.M-End: \033[1;3F
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~
URxvt.keysym.S-Page_Up: \033[5;2~
URxvt.keysym.S-Page_Down: \033[6;2~</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>
<h3id="4.3">4.3. How do I remove an unwanted Byte Order Mark?</h3>
<blockquote><p>To check whether a file contains a Byte Order Mark (BOM), open the file and type <b>Ctrl+Home</b>. If there is a BOM, the status bar will tell you so. Now type <b>Delete</b> to remove the BOM, and <b>^S</b> to save the file.</p>
<p>If you've accidentally deleted a Byte Order Mark from a file that needs it, and you want to restore it, then type: <b>Ctrl+Home Alt+V feff Enter</b>. Verify that the BOM is back with <b>Ctrl+Home</b>, and save the file with <b>^S</b>. (Note that on Unix, files should not contain a BOM.)</p></blockquote>
<h3id="4.4">4.4. Where did Ctrl+T in the Search menu go?</h3>
<blockquote><p>Actually, the <b>Ctrl+T</b> toggle is still there — it's just not listed in the help lines nor in the help text, and the function it executes cannot be rebound to another key. If you do want to use another key, you can emulate the rebinding with something like this in your .nanorc:</p>
<pre>
bind ^E "{cancel}{gotoline}" search
bind ^E "{cancel}{whereis}" gotoline</pre>
<p>But since forever there are also direct keystrokes for jumping to a line number: <b>Ctrl+/</b> and <b>Alt+G</b> in the main menu.</p></blockquote>
<h3id="4.5">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>
<h3id="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?</h3>
<blockquote><p>You have the <i>autoindent</i> feature turned on. Hit <b>Meta-I</b> to turn it off, paste your text, and then hit <b>Meta-I</b> again to turn it back on.</p>
<p><i>Update:</i> Since version 4.8, nano suppresses auto-indentation during a paste (when your terminal understands <ahref="https://en.wikipedia.org/wiki/Bracketed-paste">bracketed pastes</a>), so you no longer need to toggle it off and on manually.</p></blockquote>
<h3id="4.7">4.7. When I paste from Windows into a remote nano, nano rewraps the lines. What gives?</h3>
<blockquote><p>When pasting from Windows, in some situations linefeeds are sent instead of carriage returns (Enters). And linefeeds are <b>^J</b>s, which make nano justify (rewrap) the current paragraph. To prevent these linefeeds from causing these unwanted justifications, add this line to your .nanorc on the remote Linux box: <b>unbind ^J main</b> or <b>bind ^J enter main</b>, depending on whether the paste contains CR + LF or only LF.</p>
<p><i>Update:</i> Since version 4.8, nano ignores linefeed characters in a paste (when your terminal understands <ahref="https://en.wikipedia.org/wiki/Bracketed-paste">bracketed pastes</a>), so you no longer need the above workaround.</p></blockquote>
<h3id="4.8">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>
<h3id="4.9">4.9. How do I make nano my default editor (in Pine, mutt, git, ...)?</h3>
<blockquote><p>You need to make nano your $EDITOR. If you want this to be saved, you should put a line like this in your <b>.bashrc</b> if you use bash (or <b>.zshrc</b> if you believe in zsh):</p>
<p><b>export EDITOR=/usr/local/bin/nano</b></p>
<p>or, if you use tcsh, put this in your <b>.cshrc</b> file:</p>
<p>Change /usr/local/bin/nano to wherever nano is installed on your system. Type "which nano" to find out. This will not take effect until the next time you log in. So log out and back in again.</p>
<p>Then, on top of that, if you use Pine, you must go into setup (type <b>S</b> at the main menu), and then configure (type <b>C</b>). Hit Enter on the lines that say:</p>
<p>Then exit (<b>E</b>) and select Yes (<b>Y</b>).</p>
<p>If you're a mutt user, you should see an effect immediately the next time you log in. No further configuration is needed. However, if you want to let people know you use nano to compose your email messages, you can put a line like this in your <b>.muttrc</b>:</p>
<p><b>my_hdr X-Composer: nanox.y.z</b></p>
<p>Again, replace x.y.z with the version of nano you use.</p></blockquote>
<h2><aname="4.12"></a>4.12. I've compiled nano with color support, but I don't see any color when I run it!</h2>
<blockquote><p>If you want nano to actually use color, you have to specify the color configurations you want it to use in your .nanorc. Several example configurations are in the <b>doc/syntax</b> subdirectory of the nano source, which are normally installed to <b>/usr/local/share/nano</b>. To enable all of them, uncomment the line <b># include "/usr/local/share/nano/*.nanorc"</b> in your nanorc. See also section <ahref="#3.9">3.9</a>.</p></blockquote>
<h2><aname="4.13"></a>4.13. How do I select text for or paste text from the clipboard in an X terminal when I'm running nano in one and nano's mouse support is turned on?</h2>
<blockquote><p>Try holding down the Shift key and selecting or pasting the text as you normally would.</p></blockquote>
<h2><aname="4.14"></a>4.14. When I paste text into a document, each line gets indented further than the last. Why does nano do this, and how can I avoid it?</h2>
<blockquote><p>You have the autoindent feature turned on. Hit Meta-I to turn it off, paste your text, and then hit Meta-I again to turn it back on.</p></blockquote>
<h2><aname="4.15"></a>4.15. On startup I get a message that says "Detected a legacy nano history file". Now older nano versions can't find my search history!</h2>
<blockquote><p>In nano 2.3.0, cursor-position history was introduced, and both history files now reside under a .nano directory in your home. nano was trying to move this file into the new location so it could continue to use it. This means that if you try and use an earlier version of nano, it will be unable to see your current search history. To fix this, run the following commands:<br>
<p>Note the <b>+1</b> at the end — it makes nano start always at the top of the edit window. The guidestripe helps you keep the text within a reasonable width.</blockquote>
<hrwidth="100%">
<h1><aname="5"></a>5. Internationalization</h1>
<h2><aname="5.1"></a>5.1. There's no translation for my language!</h2>
<blockquote><p>On June of 2001, GNU nano entered the <ahref="http://translationproject.org/html/welcome.html">Translation Project</a> and since then, translations should be managed from there.</p>
<p>If there isn't a translation for your language, you could ask <ahref="http://translationproject.org/team/">your language team</a> to translate nano, or better still, join that team and do it yourself. Joining a team is easy. You just need to ask the team leader to add you, and then send a<ahref="http://translationproject.org/disclaim.txt">translation disclaimer to the FSF</a> (this is necessary as nano is an official GNU package, but it does <b>not</b> mean that you transfer the rights of your work to the FSF, it's just so the FSF can legally manage them).</p>
<p>In any case, translating nano is very easy. Just grab the latest <b>nano.pot</b> file listed on<ahref="http://translationproject.org/domain/nano.html">nano's page</a> at the TP, and translate each <b>msgid</b>line into your native language on the<b>msgstr</b>line. When you're done, you should send it to the TP's central po repository.</p></blockquote>
<h2><aname="5.2"></a>5.2. I don't like the translation for <x> in my language. How can I fix it?</h2>
<blockquote><p>The best way would probably be to send an e-mail to the team's mailing listed mentione in the <code>Language-Team:</code> field in the <b><your_language>.po</b> file with your suggested corrections, and then they can make the changes reach the nano-devel list.</p></blockquote>
<h2><aname="5.3"></a>5.3. What is the status of Unicode support?</h2>
<blockquote><p>In version 1.3.12 or later, Unicode should be usable. With your terminal, locale (LC_ALL and similar environment variables), and encoding configured to properly support UTF-8, you should be able to enter and save Unicode text.</p></blockquote>
<h1id="5">5. Internationalization</h1>
<h3id="5.1">5.1. There's no translation for my language!</h3>
<blockquote><p>In June 2001, GNU nano entered the<ahref="https://translationproject.org/html/welcome.html">Translation Project</a> and since then, translations should be managed from there.</p>
<p>If there isn't a translation for your language, you could ask<ahref="https://translationproject.org/team/">your language team</a> to translate nano, or better still, join that team and do it yourself. Joining a team is easy. You just need to ask the team leader to add you, and then send a <ahref="https://translationproject.org/disclaim.txt">translation disclaimer to the FSF</a>(this is necessary as nano is an official GNU package, but it does<b>not</b>mean that you transfer the rights of your work to the FSF, it's just so the FSF can legally manage them).</p>
<p>In any case, translating nano is easy. Just grab the latest <b>nano.pot</b> file listed on <ahref="https://translationproject.org/domain/nano.html">nano's page</a> at the TP, and translate each <b>msgid</b> line into your native language on the <b>msgstr</b>line. When you're done, you should send it to the TP's central PO-file repository.</p></blockquote>
<h3id="5.2">5.2. I don't like the translation for <x> in my language. How can I fix it?</h3>
<blockquote><p>The best way is to send an e-mail with your suggested corrections to the team's mailing list. The address is mentioned in the <code>Language-Team:</code> field in the relevant PO file. The team leader or the assigned translator can then make the changes reach the nano-devel list.</p></blockquote>
<h3id="5.3">5.3. What is the status of Unicode support?</h3>
<blockquote><p>Unicode should be fully usable nowadays. When the encoding of your terminal is set to UTF-8, and your locale (mainly the LANG environment variable) is UTF-8 too, then you should be able to read, enter and save Unicode text.</p></blockquote>
<hrwidth="100%">
<h1><aname="6"></a>6. Advocacy and Licensing</h1>
<h2><aname="6.1"></a>6.1. Why should I use nano instead of Pico?</h2>
<blockquote><p>There are many reasons to use nano instead of Pico. A more complete list can be found at the <ahref="http://www.nano-editor.org/">nano homepage</a>.</p></blockquote>
<h2><aname="6.2"></a>6.2. Why should I use Pico instead of nano?</h2>
<blockquote><p>Again, check out the <ahref="http://www.nano-editor.org/">nano homepage</a> for a good summary of reasons. It really is a matter of personal preference as to which editor you should use. If you're the type of person who likes using the original version of a program, then Pico is the editor for you. If you don't mind sacrificing mailer integration with Pine, and are looking for a few more features, as well as a 'better' license in terms of adding your own changes, nano is the way to go.</p><p>Note that the last of these no longer applies to the new version of Pine, <ahref="http://www.washington.edu/alpine/">Alpine</a>, which is under the Apache License, version 2.0.</p></blockquote>
<h2><aname="6.3"></a>6.3. What is so bad about the older Pine license?</h2>
<blockquote><p>The U of W license for older versions of Pine and Pico is not considered truly Free Software according to both the Free Software Foundation and the <ahref="http://www.debian.org/social_contract#guidelines">Debian Free Software Guidelines</a>. The main problem regards the limitations on distributing derived works: according to UW, you can distribute their software, and you can modify it, but you can not do both, i.e. distribute modified binaries.</p></blockquote>
<h2><aname="6.4"></a>6.4. Okay, well, what mail program should I use then?</h2>
<blockquote><p>If you are looking to use a Free Software program similar to Pine, and Emacs is not your thing, you should definitely take a look at <ahref="http://www.mutt.org/">mutt</a>. It is a full-screen, console based mail program that actually has a lot more flexibility than Pine, but has a keymap included in the distribution that allows you to use the same keystrokes as Pine would to send and receive mail. It's also under the GNU General Public License, version 2.0.<P>
Of course, due to the license change you can now use the<AHREF="http://www.washington.edu/alpine/">Alpine distribution</A> of PINE as it is now considered Free Software, but you would be sacrificing many of nano's features to do so.</p></blockquote>
<h1id="6">6. Advocacy and Licensing</h1>
<h3id="6.1">6.1. Why should I use nano instead of Pico?</h3>
<blockquote><p>If you want features like undo/redo, syntax highlighting, line numbers, soft-wrapping, opening multiple files at once, an interface localized to your language, or search and replace with support for regular expressions, then you want nano.</p></blockquote>
<h3id="6.2">6.2. Why should I use Pico instead of nano?</h3>
<blockquote><p>If you use your editor only to write emails or other texts and have no need for the above-mentioned features, then Pico will do fine for you.</p></blockquote>
<h3id="6.3">6.3. What is so bad about the older Pine license?</h3>
<blockquote><p>The U of W license for older versions of Pine and Pico is not considered truly Free Software according to both the Free Software Foundation and the <ahref="https://www.debian.org/social_contract#guidelines">Debian Free Software Guidelines</a>. The main problem regards the limitations on distributing derived works: according to UW, you can distribute their software, and you can modify it, but you can not do both, i.e. distribute modified binaries.</p></blockquote>
<h3id="6.4">6.4. Okay, well, what mail program should I use then?</h3>
<blockquote><p>If you are looking to use a Free Software program similar to Pine, and Emacs is not your thing, you should definitely take a look at<ahref="http://www.mutt.org/">mutt</a>. It is a full-screen, console based mail program that actually has a lot more flexibility than Pine, but has a keymap included in the distribution that allows you to use the same keystrokes as Pine would to send and receive mail. It's also under the GNU General Public License, version 2.0.</p>
<p>Of course, due to the license change you can now use the <ahref="http://www.washington.edu/alpine/">Alpine distribution</a> of PINE as it is now considered Free Software, but you would be sacrificing many of nano's features to do so.</p></blockquote>
<blockquote><p>There are three mailing lists for nano hosted at <ahref="http://savannah.gnu.org/">Savannah</a>: info-nano, help-nano and nano-devel. info-nano is a very low traffic list where new versions of nano are announced (surprise!). help-nano is for getting help with the editor without needing to hear all of the development issues surrounding it. nano-devel is a normally low, sometimes high traffic list for discussing the present and future development of nano. Here are links to where you can sign up for a given list:</p>
<h2><aname="7.2"></a>7.2. I want to send the development team a big load of cash (or just a thank you).</h2>
<blockquote><p>That's fine. Send it <ahref="mailto:nano-devel@gnu.org">our way</a>! Better yet, fix a <ahref="https://savannah.gnu.org/bugs/?group=nano">bug</a> in the program or implement a <ahref="http://www.nano-editor.org/dist/v2.3/TODO">cool feature</a> and send us that instead (though cash is fine too).</p></blockquote>
<h2><aname="7.3"></a>7.3. How do I submit a bug report or patch?</h2>
<h1id="7">7. Miscellaneous</h1>
<h3id="7.1">7.1. Where can I ask questions or send suggestions?</h3>
<blockquote><p>There are three mailing lists for nano hosted at<ahref="https://savannah.gnu.org/">Savannah</a>: info-nano, help-nano and nano-devel. info-nano is a very low traffic list where new versions of nano are announced (surprise!). help-nano is for getting help with the editor without needing to hear all of the development issues surrounding it. nano-devel is a normally low, sometimes high traffic list for discussing the present and future development of nano. Here are links to where you can sign up for a given list:</p>
<h3id="7.2">7.3. How do I submit a bug report or patch?</h3>
<blockquote>
<p>The best place to submit bugs is to the <ahref="https://savannah.gnu.org/bugs/?group=nano">Savannah bug tracker</a> as you can check whether the bug you are submitting has already been submitted.
<p>Please submit patches for nano via the <ahref="https://savannah.gnu.org/patch/?group=nano">Savannah project's patch manager</a> for the nano project.</p></blockquote>
<h2><aname="7.4"></a>7.4. How do I join the development team?</h2>
<blockquote><p>The easiest way is to consistently send in good patches that add some needed functionality, fix a bug or two, and/or make the program more optimized/efficient. Then ask nicely and you will probably be added to the Savannah development list and be given SVN write access after a while. There is a lot of responsibility that goes along with being a team member, so don't think it's just something to add to your resume.</p></blockquote>
<h2><aname="7.5"></a>7.5. Can I have write access to the subversion tree?</h2>
<blockquote><p>Re-read Section <ahref="#7.4">7.4</a> and you should know the answer.</p></blockquote>
<h2><aname="8"></a>8. ChangeLog</h2>
<blockquote><p>2014/04/24 - A bunch of small fixes and updates. (Benno)<br>
2009/11/30 - Update various bits for nano 2.2.x. (DLR)<br>
2009/11/18 - Typo fix. (j.mader@gmail.com)<br>
2008/03/16 - Update docs to refer to subversion instead of CVS, add more words about Alpine, and refer to Savannah for bugs and patches. (chrisa)<br>
2007/12/09 - Add minor punctuation and wording fixes, and update various sections to account for Alpine. (DLR)<br>
2007/08/26 - Update links to the Free Translation Project. (DLR)<br>
2007/07/29 - Update RPM links for nano 2.0.x. (DLR)<br>
2007/04/18 - Add a new section 4.14 to explain how autoindent affects pasted text. (John M. Gabriele, minor tweaks by DLR)<br>
2007/04/04 - Update email address. (DLR)<br>
2007/01/01 - Update section 4.1 to describe how to open files with names beginning with '+' at specified columns as well as lines. (DLR)<br>
2006/11/25 - Add miscellaneous wording and capitalization fixes. (DLR)<br>
2006/10/28 - Update various links for the 2.0 branch of nano. (DLR)<br>
2006/10/06 - Update the question in section 4.13 to match the version of it in the answer section. (DLR)<br>
2006/07/25 - Update section 5.3 again to not state "the latest development version" before 1.3.12, as it's no longer accurate. Also add some minor spacing fixes. (DLR)<br>
2006/06/12 - Update section 5.3, due to the display fix for two-column Unicode characters. (DLR)<br>
2006/06/05 - Add a new section 4.8, and move all section 4 entries after it down one number, to explain how to deal with glibc 2.2.3's crashes involving extended regular expressions. (DLR)<br>
2006/06/04 - Add minor punctuation, wording, and typo fixes. (DLR)<br>
2006/05/27 - Update section 3.8 to mention the new "Unicode Input" prompt, and how Unicode input only works when Unicode support is enabled. (DLR)<br>
2006/05/12 - Remove section 4.4, and move all section 4 entries after it up one number, since it no longer applies. Meta-] and Meta-[ are no longer used to indent and unindent marked text, since they require that the bracket matching key change to Ctrl-], which is used as the telnet escape key (found by Chris). Also, make the link to the nano CVS page a bit more readable. (DLR)<br>
2006/05/08 - Add a new section 4.5, and move all section 4 entries after it down one number, to explain a problem that can occur when holding down keys to generate Meta sequences. Also add a few more capitalization and wording fixes. (Benno Schulenberg, minor tweaks by DLR)<br>
2006/05/01 - Add a new section 4.4, and move all section 4 entries after it down one number, to explain how to deal with problems typing Meta-[. Also add a few capitalization and wording fixes. (DLR)<br>
2006/04/14 - Clarify section 1.4: help menu -> help text display. (DLR, suggested by Benno Schulenberg)<br>
2006/03/16 - Update the Free Translation Project's address, change the character set to UTF-8, and remove broken links to contributed RedHat nano packages. (DLR)<br>
2005/11/21 - Clarify section 5.3 to better explain how to enable Unicode support, and remove the mention of quirks, since they turned out to not be a nano problem. (Mike Frysinger and DLR)<br>
2005/11/19 - Add a new section 5.3 to explain the status of nano's Unicode support. (Mike Frysinger, minor tweaks by DLR)<br>
2005/08/27 - Update email address. (DLR)<br>
2005/08/10 - Add a new section 4.3, and move all section 4 entries after it down one number, to explain how to deal with numeric keypad problems. (DLR)<br>
2005/08/08 - Update section 3.8 to mention that verbatim input mode now takes a six-digit hexadecimal number. (DLR)<br>
2005/07/04 - Update section 4.10 to mention that pasting from the X clipboard via the middle mouse button also works when the Shift key is used. (DLR)<br>
2005/06/15 - Update description of --enable-extra, and add missing line breaks. (DLR)<br>
2005/06/13 - Minor capitalization and wording fixes. (DLR)<br>
2005/06/08 - Updated section 1.1 to mention the current maintainer. (DLR)<br>
2005/03/09 - Added question about opening files with names beginning with '+'s, and added a few more miscellaneous cosmetic fixes. (DLR)<br>
2005/01/03 - Removed now-inaccurate note about verbatim input's not working at prompts, and update its description to mention that it handles hexadecimal values now. (DLR)<br>
2004/11/21 - Listed sh as an example of a Bourne shell. (DLR)<br>
2004/11/05 - Fixed inaccuracy: Pico compatibility mode was made the default in nano 1.1.99pre1, not 1.2.2. Also added question about how to type F13-F16 on terminals lacking keys past F12 (suggested by Chris), question about how to select text for the clipboard in X terminals with nano's mouse support turned on (answer found by Joseph Birthisel), and misc. fixes and link updates. (DLR)<br>
2004/04/07 - Removed NumLock glitch question, as it's no longer needed. (DLR)<br>
2004/01/30 - Fixed inaccuracy: multibuffer mode was first in nano 1.1.0, not 1.1.12. (DLR)<br>
2003/12/31 - Added question about the new verbatim input function, and a few minor fixes. Removed reference to "set pico" (DLR).<br>
2003/07/02 - Added question about nano's not showing color when it's compiled with color support (DLR; suggested by Jordi).<br>
2003/02/23 - Updated RPM links for nano 1.2.x (DLR).<br>
2003/01/16 - Split section 4.5 into 4.5a and 4.5b for search string behavior. Added --enable-all docs.<br>
2002/12/28 - More misc. fixes (David Benbennick, DLR).<br>
2002/10/25 - Misc. fixes and link updates (DLR).<br>
2002/09/10 - Another typo fix (DLR).<br>
2002/05/15 - Typo fix (DLR).<br>
2001/12/26 - Misc. fixes (Aaron S. Hawley, DLR).<br>
2001/10/02 - Update for Free Translation Project.<br>
2000/11/28 - Added blurb about make install-strip.<br>
2000/11/19 - Changed Debian frozen to stable.<br>
2000/11/18 - Previous string display (4.5).<br>
2000/09/27 - Moved addresses to nano-editor.org.<br>
2000/06/31 - Initial framework.</p></blockquote>
<p>$Id$</p>
<p>The best way to submit bugs is through the <ahref="https://savannah.gnu.org/bugs/?group=nano">Savannah bug tracker</a>, as you can check whether the bug you are reporting has already been submitted, and it makes it easier for the maintainers to keep track of them.
<p>You can submit patches for nano via <ahref="https://savannah.gnu.org/patch/?group=nano">Savannah's patch manager</a>.</p></blockquote>
<h3id="7.3">7.3. I want to send the development team a big load of cash (or just a thank you).</h3>
<blockquote><p>That's fine. Send it <ahref="mailto:nano-devel@gnu.org">our way</a>! Better yet, fix a <ahref="https://savannah.gnu.org/bugs/?group=nano">bug</a> in the program or implement a <ahref="https://nano-editor.org/dist/latest/TODO">cool feature</a> and send us that instead (though cash is fine too).</p></blockquote>
<h3id="7.4">7.4. How do I join the development team?</h3>
<blockquote><p>The easiest way is to consistently send in good patches that add some needed functionality, fix a bug or two, and/or make the program more optimized/efficient. Then ask nicely and you will probably be added to the Savannah development list and be given write access after a while. There is a lot of responsibility that goes along with being a team member, so don't think it's just something to add to your resume.</p></blockquote>
<h3id="7.5">7.5. Can I have write access to the git tree?</h3>
<blockquote><p>Re-read section <ahref="#7.4">7.4</a> and you should know the answer.</p></blockquote>
color brightyellow ":|\*|/|%|\+|-|\^|>|>=|<|<=|~=|=|\.\.|\<(not|and|or)\>"
# Statements
color brightblue "\<(do|end|while|repeat|until|if|elseif|then|else|for|in|function|local|return|break)\>"
# Keywords
color brightyellow "\<(io|math|os|string|table|coroutine|debug)\>\."
color brightyellow "\<(_G|_VERSION|assert|collectgarbage|dofile|error|getfenv|getmetatable|ipairs|load|loadfile|module|next|pairs|pcall|print|rawequal|rawget|rawset|require|select|setfenv|setmetatable|tonumber|tostring|type|unpack|xpcall)\s*\("
# Standard library
color brightyellow "io\.\<(close|flush|input|lines|open|output|popen|read|tmpfile|type|write|stdin|stdout|stderr)\>"
color brightyellow "math\.\<(abs|acos|asin|atan2|atan|ceil|cosh|cos|deg|exp|floor|fmod|frexp|huge|ldexp|log10|log)\>"
color brightyellow "math\.\<(max|min|mod|modf|pi|pow|rad|random|randomseed|sinh|tan)\>"
color brightyellow "os\.\<(clock|date|difftime|execute|exit|getenv|remove|rename|setlocale|time|tmpname)\>"
color brightyellow "package\.\<(cpath|loaded|loadlib|path|preload|seeall)\>"
color brightyellow "string\.\<(byte|char|dump|find|format|gmatch|gsub|len|lower|match|rep|reverse|sub|upper)\>"
color brightyellow "table\.\<(concat|insert|maxn|remove|sort)\>"
color brightyellow "coroutine\.\<(create|resume|running|status|wrap|yield)\>"
color brightyellow "debug\.\<(debug|getfenv|gethook|getinfo|getlocal|getmetatable|getregistry|getupvalue)\>"
color brightyellow "debug\.\<(setfenv|sethook|setlocal|setmetatable|setupvalue|traceback)\>"
# File handle methods
color brightyellow "\:\<(close|flush|lines|read|seek|setvbuf|write)\>"
color red "\<(accept|alarm|atan2|bin(d|mode)|c(aller|h(dir|mod|op|own|root)|lose(dir)?|onnect|os|rypt)|d(bm(close|open)|efined|elete|ie|o|ump)|e(ach|of|val|x(ec|ists|it|p))|f(cntl|ileno|lock|ork))\>" "\<(get(c|login|peername|pgrp|ppid|priority|pwnam|(host|net|proto|serv)byname|pwuid|grgid|(host|net)byaddr|protobynumber|servbyport)|([gs]et|end)(pw|gr|host|net|proto|serv)ent|getsock(name|opt)|gmtime|goto|grep|hex|index|int|ioctl|join)\>" "\<(keys|kill|last|length|link|listen|local(time)?|log|lstat|m|mkdir|msg(ctl|get|snd|rcv)|next|oct|open(dir)?|ord|pack|pipe|pop|printf?|push|q|qq|qx|rand|re(ad(dir|link)?|cv|do|name|quire|set|turn|verse|winddir)|rindex|rmdir|s|scalar|seek(dir)?)\>" "\<(se(lect|mctl|mget|mop|nd|tpgrp|tpriority|tsockopt)|shift|shm(ctl|get|read|write)|shutdown|sin|sleep|socket(pair)?|sort|spli(ce|t)|sprintf|sqrt|srand|stat|study|substr|symlink|sys(call|read|tem|write)|tell(dir)?|time|tr(y)?|truncate|umask)\>" "\<(un(def|link|pack|shift)|utime|values|vec|wait(pid)?|wantarray|warn|write)\>"
color magenta "\<(continue|else|elsif|do|for|foreach|if|unless|until|while|eq|ne|lt|gt|le|ge|cmp|x|my|sub|use|package|can|isa)\>"
color yellow "\<(BEGIN|END|alias|and|begin|break|case|class|def|defined\?|do|else|elsif|end|ensure|false|for|if|in|module)\>"
color yellow "\<(next|nil|not|or|redo|rescue|retry|return|self|super|then|true|undef|unless|until|when|while|yield)\>"
# Constants.
color brightblue "(\$|@|@@)?\<[A-Z]+[0-9A-Z_a-z]*"
# Ruby "symbols".
icolor magenta "([ ]|^):[0-9A-Z_]+\>"
# Some unique things we want to stand out.
color brightyellow "\<(__FILE__|__LINE__)\>"
# Regular expressions.
color brightmagenta "/([^/]|(\\/))*/[iomx]*" "%r\{([^}]|(\\}))*\}[iomx]*"
# Shell command expansion is in `backticks` or like %x{this}. These are
# "double-quotish" (to use a perlism).
color brightblue "`[^`]*`" "%x\{[^}]*\}"
# Strings, double-quoted.
color green ""([^"]|(\\"))*"" "%[QW]?\{[^}]*\}" "%[QW]?\([^)]*\)" "%[QW]?<[^>]*>" "%[QW]?\[[^]]*\]" "%[QW]?\$[^$]*\$" "%[QW]?\^[^^]*\^" "%[QW]?![^!]*!"
# Expression substitution. These go inside double-quoted strings,
# "like #{this}".
color brightgreen "#\{[^}]*\}"
# Strings, single-quoted.
color green "'([^']|(\\'))*'" "%[qw]\{[^}]*\}" "%[qw]\([^)]*\)" "%[qw]<[^>]*>" "%[qw]\[[^]]*\]" "%[qw]\$[^$]*\$" "%[qw]\^[^^]*\^" "%[qw]![^!]*!"
color brightblue "((Icon|ExclusiveOs|ExcludeOs)[[:space:]]*:)"
color brightblue "((BuildArch|BuildArchitectures|ExclusiveArch|ExcludeArch)[[:space:]]*:)"
color brightblue "((Conflicts|Obsoletes|Provides|Requires|Requires\(.*\)|Enhances|Suggests|BuildConflicts|BuildRequires|Recommends|PreReq|Supplements)[[:space:]]*:)"
color brightblue "((Epoch|Serial|Nosource|Nopatch)[[:space:]]*:)"
color brightblue "((AutoReq|AutoProv|AutoReqProv)[[:space:]]*:)"
color brightblue "((Copyright|License|Summary|Summary\(.*\)|Distribution|Vendor|Packager|Group|Source\d*|Patch\d*|BuildRoot|Prefix)[[:space:]]*:)"
color brightblue "((Name|Version|Release|Url|URL)[[:space:]]*:)"
color brightblue start="^Source" end=":" start="^Patch" end=":"
# Architectures.
color brightred "(i386|i486|i586|i686|athlon|ia64|alpha|alphaev5|alphaev56|alphapca56|alphaev6|alphaev67|sparc|sparcv9|sparc64armv3l|armv4b|armv4lm|ips|mipsel|ppc|ppc|iseries|ppcpseries|ppc64|m68k|m68kmint|Sgi|rs6000|i370|s390x|s390|noarch)"
# Architecture conditionals.
color brightred "(ifarch|ifnarch)"
# OS conditionals.
color brightred "(ifos|ifnos)"
# %* strings.
color green "%([A-Z_a-z_0-9_]*)"
color magenta "%_([A-Z_a-z_0-9_]*)"
color yellow start="%__" end="\ "
color magenta start="%\{" end="\}"
color yellow start="%\{__" end="\}"
# Sections.
color red "^%(build$|changelog|check$|clean$|description|files|install$|package|pre|prep$|pretrans|preun)"
color red "^%(post|posttrans|postun|trigger|triggerin|triggerpostun|triggerun|verifyscript)"
# Conditionals and defines.
color brightred "%(if|else|endif|define|global|undefine)"
# Comments.
color cyan "#.*$"
# Special case: "# norootforbuild" is handled as main tag.
color green "\<(after|append|array|auto_execok|auto_import|auto_load|auto_load_index|auto_qualify|binary|break|case|catch|cd|clock|close|concat|continue|encoding|eof|error|eval|exec|exit|expr|fblocked|fconfigure|fcopy|file|fileevent|flush|for|foreach|format|gets|glob|global|history|if|incr|info|interp|join|lappend|lindex|linsert|list|llength|load|lrange|lreplace|lsearch|lset|lsort|namespace|open|package|pid|puts|pwd|read|regexp|regsub|rename|return|scan|seek|set|socket|source|split|string|subst|switch|tclLog|tell|time|trace|unknown|unset|update|uplevel|upvar|variable|vwait|while)\>"
# Basic Tcl subcommands:
color green "\<(array anymore|array donesearch|array exists|array get|array names|array nextelement|array set|array size|array startsearch|array statistics|array unset)\>"
color green "\<(alarm|auto_load_pkg|bsearch|catclose|catgets|catopen|ccollate|cconcat|cequal|chgrp|chmod|chown|chroot|cindex|clength|cmdtrace|commandloop|crange|csubstr|ctoken|ctype|dup|echo|execl|fcntl|flock|fork|fstat|ftruncate|funlock|host_info|id|infox|keyldel|keylget|keylkeys|keylset|kill|lassign|lcontain|lempty|lgets|link|lmatch|loadlibindex|loop|lvarcat|lvarpop|lvarpush|max|min|nice|pipe|profile|random|readdir|replicate|scancontext|scanfile|scanmatch|select|server_accept|server_create|signal|sleep|sync|system|tclx_findinit|tclx_fork|tclx_load_tndxs|tclx_sleep|tclx_system|tclx_wait|times|translit|try_eval|umask|wait)\>"
# Syntax:
color brightblue "proc[[:space:]]" "(\{|\})"
color green "(\(|\)|\;|`|\\|\$|<|>|!|=|&|\|)"
color brightyellow ""(\\.|[^"])*"" "'(\\.|[^'])*'"
File diff suppressed because it is too large
Load Diff
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
