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 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.
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.
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.
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.
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>
When nano was configured with --enable-tiny --enable-speller, the
block_sigwinch() function should be available, to mask SIGWINCHes
during a spell check.
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.
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.
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>
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.
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.
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>
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.
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.
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>
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>
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.
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>
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.
Benno Schulenberg