Speller, linter, formatter, and execute-a-command cannot be used in
restricted mode, but the relevant keys should report that the function
is *disabled*, not that the key is unbound.
This fixes https://savannah.gnu.org/bugs/?64226.
Problem existed since version 3.2, since nano reads the nanorc files
also in restricted mode.
This suppression prevents the filename flashing by at the bottom
of the screen when switching between buffers.
This addresses https://savannah.gnu.org/bugs/?64019
Reported-by: Alan Cristhian Ruiz <alancristhian@protonmail.com>
Problem existed since version 6.0, since --zero was introduced.
Various tools will output filenames with line numbers in the format
<filename>:<line>:<column>. Support this format in addition to the
+<line>,<column> format when opening files.
Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The isxxxxx() functions expect their parameter to be either EOF or
a value in the unsigned char range. Passing a negative char value
could (in theory) result in unexpected behavior.
In view mode it should be impossible to modify any buffer, but...
when (through some bug) the user did succeed in modifying a buffer,
this should not lead to writing out this modified buffer to disk.
Had this safety stop been present earlier, it would have prevented
the second part of https://savannah.gnu.org/bugs/?63616.
A string bind can only contain bytes (chars), not keycodes (integers,
in nano upto 0x4FF). So, apart from an error code or a placeholder
command code, get_code_from_plantation() can only return a byte.
The function get_code_from_plantation() should return ERR only when
the string bind is fully exhausted. In the normal case, where some
bytes are still available, it should return the first of these bytes,
so that the {verbatim} function will work too.
This fixes https://savannah.gnu.org/bugs/?63702.
Bug existed since version 7.0, commit 958ec294,
since command cartouches were introduced.
This separation avoids the impression that we're thanking the mentioned
people for their use of nano (something they probably don't do).
(Also, remove two other blank lines -- effectively moving these two
lines further up, keeping the total amount of whitespace the same.)
When in view mode, nothing shouldbe allowed to be entered into
(or deleted from) the buffer.
This fixes https://savannah.gnu.org/bugs/?63616.
Reported-by: Timothy Liu <liuxf19@163.com>
Bug existed since version 4.8, commit 0e6d693d.
That is: do not silently return from parse_one_include() when the
given file does not exist, *and* return the filename (or pattern)
itself when it matches nothing.
This fixes https://savannah.gnu.org/bugs/?63446.
Bug existed since version 4.0, commit d3f0d32e.
This prevents an unwanted message when nano
is compiled with -fsanitize=undefined.
This fixes https://savannah.gnu.org/bugs/?63447.
Problem existed since version 4.8, commit 343f97b3,
since the --rcfile option was added.
Make sure that there is only whitespace to the left of the cursor
before setting 'allblanks' to TRUE, because this latter value will
cause these characters to be eaten (as a special case, to avoid
creating lines that contain only blanks when both --autoindent
and --breaklonglines are on).
This fixes https://savannah.gnu.org/bugs/?63407.
Reported-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Bug existed since version 2.9.8, commit d00ab406.
This places the cursor in a more predictable position.
This fixes https://savannah.gnu.org/bugs/?63223.
Issue existed since version 4.4, commit a9dd73fb,
since the +/string feature was introduced.
Not just for +/ (a search command without a string) should nano report
an "Empty search string", but also for +c/ or +r/ or similar.
This fixes https://savannah.gnu.org/bugs/?63222.
Bug existed since version 4.4, commit 2326bf69.
When the user interrupts an external command that hangs or takes too
long, nano should also kill the data-sending process (when present).
This fixes https://savannah.gnu.org/bugs/?63177.
Bug existed in this form since version 4.3, commit d946f38a,
but basically existed since version 3.0, commit ec339d3b.
When something goes wrong while executing an external command or while
piping text to it, report an error on the status bar and restore the
state of the buffer to what it was before the execution.
This fixes https://savannah.gnu.org/bugs/?63114.
Bug existed since version 2.9.8, since filtering text was introduced,
but basically existed since before version 2.0.0, since executing an
external command was introduced.
The execute_command() function — then called open_pipe() — was changed
to have a boolean return value in commit ce62e82a eighteen years ago,
but the value has never been used or checked.
The function line_from_number() can handle only line numbers that exist,
and will crash otherwise. (The lack of checks makes the function fast.)
This fixes https://savannah.gnu.org/bugs/?63120.
Bug existed since commit d1e28417 from five weeks ago.
Since commit c848ec3d from three years ago, nano has assumed that
'char' is always a single byte. So... elide the last occurrences
of sizeof(char), as they give a false impression of generality.
The function recode_LF_to_NUL() has to iterate over the string anyway
(to replace each \n with \0), so... instead of calling strlen() right
before it, just let recode_LF_to_NUL() return the length of the string.
(This is not speed-critical code, but... it saves one iteration over
the entire buffer contents whenever writing out a file.)
(There is no need to recode the NULs back to LFs because the sending of
the data happens in a separate process, which then simply disappears.)
This fixes https://savannah.gnu.org/bugs/?63106.
Bug existed since version 2.9.8, since filtering a buffer or a region
through an external command was introduced.
Not quitting would make nano hang for several seconds (which is very
annoying) and then die and save an emergency file (which is useless).
This fixes https://savannah.gnu.org/bugs/?63109.
Bug existed chiefly since version 5.9, commit 8d1a666d,
but basically existed since before version 2.0.0.
Analogous to commit 3922b531: instead of allocating and later freeing
a tiny fragment of memory for every character that the user enters (in
the edit window or at a prompt), reserve a small piece in the beginning
and retain it, and increase (but never decrease) its size as needed.
This addresses the second part of https://savannah.gnu.org/bugs/?63086.
In theory, the 'size_t' of 'capacity' could be just two bytes, which
means the keystroke buffer would overflow for pastes that are larger
than 32 kilobytes -- which are unlikely to occur, but... possible.
However, previously there was *no* overflow check when extending the
keystroke buffer (only when trying to put back a key code), so this
check is an improvement.
(On a regular machine, 'size_t' is at least four bytes, which means
the keystroke buffer would overflow at 2 gigabytes. Such a paste
is extremely unlikely to occur, so this check is really a no-op.)
Instead of allocating and freeing a tiny fragment of memory for every
keystroke, reserve a small piece in the beginning and then retain it,
because it will be needed again and again and again. Increase the size
when needed (for a large paste, probably), but don't bother to shrink
it afterward.
This addresses the first part of https://savannah.gnu.org/bugs/?63086.
Move the triggering of the line redraw out of the error path, and
into a better place: next to the normal clearing of the feedback.
This fixes https://savannah.gnu.org/bugs/?63053.
Bug existed since version 6.0, commit 6d828cf4.
As the magic line isn't really a line (it is not counted in the number
of lines read and written), and nothing is on it (not even a newline),
it doesn't make sense to allow any regex, like ^ or $, to match it.
This fixes https://savannah.gnu.org/bugs/?63034.
Indirectly-reported-by: Mike Scalora <mike@scalora.org>
Bug existed since before version 2.0.0.
Calling strstrwrapper() with the Backwards, Casesens, and Regex flags
unset is equivalent to calling mbstrcasestr(). So... do that instead
and quit saving and restoring the flags for each call of findfile().
This saving-and-restoring has been redundant since commit b0957254
from eight years ago.
The dots gave the impression that the next keystroke (hex digit) would
land somewhere on the dots. But this is not so -- the current digits
are instead shifted to the left and the new digit is added at the end.
Also adjust and improve several comments.
Also elide three calls of tolower(), using ORing with 0x20 instead,
as we're dealing with plain ASCII here.
Rename a variable too, away from a double abbreviation.
Instead of requiring always six digits, allow the user to indicate
with <Enter> or <Space> that the digits typed so far are the complete
Unicode code point (when prefixed with the missing number of zeroes).
This fulfills https://savannah.gnu.org/bugs/?63021.
Inspired-by: the <Ctrl+Shift+U> shortcut that some desktops have
This does not quite do what I would have liked (scroll only when needed)
when on a softwrapped line and jumping to a different chunk, but... it's
still better than needlessly centering the line.
(The user can still center the line, if that is what they want, by using
a period or a slash instead of a comma.)
This addresses https://savannah.gnu.org/bugs/?63008.
Nobody will configure nano with --enable-tiny --enable-extra, but *if*
someone does, the title bar should be absent during the crawl.
Also, swap two messages, so that their order in the POT file will be
more sensible -- a closing brace comes after the function name.
"Cannot map name %s to <thing>..." was unnecessarily verbose and vague.
I have kept these strings unchanged all these years because I didn't
want to invalidate the existing translations. But now it's time to
harmonize things and simply say "Unknown <thing>: %s" for an invalid
function name, menu name, option name, and syntax name.
("No such <thing>: %s" is nice and snappy, but its translations often
are clumsy and longer and unclear.)
(It is a harmless leak, but LeakSanitizer is loud when it complains.)
After having determined that there is a menu name, first check that
it is valid, before processing the string or the function name.
This fixes https://savannah.gnu.org/bugs/?62991.
Problem existed since version 2.9.4, since string binds were introduced.
This makes more sense than letting the formatter and the linter depend
on ENABLE_COLOR (which maybe should have been named ENABLE_SYNTAX).
This fulfills https://savannah.gnu.org/bugs/?50080.
Six years ago, commit a878f5f1 introduced a call of regenerate_screen()
directly in the input routine, which made the call of refresh_func() in
the prompt routine redundant -- except when in the file browser.
Since version 6.0, with option --zero, the edit window can cover
the whole terminal. Make use of this also for the credits crawl.
Also, shorten and quicken the crawl a bit, and make it start always
on the bottom row, instead of (for mysterious reasons) one row higher
when the terminal has an odd number of rows.
Furthermore, don't put back the key the user typed to stop the crawl.
Instead of starting always from the top of the buffer, start at the
current line, as it is quite likely to be near the target line.
(Since the previous commit we're assuming that openfile->current is
always valid, so we might as well make use of this assumption.)
Also, rename a parameter to make its meaning more explicit.
After undoing an <Enter> or redoing a line join, it is likely that the
"eaten" and freed line was the current line. In fact, goto_line_posx()
should not refer to it any more, but... accommodate for this and just
set openfile->current to a valid value before calling goto_line_posx().
This fixes https://savannah.gnu.org/bugs/?62952.
Bug existed since version 6.3, commit eea3e1f0.
Checking for the literal ^N, ^Q, and ^Y before checking for do_toggle
and full_refresh made it impossible to rebind any of those keystrokes
to these two functions. (Not that anyone would want this, but...)
Problem existed since version 4.3, commits 341601e1 and 82aea04c.
This allows specifying bindable functions in a string bind by name
instead of by the literal control code or escape sequence to which
they are bound, which makes for a much more readable string bind,
and also allows specifying functions that are not bound to any key.
The opening brace, {, is made into a special symbol inside a string
bind, and each literal occurrence there needs to be escaped as {{}.
This fulfills https://savannah.gnu.org/bugs/?61692.
Requested-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Original-idea-by: Brand Huntsman <alpha@qzx.com>
https://lists.gnu.org/archive/html/nano-devel/2018-02/msg00006.html
This makes that the three options that change the default layout
of the interface (--stateflags, --minibar, --zero) come last.
Also, sort the option letters into a consistent order in the code.
(That 'also_the_last' now gets reset to FALSE whenever the cursor moves
to a different line is fine -- it is redundant when the mark is off, but
it does no harm.)
It was silly to check again specifically for <Del> and <Bsp> after
any possible keystroke had been handled. It was an anomaly.
This makes the tail of do_deletion() similar to the tail of inject().
(That sometimes the current line is redrawn twice is acceptable -- how
often does one type <Backspace> while having Shift-selected something?
Normally one wouldn't, because it would cancel the selection, so it's
fine to accept some inefficiency for this case.)
The checking for all functions that are marked as not-okay-for-view-mode
was excessive and unneeded. It had been inherited from commit d47d8cd4
from thirteen years ago, and was never verified for correctness.
This addresses the main part of https://savannah.gnu.org/bugs/?62903.
The linter has been marked as NOVIEW since it was introduced in 2.3.3.
But that was a mistake, as the tool does not change the buffer contents.
This addresses a minor part of https://savannah.gnu.org/bugs/?62903.
This is especially meant to avoid dereferences of 'shortcut' after its
linked function has been executed, because in an upcoming commit this
execution may have freed the shortcut's structure.
(For symmetry, make the same change also in do_statusbar_input(), even
though it is not needed there.)
This addresses one part of https://savannah.gnu.org/bugs/?62899.
The only menus that are accessible in view mode are WhereIs, Insert,
WhereIsFile, GoToDirectory, and Help. In the WhereIs menu, the only
keystroke that is not allowed in view mode (^R) is caught explicitly.
In the other four menus, all available shortcuts are permissible in
view mode, so... there is no need to check them at execution time.
(The ^R keystroke in the WhereIs menu is still shown in view mode
so as not to upset the pairing of the subsequent shortcuts.)
Since commit 63f2be7a from four years ago, view mode always sets
multibuffer mode, allowing ^R (Insert) to be invoked. But the
user is then not allowed to switch multibuffer mode off, so...
don't show the toggle.
This allows one to complete also words that are present in other files
(when these are open in other buffers).
This fulfills https://savannah.gnu.org/bugs/?61691.
Requested-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Original-patch-by: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
When confirm_margin() first sets the margin needed for the requested
line numbers, also then it needs to keep 'focusing' TRUE. Only when
actually toggling --linenumbers ON (from a zero margin to something)
should focusing be suppressed, in order to obtain smooth scrolling
when the cursor is pushed off-screen.
This fixes https://savannah.gnu.org/bugs/?62885.
Bug existed since version 4.4, since the search-at-startup feature
was introduced.
In many keyboard layouts M-< and M-> are awkward to type (in a Spanish
layout, for example: Alt+Shift+AltGr+Z and Alt+Shift+AltGr+X when there
is no LSGT key), whereas M-, and M-. are simple two-key keystrokes in
most Latin-script layouts. So, show M-,/M-. before showing M-</M->.
Also, make a condition more precise, to not show M-Left and M-Right in
the tiny version, when those shortcuts are not understood.
Since version 6.0, Suspend is no longer bound by default, which meant
that it dropped out of the help lines, leaving the items after it in an
unpaired arrangement. Move the Suspend item and its intended partner
to near the end of the list, to reestablish pairing for several items.
This makes invoking the formatter cleaner, by giving feedback and *not*
leaving curses mode. Leaving curses mode had the small advantage that
any messages from the formatter would be on the terminal after closing
nano. But it had the disadvantage that invoking the formatter flashed
the screen.
This basically reverts commit 2b9f0619 from three years ago and then
solves the issue of intruding formatter messages in a different way.
This fulfills https://savannah.gnu.org/bugs/?62789.
Requested-by: Gert Cuykens <gert.cuykens@gmail.com>
Also, elide an unneeded condition: when not softwrapping, left_x will
be zero, which is always smaller than or equal to the indentation.
Furthermore, reshuffle a few lines, improve three comments, and adjust
one to mention the parameter that was added in the previous commit.
This adjusts the main softwrapping routine so that it remembers the
reached point in a line's text and the corresponding column. This
avoids having to scan the line from the beginning for each iterative
call, and thus saves a substantial amount of time when softwrapping
very long lines.
This mitigates https://savannah.gnu.org/bugs/?62442.
Reported-by: Devin Hussey <husseydevin@gmail.com>
Original-patch-by: Devin Hussey <husseydevin@gmail.com>
The double slash would derail the file browser, causing a crash.
This fixes https://savannah.gnu.org/bugs/?62760.
Reported-by: Frank Wolff
Bug existed since version 6.3, commit fdd946c0.
Due to CVE-2022-24765, Git refuses to operate on local repositories if
it runs as a different user from its owner. Since version 2.35.2:
$ sudo git describe --tags
fatal: unsafe repository ('/home/lh_mouse/GitHub/nano-win' is owned by someone else)
To add an exception for this directory, call:
git config --global --add safe.directory /home/lh_mouse/GitHub/nano-win
Conventionally, a user, who wishes to build and install nano from Git,
does this:
$ ./configure
$ make
$ sudo make install
The first `make` command builds the program as the current user.
The `make install` then installs the built files.
However, we have a recipe for 'revision.h' that is always executed,
even in the case of `make install`. As here it is run as root, Git
actually fails and produces an empty string. This causes `make install`
to rebuild nano.o and winio.o and results in an empty version string in
the upper left corner.
The solution is simple: First we attempt a dryrun of `git describe`.
If it fails, 'revision.h', which should have been updated by the first
`make` command, will be left intact.
Reference: https://nvd.nist.gov/vuln/detail/CVE-2022-24765
Signed-off-by: LIU Hao <lh_mouse@126.com>
When one wants an Undo to restore the cursor to where it was before an
operation, one shouldn't fiddle with the position before it is stored
in the relevant undo item.
This fixes https://savannah.gnu.org/bugs/?62341.
Bug existed since version 4.9, commit 38af812a.
(This effectively reverts commit 38af812a from two years ago.)
For some reason, when copying something to the system clipboard
with 'xsel', it wants to see all output descriptors closed before
it will exit without requiring ^C.
This fixes https://savannah.gnu.org/bugs/?62276.
Reported-by: Shi Yanling <sylphenix@126.com>
Bug existed since version 2.9.8, since piping text through an
external command was introduced.
Instead of silently opening an empty buffer when the user tries to
open a file in the current but disappeared directory, give a clear
warning about the absence of this directory.
This improves the fix for https://savannah.gnu.org/bugs/?62244.
When the working directory has been deleted from under nano's feet,
get_full_path() would move up in the directory tree until getcwd()
would succeed. This meant that a filename that was specified on the
command line without any path (or with a relative path) would refer
to a different file than what the user intended. Not good.
So, stop changing directories in get_full_path(). Use the realpath()
function with NULL as second parameter instead -- it has been part of
the POSIX standard since 2008, time enough for operating systems to
have caught up.
In the bargain, this saves seventy lines of complicated logic.
This fixes https://savannah.gnu.org/bugs/?62244.
Bug existed since version 2.0.0, commit 85e35e67.
Especially when softwrapping and when multiline regexes are involved,
colorizing takes roughly exponential time relative to the line length.
To avoid bogging down, stop colorizing a line beyond a certain point.
This mitigates https://savannah.gnu.org/bugs/?61799.
Reported-by: Devin Hussey <husseydevin@gmail.com>
Although an anchor at the top line is rather pointless, it shouldn't
get cleared when the user pipes just a part of the buffer through an
external command.
When the filter command makes just small, per-line changes, keeping the
cursor at the same line number allows the user to observe the effect of
the changes -- which is not possible when the cursor gets moved to the
end of the buffer.
This partially fulfills https://savannah.gnu.org/bugs/?57248.
The same line number may not be the same position in the text, but
it will be approximately -- and it is certainly better than leaving
the cursor at the end of the buffer.
This fulfills https://savannah.gnu.org/bugs/?61175.
When making a forward movement larger than a screenful, we cannot rely
on the multidata of the line before the new screen start to have been
set correctly by a previous screen drawing, so we need to recompute all
of the multidata, for the whole buffer, so that afterward we can freely
move around and draw the screen without having to do any backtracking.
Also when a piece of text larger than a screenful is pasted or inserted,
all the multidata needs to be recomputed.
This fixes https://savannah.gnu.org/bugs/?60041,
and fixes https://savannah.gnu.org/bugs/?62056.
First bug existed in this form since version 2.4.2, commit d49c267f
(but editing Python was incomparably slower in those days).
Second bug existed since version 5.6, commit 43d94692.
This does not waste time looking for an end match, which is especially
wasteful when there is none. Also, it makes the coloring behavior more
consistent: any start match will cause coloring of the subsequent text,
no matter whether the user is in the middle of the file or near the end.
As it's possible for the start regex to match what is actually the end
match of a multiline thing (see the Python triple quotes, for example),
make sure that such a detected start match is *not* an end match, just
to avoid a needless full-screen refresh.
This makes nano conform to the https://no-color.org/ idea: suppressing
any color in the output (in the default setup) when NO_COLOR is set in
the environment.
Specifying a color for any interface element will, however, re-enable
also yellow for the spotlight and red for error messages.
This mitigates https://savannah.gnu.org/bugs/?36864.
Reported-by: Clarence Risher <sparr0@gmail.com>
Problem has existed since the beginning, as nano empties the existing
file before writing the current buffer contents into it.
Fix building with x86_64-w64-mingw32 to cross-compile native Windows
programs. Need to:
* add checks for missing functions
* don't use signals that are unavailable on the platform
* avoid useless non-Linux sys/ioctl.h include
* use putenv instead of setenv as the latter is unavailable
That is, take into account that the cutbuffer could be NULL
(when updating the undo item).
This fixes https://savannah.gnu.org/bugs/?62107.
Bug existed since version 4.9, commit b15c5a7e.
The 'endmatch.rm_eo' value is relative to the end of the start match,
so to find the end of the end match, one has to add 'startmatch.rm_eo'
plus 'endmatch.rm_eo' to the starting point of the line.
This addresses https://savannah.gnu.org/bugs/?62091.
Problem existed since version 5.6, commit 0596b875.
In version 2.2.0, pyflakes changed its output format,
from 'filename:line: text' to 'filename:line:column text'.
This fixes https://savannah.gnu.org/bugs/?62057.
Problem existed since version 2.9.0, commit 5dcf375f.
(That commit tried to compensate for an introductory message from gcc
that no longer seems to exist.)
The new name 'gauge' more clearly indicates that it is a distance
between two "columns", two "pillars", two "piles". Using 'longest'
was poor, because in fact it was set to 'widest + 10'.
(Also, change the type of 'piles' to an integer -- it will always
be smaller than COLS, and COLS is an integer.)
A newer compiler (gcc-10.3) said: browser.c:174:34: warning:
field width specifier '*' expects argument of type 'int'
It's fine for 'longest' to be an integer, as a filename in Unix is
at most 255 bytes long, which can occupy at most 510 columns (when
the name consists entirely of control codes), and that fits easily
within an 'int', which has at least fifteen bits, unsigned.
Well... in theory 'tabsize' could be set to an insanely high number,
and if a filename contains several tabs, this could cause 'longest'
to overflow. (Why doesn't the compiler warn about that?) If that
were to occur, and the filename with the tabs were the last in the
list, then 'longest' would get set to the minimum width: 15. That
would not be correct, but... nothing bad would happen.
This addresses https://savannah.gnu.org/bugs/?62014.
Reported-by: Mike Frysinger <vapier@gentoo.org>
This wipe suppression is meant to prevent the last row of the edit window
getting cleared when edit window and bottom window overlap, and this is
relevant only when the user is actually editing -- the file browser and
help viewer take care not to use this bottom row for content.
This fixes https://savannah.gnu.org/bugs/?62031.
Bug existed since version 6.0, commit be61aad9.
Problem existed since commit 3b657a26 from five days ago.
In addition, exclude pasting-at-the-prompt from the tiny version, as
it's hardly useful when one cannot copy a selected piece of text.
When re-entering curses mode, ncurses will pick up the new size of
the terminal and set the LINES and COLS variables appropriately.
(We don't ask the terminal for its size when nano starts up, so why
would we need to do it when the terminal is resized?)
Since version 2.8.7 the user can paste text at the prompt (with ^U),
but the ability to copy what is present at the prompt was overlooked.
For feedback, the cursor is moved to the start of the answer -- like
it moves to the start of the next line when in the edit buffer.
This addresses https://savannah.gnu.org/bugs/?61702.
Reported-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
In most cases, the cursor will be at the end of what the user typed
at the prompt (or retrieved from history), and ^K will work as it
always did, erasing the whole answer. But if the user has moved the
cursor to somewhere in the middle of the answer, a ^K will now erase
just the part after the cursor. A second ^K will erase the rest.
Inspired-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Because doing the spotlighting after those extra keycodes have been
handled will most likely spotlight the wrong piece of text. Also,
if those keycodes hadn't arrived early, the first of them would have
cancelled the spotlighting.
This fixes https://savannah.gnu.org/bugs/?61962.
Bug existed since version 5.8, commit 3f340836.
When a large piece of text was pasted into nano, then the old way of
repeatedly moving the buffered text one more position toward the head
of the keystroke buffer would waste a lot of time. With this change,
pasting the current NEWS file into a buffer goes down (on my machine)
from around 30 seconds to just 2.
This addresses https://savannah.gnu.org/bugs/?61822.
Reported-by: Radu Caragea <rcaragea@protonmail.com>
Problem existed in this form since version 1.3.6, commit 7483571f.
When the user exits with ^X and gets warned that the file on disk
has changed, then typing ^C at the question whether to continue
saving should not discard the buffer and exit, but should return
the user to the filename prompt.
This fixes https://savannah.gnu.org/bugs/?61883.
Reported-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
Bug existed since version 2.9.0, commit 217cfbf3.
And don't mention <Tab> for the 'indent' function, as the keystroke
is equivalent to M-} only when lines are marked.
Reported-by: Tasos Papastylianou <tpapastylianou@hotmail.com>
The value of 'consumed' may not exceed the given 'length'.
Bug existed since version 2.9.3, commit e739448c.
(Bug was found by studying Fedora crash reports. Thank you, Fedora!)
