This allows one to complete also words that are present in other files
(when these are open in other buffers).
This fulfills https://savannah.gnu.org/bugs/?61691.
Requested-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Original-patch-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
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>