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>
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...
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.
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>
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.
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 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.
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 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.
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.
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.
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.
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.
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>
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.
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.
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 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.
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.
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.
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>
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.
Benno Schulenberg