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.
