Re: nano hangs when pasting five characters

Benno Schulenberg <[email protected]> Fri, 28 Feb 2025 11:29:08 +0100
Newsgroups	gmane.editors.nano.devel
Message-ID	<[email protected]>
Op 27-02-2025 om 23:07 schreef Doug Smythies:
> The issue is not keystroke based, but time based.
> After the first one, 5 character pastes work fine if I paste repeatedly and rapidly.
> 5 character pastes are always split if I paste repeatedly but very slowly.

Yes, I suspected something like that when seeing, in your previous email,
eight pastes in a row go fine.

>                  key_buffer[waiting_codes++] = input;
> +               napms(2);  /* rate limit the input */

But when pasting, say, two thousand characters, it would take four seconds
for the paste to complete.  That is not acceptable.  (One of the reasons
for implementing bracketed pastes was to make large pastes go fast.  Going
slow again is not an option.)

While trying to simulate your problem locally, I created this little script:

   #!/bin/bash
   sleep 5

   xdotool key  --delay 0 Escape
   xdotool type --delay 0 "[200~"

   xdotool type --delay 0 "abcde"

   xdotool key  --delay 0 Escape
   xdotool type --delay 0 "[201~"

Then I run this script in the background (./paste.sh &) and run a nano
(src/nano -x_c README 2>TRAIL; grep hex TRAIL) and wait for the "ghost"
to simulate a paste, and exit with ^X^Q.  Which gives me this:

Sequence of hex codes:  1b  5b  32  30  30
Sequence of hex codes:  7e
Sequence of hex codes:  61
Sequence of hex codes:  62
Sequence of hex codes:  63
Sequence of hex codes:  64
Sequence of hex codes:  65
Sequence of hex codes:  1b  5b  32  30  31
Sequence of hex codes:  7e
Sequence of hex codes:  18
Sequence of hex codes:  11

What?  Why is the "~" split from the rest?  Does Xorg buffer things
by five bytes?  To check this, I made nano recognize also \e[41 and
\e[42 as opening and closing sequences of a bracketed paste.  With
an adjusted paste script, the first time I got this:

Sequence of hex codes:  1b  5b  34
Sequence of hex codes:  31
Sequence of hex codes:  61  62  63  64  65
Sequence of hex codes:  1b  5b  34
Sequence of hex codes:  32
Sequence of hex codes:  18
Sequence of hex codes:  11

Five subsequent times, I got this:

Sequence of hex codes:  1b  5b  34
Sequence of hex codes:  31
Sequence of hex codes:  61
Sequence of hex codes:  62
Sequence of hex codes:  63
Sequence of hex codes:  64
Sequence of hex codes:  65
Sequence of hex codes:  1b  5b  34
Sequence of hex codes:  32
Sequence of hex codes:  18
Sequence of hex codes:  11

Somehow something in the input pipeline seems to look at these codes
and thinks to know how long escape sequences are, and cuts them off
when a byte arrives that (it thinks) doesn't belong.

Then I modified nano to recognize \e[31 and \e[32 instead, as escape
sequences that start with \e[3 can be five bytes long.  Result:

Sequence of hex codes:  1b  5b  33  31
Sequence of hex codes:  61
Sequence of hex codes:  62
Sequence of hex codes:  63
Sequence of hex codes:  64
Sequence of hex codes:  65
Sequence of hex codes:  1b  5b  33  32
Sequence of hex codes:  18
Sequence of hex codes:  11

Indeed.  Something in the pipeline /thinks/ to know how long escape
sequences that start with \e[x can be, and breaks them up when they
are longer.  I begin to suspect ncurses.  It would mean that ncurses
sometimes forgets about the existence of \e[200~ and \e[201~.

Checked it for \e[58 and \e[59 too:

Sequence of hex codes:  1b  5b  35  38
Sequence of hex codes:  61
Sequence of hex codes:  62  63  64  65
Sequence of hex codes:  1b  5b  35  39
Sequence of hex codes:  18
Sequence of hex codes:  11


Benno
OpenPGP_signature.asc (application/pgp-signature, 840 B)