This matches Pico's behavior. However, Pico doesn't add the quoting +
indentation to the line in which the selection ends, but this is wrong,
so nano does add it. Also, Pico doesn't account for partial quoting +
indentation at the start or end of a selection, but this is wrong, so
nano does.
Unlike a regular paragraph, marked text may have different quotes and
more than two types of indentation. Handle this by replacing deviant
quotes with the quote of the first line, and deviant indentation with
the indentation of the second line.
This is modelled after Pico's behavior. However, Pico won't do anything
if you do a full-justify while the mark is on. But this is unnecessarily
limiting, so, when the mark is on, nano will handle a full-justify and a
plain justify the same.
This currently does not handle the lead (quoting + indentation) in
justified selections, does not put mid-line justified selections onto
separate lines, and does not strip whitespace after the lead in justified
selections, the latter two of which Pico does. These behaviors are
forthcoming.
concat_paragraph() concatenates a paragraph into a single line, and
rewrap_paragraph() rewraps that line into multiple lines again.
These two will be needed when the justifying of marked text is added.
Instead of passing 'quote_len' to these functions, calculate it directly
in them.
This will be needed when the justifying of marked text is added. When
unmarked text is justified, it is a single paragraph and by definition
has a uniform quoting part. But marked text may be a jumble of lines
that have different quoting parts.
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>
When the right half of a two-column character gets overwritten by the
">" continuation character, then represent its left half as "[" also
when spotlighting a replacement candidate. Achieve this by calling
display_string() in the overshooting case with 'isprompt' set to TRUE,
which also makes this function reserve space for the ">" continuation
character so spotlight() doesn't need to do this any more.
This fixes https://savannah.gnu.org/bugs/?55679.
Improved-by: Benno Schulenberg <bensberg@telfort.nl>
The change in commit edc0d628 was flawed. The old logic covered
every case but one: having reached the end of 'buf' but 'column'
still having overshot the screen width. Now cover this latter
case too.
This fixes https://savannah.gnu.org/bugs/?55638 properly,
allowing the next commit to fix another buglet.
Condensed-by: Benno Schulenberg <bensberg@telfort.nl>
In this way, for single-width characters, one can see what character is
ahead of the cursor before actually moving the cursor to that position,
and, for double-width characters, the cursor never sits on a placeholder
but always shows the character that is actually there.
This addresses https://savannah.gnu.org/bugs/?55716.
In the tiny version the feature toggles are absent, so most of the
Meta-key combinations do nothing, and when --with-slang was used, the
<Ctrl+Left/Right> keystrokes do not work (as they produce truncated
escape sequences under Slang), and the <Ctrl+Space> and <Alt+Space>
keystrokes are awkward to type and make no sense. So... use some
of the free Meta combinations to jump a word to the left or right,
since these functions *are* present in the tiny version.
The reload_positions_if_needed() routine can free the existing
'position_history' and allocate a new one. Using the old one,
from before the reload, could lead to a crash.
This fixes https://savannah.gnu.org/bugs/?55792.
Reported-by: Enrico Mioso <mrkiko.rs@gmail.com>
Bug existed since the reloading of the position-history file was
introduced, a year and a half ago, in commit bfc53f30.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
That is: keep nibbling off characters until a character is eaten that
takes up at least one column.
This fixes https://savannah.gnu.org/bugs/?55759.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Bug existed since version 2.8.0, commit 5283acdc.
On small terminals (80 columns or so), ^S and ^Q would be in
the last position of the help lines. But some terminals might
intercept ^S and stop all output (until ^Q is pressed), which
could be unexpected and frustrating. So, rearrange things for
the tiny version so that ^S appears only on very wide terminals.
Also, having two keystrokes for saving the current buffer
(^O and ^S) in the two help lines is wasteful, more so as
in the tiny version there are no ^G help texts.
So, show the more useful M-Q and M-W instead.
This addresses https://bugs.debian.org/915017.
Reported-by: Steve McIntyre <steve@einval.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.
The start-of-paragraph and end-of-paragraph seeking functions are only
vaguely related to searching, and have nothing to do with replacing --
the functions make more sense in the Goto-Line menu.
Also, the Goto-Line menu is much less crowded, so the functions are
more likely to be noticed there. Furthermore, this makes harmless a
typo that I sometimes make: typing ^W again when I've already done so.
Jumping to the first or last line of the buffer doesn't have anything
to do with searching, so these functions shouldn't be present in the
search menus. They make perfect sense in the Goto-Line menu, though.
To make it obvious that they are not actual characters in the file.
The default highlighting is in reverse video, but this can be changed
to bold by using --bold or 'set boldtext'.
This fulfills https://savannah.gnu.org/bugs/?55571.
The angular brackets look a bit like arrows and thus hint much more
at the idea of continuation than a dollar sign.
With-help-from: David Lawrence Ramsey <pooka109@gmail.com>
When the screen's edge leaves just one column for a two-column
character, then show its left half as "[" and its right half as "]".
(They used to be shown as ">" and "<", but these characters will be
repurposed in the next commit.)
This addresses https://savannah.gnu.org/bugs/?55657.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
The get_history_older_void() and get_history_newer_void() functions
are mere names, they don't actually do anything. So... don't bother
to execute them, so the 'finished' variable doesn't have to be reset
after calling them.
Also, normalize the order of those two empty functions.
When doing replacements or fixing misspelled words, and edit_refresh()
is called to highlight the relevant word, then the current menu can be
anything from MREPLACEWITH, MYESNO, MSPELL, or MMAIN. Make sure it is
always set to the latter just before calling edit_refresh(), so that
display_string() will use the full length and the word gets properly
highlighted.
This fixes https://savannah.gnu.org/bugs/?55680.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Bug was introduced by the previous commit, 56181896.
It needs to be trimmed and substituted with a single-width placeholder
to prevent the continuation character ">" from getting pushed to the
next row.
Also, use the correct width for the answer so that the continuation
character is only displayed when the answer does not fit any more.
This fixes https://savannah.gnu.org/bugs/?55620.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Original-patch-by: David Lawrence Ramsey <pooka109@gmail.com>
When a line ends with a two-column character, and this character straddles
the edit window's edge, then, although we've reached the end of 'buf', we
have exceeded the 'beyond' column and this two-column character needs to
be trimmed from the 'converted' string, otherwise it would get printed on
the next row.
This fixes https://savannah.gnu.org/bugs/?55638.
Bug existed since version 2.8.0, commit 5283acdc.
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.
Using the cursor keys for movement-related functions makes more sense
than using them for jumping to the previous or next occurrence of the
search string.
(For searching another occurrence backward the M-Q binding has become
available, while M-W will search another occurrence always forward.)
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>
The user did not move the cursor nor intend to move the cursor, so
leave things as they are.
This fixes https://savannah.gnu.org/bugs/?55535.
Indirectly-reported-by: David Lawrence Ramsey <pooka109@gmail.com>
After a series of escapes, also <Shift+Meta+letter> should be recognized
as a command keystroke, not just <Meta+letter>.
This fixes https://savannah.gnu.org/bugs/?55442.
Bug existed since the ignoring of <Escape>s before a valid command
keystroke was introduced in version 3.0, commit ecc9211a.
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.
The reduced file size should be stored not just when joining two lines
but also when simply a character in the middle of a line is deleted.
This fixes https://savannah.gnu.org/bugs/?55352.
Bug existed since version 2.5.0, commit 66e21416.
All tested systems (FreeBSD, NetBSD, OpenBSD, Alpine, and Ubuntu)
support the GNU-style word boundaries (\< and \>), either natively
or through using the regex module from gnulib.
If this change breaks regexes containing \< or \> on your system,
please report a bug: https://savannah.gnu.org/bugs/?group=nano
This addresses https://savannah.gnu.org/bugs/?55207.
Reuse the WAS_FINAL_LINE flag to signal a cut that added a magicline,
for both a marked cut and cut-to-eof.
This fixes https://savannah.gnu.org/bugs/?55305.
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.
When the terminfo selected by TERM does not match the terminal and
the <Delete> key behaves the same as <Backspace> (deleting leftward)
or the <Backspace> key behaves the same as <Delete> (deleting without
moving the cursor), then using just -d or --rebinddelete should make
the deviant key behave correctly again without affecting the other.
ASCII code BS should always do a backspace, also on systems where the
"^H" string gets redirected (for rebinding purposes) to KEY_BACKSPACE.
This fixes https://savannah.gnu.org/bugs/?55247.
Reported-by: Norton Warner <nortonwarner@gmail.com>
When not unbinding it from its earlier function (in the same menu),
it would result in showing the keystroke twice in the help text.
This fixes https://savannah.gnu.org/bugs/?55239.
Bug was introduced a month ago, by commit f81d174f.
The direct call was a leftover of the old unjustify mechanism.
Also, move two statements to the end of the do_justify() routine,
since that is their place in comparable routines.
Suggested-by: David Lawrence Ramsey <pooka109@gmail.com>
When multiple buffers are open, the edit window says "Close" for ^X
instead of "Exit" (when one buffer is open). In the help viewer ^X
says "Close". Apparently the idea is that ^X should say "Exit" only
when pressing ^X leads to exiting from nano. Pressing ^X in the file
browser does not exit from nano, so make it say "Close" instead.
(The help viewer says "Close" since version 2.8.6, commit 934a2192.)
When using --preserve, ^S and ^Q are "eaten" by the terminal and
do not reach nano: they have no effect in nano, so the help lines
and the help texts should not mention these shortcuts.
Also, to keep the help lines in the help viewer neatly arranged,
^L is not bound there when --preserve is used.
Not stepping beyond the last line of the paragraph means that the
length of the paragraph is always the difference in line numbers
(between first and last line of the paragraph) plus one.
When leaving the mark on while justifying and then undoing the
justification, things are likely to get messed up. My applying
David's patches only partially caused this breakage.
This fixes https://savannah.gnu.org/bugs/?55074.
Only the first search for a paragraph needs to check whether we're
currently in the middle of a paragraph. When the 'while' loop for
a full justify is executed, all calls of find_paragraph() start
either on the first line of a paragraph or between two paragraphs.
To find a paragraph, what needs to be done is:
a) When not in a paragraph, move forward until we find one, if any.
b) When in a paragraph but not at its start, move back to its start.
c) Move forward to the end of the paragraph, if any.
When, in the 'while' loop for a full justify, 'filebot_inpar' becomes
TRUE, it means that EOF has been reached and find_paragraph() should
not be called again. To allow 'filebot_inpar' to convey this meaning,
it should not be set to TRUE elsewhere, so another boolean is needed
for setting the correct length of the final line of the cutbuffer.
This fixes https://savannah.gnu.org/bugs/?55086.
The removal of the x-coordinate handling affected this. Reshuffle things
so that we can check for it after we have moved (the same way we check for
it at the beginning of the function before we move) without having to set
'quote_len' and 'par_len' unnecessarily.
Also, adjust some comments accordingly.
Move detecting the final line of the paragraph to find_paragraph(),
since a paragraph of which the final line is the last line of the
buffer will still be that way after being justified.
Also, move all x-coordinate handling to do_justify(), since it only
applies to the current buffer.
Benno Schulenberg