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).
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.
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.
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.
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.
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.
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.
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.
(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>
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.
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.
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.
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.
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.
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>
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.
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.
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>
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.
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.
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.
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.
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.
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>
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.
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 constant cursor display must be suppressed whenever a message
was printed to the status bar. That is: whenever 'lastmessage' is
something other than 'VACUUM'.
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.
Benno Schulenberg