This fixes https://savannah.gnu.org/bugs/?62912.
Bug existed since commit 958ec294 from earlier today,
but was enabled by commit 433dd921 from three days ago.
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.)
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.
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>
Normally, returning to the main loop will set 'focusing' back to TRUE,
but the replacement loop doesn't return until replacing is finished.
This fixes https://savannah.gnu.org/bugs/?61397.
Bug existed since version 5.0, commit d8249917.
If all is programmed well, then the functions 'get_older_item' and
'get_newer_item' will only occur when a history list is passed to
acquire_an_answer(). But let's keep it certain we don't dereference
a NULL pointer.
When the user immediately cancels a search (^W^C), then nothing in
the history stack has changed, so then there is no need to reset the
history pointer to the bottom.
This slightly improves the fix for https://savannah.gnu.org/bugs/?61316.
This also gets rid of an assignment in an 'if' clause (twice),
elides a local variable, and makes it clearer that a pointer
gets moved to the previous or next item (instead of hiding it
as a side effect of the function call).
Whenever invoking a search prompt, calling up historical search items
should start with the newest item.
This fixes https://savannah.gnu.org/bugs/?61316.
Bug existed since version 2.8.2, since help texts became searchable.
When the answer at the prompt was clear before the user went up into
the history list, the answer should be cleared again when the user
comes back down to the present.
This fixes https://savannah.gnu.org/bugs/?61308.
Bug existed since before version 2.2.0.
We want to reduce the size of the answer by one byte,
not keep the full answer (plus terminating NUL).
This fixes https://savannah.gnu.org/bugs/?60764.
Bug existed since version 2.9.8, commit f304b9ae,
since piping text to an external command was introduced.
When the tail of the answer still fits exactly on the screen, the ">"
continuation character should not be shown -- also when the start of
the answer is "scrolled off" to the left.
This fixes https://savannah.gnu.org/bugs/?59816.
Bug existed in this form since version 4.0, commit 56181896.
When making small movements in the lower right corner, ncurses can
get confused about where the cursor actually is -- a double-width
character seems to throw its calculations off.
This addresses https://savannah.gnu.org/bugs/?59808.
Bug existed since version 5.4, commit 39705c60.
It was only ever needed when the user lied about the size
of the terminal, which should be considered a user error.
It was a workaround for https://savannah.gnu.org/bugs/?48852.
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>
During verbatim input at most four integers are produced (the longest
possible unicode sequence), so use the value 999 to indicate a special
condition (a screen resize) that should not enter anything into the
buffer AND should not produce any error message or beep.
This fixes https://savannah.gnu.org/bugs/?58923.
Bug existed since version 5.0, commit 5899181a.
The codes from (for example) U+D800 to U+DFFF are invalid. If any
such invalid code is entered at the Unicode Input prompt, nano should
not act as if the code was accepted and inserted into the buffer, and
should certainly not mark the buffer as Modified.
This fixes https://savannah.gnu.org/bugs/?58714.
Bug existed since version 4.9, commit b3faf353.
This gives quicker feedback, and spares the user unnecessary beeps
and typing. Also, now a beep after a <Tab> means just one thing:
there are NO completions.
This fulfills https://savannah.gnu.org/bugs/?58627.
The parameter was referenced in just one place. So, simply check for
the three relevant menus (and unrestricted mode) and be done with it.
This also has the pleasant effect that the menu name is now the first
parameter of do_prompt(), thus clearly indicating what prompt it is,
instead of having an opaque TRUE or FALSE value at the beginning.
