Instead of burdening seven other calls of do_prompt() with a useless
parameter, just check for MGOTODIR in the appropriate place. It also
saves having to pass the parameter down through three more functions.
The single dot serves no purpose, as the user is already there. And
the double dot is reached more easily by typing a second dot first.
And anyway, . and .. are not shown when the user does not type a dot
first, so why show them when the user types a single dot followed by
<Tab><Tab>? Most likely the user wants to see actual dot files, so
just show those.
This fixes https://savannah.gnu.org/bugs/?58619.
Now the help lines can be toggled not only while editing, but also at
the Read (^R), Write (^O), Execute (^T), Search (^W), Replace (M-R),
Goto (^/), and Yesno prompts, and also in the file browser and when
searching for a file name. The help lines cannot be toggled in the
help viewer, nor when searching in a help text, nor in the linter,
as these three things force the help lines to be on.
Furthermore, the 'nohelp' function can be rebound in all relevant
menus (default binding: M-X).
This fulfills https://savannah.gnu.org/bugs/?58471.
The modifier has to come before the foreground color name, separated
by a comma, and after 'bold,' (when present). This has no effect on
terminals that are incapable of cursive text, like the Linux console.
This fulfills https://savannah.gnu.org/bugs/?56525.
The username_tab_completion() function taken from busybox-0.46 was
just a stub, it contained basically nothing. Chris himself wrote
the function in November 2000 (commit be77c611), and rewrote it in
January 2001 (commit 2c2c5f21).
The version of username_tab_completion() in that latter commit looks
somewhat like the version of Vladimir N. Oleynik <dzo@simtreas.ru>
(busybox commit 4e338757). That commit comes three days after Chris'
commit, but Vladimir's original email is from a week earlier:
http://lists.busybox.net/pipermail/busybox/2001-January/035687.html.
So... it is quite possible that Rocco saw that email and suggested
to Chris to rewrite username_tab_completion() using getpwent().
Anyway, the version that was taken from busybox-0.46 was just four
lines and thus not worthy of copyright. The two other functions
that were copied were heavily modified in 2000, so it's better to
add that year in the copyright notice. It is fine to tweak the
notice: it just says that the original authors must be attributed,
not that the exact text must remain unchanged.
Instead of first trying to match things, and then discarding these
matches when the cursor is not at the end of the offered fragment
('buf'), simply don't bother to do any matching in that case.
The variable is set to zero at its declaration, and the second function
is called only when the first is either not called or found nothing --
thus '*num_matches' will still be zero.
Names give a rough idea of what the color will look like, whereas
numerical indexes would not do this at all.
Nine extra colors seems enough. If there were more, no one would be
able to say for sure which is which when two similar colors are used
several rows apart.
This partially fulfills https://savannah.gnu.org/bugs/?56445.
After a year or so, when people have had time to convert their syntaxes
to use 'bold' and/or 'light' instead of 'bright', we can drop this
colorizing, and still later stop recognizing 'bright' altogether.
Having the M-F toggle non-persistent, makes the behavior of ^R
predictable. This allows string binds that load a file to work
correctly independently of when M-F was last pressed.
The -F/--multibuffer command-line option and "set multibuffer"
in a nanorc file determine the default behavior of ^R.
Signed-off-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
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...
A background color *can* be bright (in the sense of lighter, shinier).
It's just that the background cannot be bold. Only the typeface used
on the foreground can be bold (if the terminal supports it). So, let
"bright", when used with a background color, simply mean "light".
This makes it possible to avoid the misnamed prefix "bright". It is
misnamed because (on current terminal emulators, when the brightening
of bold is switched off) it just makes the typeface bold, not the color
brighter. The prefix "light" will now only make the color brigther,
and the modifier "bold" will just make the typeface bold (on terminal
emulators, when the brightening of bold is switched off).
On a Linux console, which is not capable of bolding the typeface,
"bold" will brighten the color.
This fully fulfills https://savannah.gnu.org/bugs/?58503.
The prefix "bright" will continue to make the color brighter AND/OR
make the typeface bold (depending on how the terminal is configured
and on its capabilities), but the prefix "light" will just make the
color brighter (if the terminal can do that).
The prefix "bright" continues to do the same as what it did before,
to not change the appearance of user-defined syntaxes. And having
an option to change the meaning of "bright"... would be confusing.
This partially fulfills https://savannah.gnu.org/bugs/?58503.
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.
Each listing of a name is preceeded by a call to wmove(), so there
is no need for an initial wmove(). And after writing "more" on the
bottom row of the edit window, the loop is terminated, so there is
no need to check that this is the first item on the bottom row.
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>
(Unfortunately, this means that ^L cannot be used for the
Linter in the "Execute Command" menu.)
This fixes https://savannah.gnu.org/bugs/?58469.
Bug existed since around version 2.1.0.
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.
A help text is contained in a normal buffer (since quite a while now),
so cursor placement should work like in a regular edit window.
Also, remove an unneeded switching on of the cursor -- it is already on
as nano is waiting for keyboard input.
This fixes https://savannah.gnu.org/bugs/?58489.
Bug existed since version 3.2, commit 10d9742c, since --showcursor
shows the cursor also in the help viewer.
If a replacement changed the matching of a multiline coloring regex,
then wipe the existing multiline data and recalculate it for the whole
buffer.
There is no need to redraw the current line (let alone the whole window)
directly after a replacement, because if there is a next occurrence, the
edit window will be redrawn then in order to spotlight that occurrence;
and if there is no other occurrence, the edit window will be redrawn in
the main loop because there has been at least one replacement.
This fixes https://savannah.gnu.org/bugs/?58481.
Bug existed (in this form) since version 2.7.5. Before that,
the miscoloring could happen even without scrolling.
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 that the M-F toggle stays roughly in the same place when
toggling between "Read File" and "Execute Command", and groups the
six special commands together.
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.
Make the "Execute Command" menu accessible also with a single keystroke
(^T), not just with a double one (^R^X). This is useful, because no one
will suspect that "Execute Command" can be found behind "Read File".
To not disturb muscle memory too much for people who are used to ^T
invoking the Spell Checker, a second ^T will invoke it.
Instead of creating a special Tools menu, add the five functions that
affect the whole buffer to the "Execute Command" menu. There is room
for these five functions there, and they kind of fit in because three
of them (Speller, Linter, and Formatter) actually invoke an external
command, and Full Justify could have been implemented externally, and
the destructive Cut Till End ought to have required a double keystroke
since the beginning.
Also, do not prompt when there is no space left on the device,
because then trying to save the actual file would likely lead
to truncating it, resulting in an empty file.
Only when fclose() is called, does the data get flushed out to disk,
and maybe only then the system realizes that there is no space left on
the device, as Chris noted in: https://savannah.gnu.org/bugs/?24000.
When asking this question when deleting fails or writing fails,
it should be asked too when creating fails. Otherwise the user
is blocked from saving the file -- until she realizes that maybe
toggling off backups would help.
If the user answered "No" or "Cancel" the first time, they should
be allowed to answer "Yes" the next time -- possibly after fixing
the necessary permissions in another terminal.
This fixes https://savannah.gnu.org/bugs/?58442.
Bug existed since version 2.3.0, commit 3d411188.
Access control lists can permit read and write access to a file
but not permit to manipulate any attributes of the file. So it
is quite possible for futimens() to fail, just like chown() and
chmod() can fail, but this should be no cause for alarm: as long
as writing the backup file worked, then writing the file itself
will probably work too.
First, it is very unlikely that chmod() would fail as the user just
created the file herself. Second, even if chmod() would fail, this
is not a problem, because we have created the file with read+write
permissions for the owner only, so the file cannot accidentally be
left accessible to unintended others.
But most of all, such a failure should not stop nano from trying to
write the backup file. Only when the actual *writing* fails, should
we bother the user with a prompt.
If there are still systems where mkstemp() creates world-readable
temporary files, then please holler. On current BSDs and on GNU,
I've verified that mkstemp() creates files with 0600 permissions.
When deleting an existing backup file failed, we do not want to
append to this file, but want instead to overwrite it (when the
user has put 'set allow_insecure_backup' in their nanorc file).
Also, when using O_EXCL (in the normal, secure case), O_APPEND
is pointless, because the file will be created and thus empty.
This fixes https://savannah.gnu.org/bugs/?58439.
Bug existed since version 2.2.5, commit 461519cc.
A normal user can change the group of a file (if the user is a member
of that group), but cannot change the owner of that file. So, when a
user edits a file that belongs to a different user, the call of fchown()
will fail. But there is no harm in that. Also when the user is root,
there is no harm in fchown() failing -- it will simply mean that the
backup file will remain owned by root and will not be writable by the
intended owner (when root has the normal umask of 0022).
This fixes https://savannah.gnu.org/bugs/?58383.
Bug existed since version 2.2.5, commit 86be3af7.
In the past, when Speller and Linter and Formatter were all bound
to ^T (later ones taking priority), it was easier to exclude also
the formatter code when --disable-speller was used. But since the
formatter was reintroduced (in commit 34170611) and bound to its
own keystroke (M-F), this is no longer the case.
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 12cf1c99 added a beep() for every invalid keystroke at the
Yes-No prompt, but overlooked that KEY_WINCH is not invalid.
This fixes https://savannah.gnu.org/bugs/?58422.
Bug existed since version 4.8, commit 12cf1c99.
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.
If unlinking would fail because the parent directory is unwritable,
then a check in has_valid_path() would have prevented do_lockfile()
from being called at all.
If in between the unlink() in delete_lockfile() and the fopen() in
write_lockfile() some other process creates a symlink in the place
of the lock file, then the fopen() could unexpectedly overwite a
root-owned file (when the user is root).
This basically reverts the previous commit, b4299f4f, but makes the
code a bit conciser.
One microsecond earlier, the lock file has been deleted (if it existed),
so, if between our unlink() and our open() some other process managed to
recreate the lock file... well, we want to delete it *again*. So, just
overwrite and truncate the lock file (if it exists).
When the lock file did NOT exist (a few microseconds earlier, when
checking in do_lockfile(), before calling write_lockfile()), then
the user expects the lock file to be written, so: just write it.
That between the check and the actual writing of the lock file there
is a small window of opportunity for other processes to write this
lock file is unfortunate, but it is not a reason to bother the user
with an error message when it happens.
One microsecond before a lock file is created an existing lock file
has been deleted, and if that deletion failed, writing the lock file
is aborted. So why should writing the lock file not be aborted when
the lock file cannot be exclusively created one microsecond later?
This makes no sense. So... always include the O_EXCL flag, also
when the INSECURE_BACKUP flag is set.
(And anyway: lock files are not an essential part of editing, they
are just a small service to the user, AND they have nothing to do
with backups, so a backup flag should not influence them.)
When two lines are joined, 'refresh_needed' is already set to TRUE,
so only when a midline character is deleted the check for a changed
number of chunks is needed.
Now all functions that are relevant only to softwrapping
get called only when softwrapping is on.
This also allows to elide an intermediate function call.
A file is always in either Unix or DOS or Mac format, and should
by default be saved again in that same format.
Any lone CRs or LFs after the first line should not change the
format that was deduced from that very first line.
Only when a CR is seen before any LF, and the CR is not followed
by a LF, should this CR be interpreted as a line separator. And
only then the file should be reported as being in Mac format --
as long as --noconvert is not used.
This fixes https://savannah.gnu.org/bugs/?58357.
Bug existed since at least version 2.0.6.
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.
When the user mentions the file "zzy" on the command line,
the magic spell "Xyzzy" does not actually get typed, so the
Easter egg should then not be triggered.
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.
When a file is saved under a different name, and as a result the
applicable syntax changes, and the old syntax had multiline regexes
and the new syntax doesn't, then the call of precalc_multicolorinfo()
in write_file() should not result in nano setting up a multicache of
zero bytes for each line in the buffer.
(Problem was found by locally letting nano crash when zero bytes are
allocated, and then happening to rename a file.py to a file.sh.)
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.
Just let all anchors disappear when doing an external spell check or
formatting or piping the buffer through an external command, because
leaving just a single anchor on the top line is useless.
This fixes https://savannah.gnu.org/bugs/?58273.
Bug existed since commit 732cf887 from one month ago. That code
causes an anchor to persist at the point where lines are removed.
When a single paragraph is justified, any anchor on any of its lines
gets moved to its first line. Let a full justification do the same
for each of the paragraphs.
This fixes https://savannah.gnu.org/bugs/?58272 in a better way.
This fixes https://savannah.gnu.org/bugs/?58272.
Bug existed since commit 732cf887 from one month ago. That code
causes an anchor to persist at the point where lines are removed.
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.
In "Cut Text" and "Paste Text" the word "Text" is superfluous. (It
could even be called slightly misleading, because by default ^K will
cut the current line, whether or not it contains text.)
The "Get Help" is of course inherited from Pico, but to me it has
always sounded a bit as if it would go search help on the internet.
Instead of "Spelling" I would have preferred "Spellcheck", but that
gets a bit too cramped on an 80-column terminal.
For ^C I've chosen "Location" because I tend to understand "Position"
as a verb, especially when seen next to "Go To Line" (even when having
two items with the same meaning next to each other doesn't make sense).
"Mark Text" has simply always been wrong. It doesn't mark anything,
but just *sets* the mark (or unsets it, but that normally happens
automatically, no need to mention that in the label).
The "Cut Till End" and "Full Justify" get shown only on very wide
terminals, and at such widths there is enough room for each label
to write out those two labels in full.
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>
This has the pleasing effect of not changing the linestruct of the
succeeding line when a line is cut.
This addresses https://savannah.gnu.org/bugs/?56226.
It should give the same result as 'wc -w' as long as the content
of 'wordchars' does not affect the counting.
This fixes https://savannah.gnu.org/bugs/?58123.
Bug existed since version 2.6.2, since the --wordchars option was
introduced in commit 6f12992c.
First the clause for the intro text and the normal lines, and then the
clause for the continuation lines (that are narrower and indented).
Also, avoid blanking the status bar when initializing the subwindows
anyway, and avoid an unneeded resfreshing call -- the bottombars()
function will take care of that.
Normally, when undoing an <Enter> that created automatic indentation,
the created whitespace should be skipped when rejoining the two lines.
In other words: take the data starting from tail_x in the second line.
But when the <Enter> occurred at the end of leading whitespace, then
that whitespace has disappeared from the original line and it should
be copied back in from the second line. That is: from x is zero.
This fixes https://savannah.gnu.org/bugs/?58108.
Reported-by: Liu Hao <lh_mouse@126.com>
Bug existed since version 4.9, commit 1961c052.
Avoid having to decrement the count in order to offset the increment
at the end of the loop.
Also, declare a variable on a separate line, and rename it.
When using --nonewlines and the cursor has arrived at the end of the
final line, each press of M-6 would add another copy of that line to
the cutbuffer. That is clearly not the right behavior.
Also, give feedback when a press of M-6 does not actually copy anything.
This fixes https://savannah.gnu.org/bugs/?58088.
The bug was old -- it existed since before version 2.2.0.
First cutting the text to be copied (before copying it back into the
buffer) had unwanted side effects: it moved the cursor, and changed
the linestructs of the current line and the line where the mark was.
[This takes thirty more lines, but the idea is to later get rid of
the partitioning routines entirely.]
This means that in most cases mark_is_before_cursor() is called twice:
once before get_region() is called, and once by get_region() itself.
This small duplication of effort is acceptable: the affected functions
are not time critical, and it makes the code shorter.
It is very unlikely that anyone uses those keystrokes: 1) no keyboard
has such keys; 2) the default bindings for these keys were removed a
year and a half ago, and no one complained; 3) for several years nano
did not recognize the modern xterm escape sequences for F13 to F16,
and no one ssh'ing from a new machine to an old machine complained.
The only people who might be affected by this removal are Konsole users:
a Konsole claims to be an xterm, but sends its own peculiar "Esc O 2 X"
sequences for F13 to F16. Using the data from terminfo, ncurses will
not recognize those sequences, and will pass them untranslated to nano.
When nano now stops recognizing them too... Well, let's see if there
are any Konsole users that use F13 to F16.
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.
Only for the last item at the end of each of the two help lines there
are sometimes a few extra columns available. Do not use these extra
columns also for the other help items, because apparently, when wmove()
lands in the second column of a double-width character, it does not
wipe out this character (replacing it with a space) but goes to the
next column instead, causing a misalignment of the text.
This fixes https://savannah.gnu.org/bugs/?57994.
Bug existed since version 1.3.12, commit e806ab84.
The placeholder half-duplicates the character that is actually shown
at the beginning of the next row. When NOT softwrapping, showing a
"[" before the ">" kind of makes sense: to avoid having a gaping gap
there. But when softwrapping, all characters of the line will be on
the screen (except when going offscreen at the bottom), so there is
no need to show a placeholder for anything.
I imagine that when reading softwrapped Chinese or Japanese text,
things are easier to understand when no characters are shown that
are not actually in the text.
This avoids https://savannah.gnu.org/bugs/?57993.
Bug existed since version 2.8.6, commit 8490f4ac.
When the description of a keystroke starts with a very long word,
or when it does not contain any spaces at all (like for Chinese
and Japanese), do not break in the blanks before the description
but instead break IN the description, at the edge of the screen.
In other words: when wrapping a help text, do not consider blanks in
the first 17 columns to be blanks (unless it is a continuation line).
This fixes https://savannah.gnu.org/bugs/?57987.
Bug existed since version 4.8, commit 1486f32d,
when the wrapping of help texts was improved.
Keeping the invisible cursor at the left edge avoids any line getting
scrolled horizontally.
This fixes https://savannah.gnu.org/bugs/?57991.
Bug existed since version 2.8.2, since the help texts got generated
and displayed in a different way in order to become searchable.
When either only --disable-justify or --disable-speller is used, the
"Go To Line" item should not be placed after the ^C Position item, to
keep the subsequent items (Undo, Redo, and so on) nicely paired.
(Things changed since the Linter is no longer bound to ^T by default.)
This avoids an unintended rebinding of the <Backspace> key
on terminal emulators.
This fixes https://savannah.gnu.org/bugs/?57981.
Reported-by: Ciprian Tomoiaga <ciprian.tomoiaga@gmail.com>.
Only when the endpoint of the selection is actually IN a leading part,
then it should be advanced to include the whole leading part, so that
the succeeding paragraph will get the proper first-line indentation.
When justifying a selection from the middle of a paragraph, the first
line of both that selection and of the new paragraph after it should
get the same indentation as the first line of the original paragraph.
This fulfills https://savannah.gnu.org/bugs/?56308.
Benno Schulenberg