The ceck is only done at the start of a line, because in other places
the BOM will be glued to the preceding character.
This partially addresses https://bugs.debian.org/964901.
Reported-by: Nils König <oneric@oneric.de>
Until the previous commit, nano used to beep for any command code
in an external paste. It's better to continue doing that.
(When pasting multiple lines, it's debatable whether nano should
beep for each discarded CR. But for any other command code, it
definitely should beep. Maybe it should even show a message.)
Ask ncurses to recognize the escape sequences that mark the start
and end of a bracketed paste, and thus benefit from the waiting that
ncurses does for an escape sequence to complete. This helps prevent
nano from failing to recognize an end-of-paste sequence (resulting
in hanging or inserting some sequence characters into the buffer).
This addresses https://savannah.gnu.org/bugs/?66858 in a better way.
Reported-by: Doug Smythies <dsmythies@telus.net>
Let the more general flaw handling (added in commit 41c1b962, and
amended in the previous commit) handle also this case: it's better
to let the user know that they are using poor pasting software than
to silently work around the issue.
This effectively reverts commit 555a9878 from last week.
If (on a bogged-down computer) a paste goes so slow that the bytes
come in one by one, nano shouldn't discard any of them -- the user
is unlikely to appreciate this. Just switch the bracketed paste
off, for the possibility that the closing sequence went missing,
and accept that this closing sequence gets pasted into the buffer.
Since the previous commit, the escape-sequence-parsing code does not
set 'bracketed_paste' to FALSE any more when the closing sequence is
deficient. So, the browser and viewer need to do that themselves.
Also, instead of just beeping and wordlessly discarding a paste when
it's done in the file browser or help viewer, report that it is being
ignored. This is much more friendly.
A bracketed paste should be one large batch (or several batches)
of bytes, not single bytes coming in one by one. When the latter
happens, assume the end-of-paste sequence got swallowed somehow,
stop the bracketed paste and display a warning, while discarding
the first byte that came in alone.
This change was inspired by this report from Doug Smythies:
https://lists.gnu.org/archive/html/nano-devel/2025-02/msg00001.html
When pasting something into nano over OpenSSH_for_Windows, the final
tilde of the end-of-paste sequence can lag some 29 ms behind the rest
of the sequence, causing ncurses to split it off into a next batch of
bytes. Accommodate for this by noticing the missing tilde and then
waiting at most one second for it to arrive. This prevents the tilde
from appearing spuriously in the buffer after the paste.
This addresses https://savannah.gnu.org/bugs/?66858.
Reported-by: Doug Smythies <dsmythies@telus.net>
When the user types something at the Execute prompt and then invokes
one of the six tools or special functions (that don't take any input),
stash the typed string and restore it upon the next invocation of the
Execute menu. This way the typed string is not lost when the tool or
special function was invoked by accident -- which it likely was, as
those tools and functions don't take any input from the prompt.
This addresses https://savannah.gnu.org/bugs/?66637.
Suggested-by: Evgeny Pestov <fsdhfhhf@gmail.com>
Also, remove redundant double quotes, protect single quotes from
possibly getting misinterpreted, and protect periods from getting
treated as end-of-sentence. Also, use \e instead of \\.
(Overlong lines are left alone -- they don't bother me.)
This partially addresses https://bugs.debian.org/1095957.
Reported-by: Bjarni Ingi Gislason <bjarniig@simnet.is>
Functions like tolower() expect characters in the range -1..255.
Reference: https://savannah.gnu.org/bugs/?50289.
The other occurrences of toupper(), tolower(), and isxdigit() that
don't do a cast are fine, because the values of 'code' or 'keycode'
are already guaranteed to be in range by the surrounding code.
