RE: nano hangs when pasting just a few characters
"Doug Smythies" <[email protected]>
| Newsgroups | gmane.editors.nano.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Benno, Thank you for your continued help, even though the root issue here seems to be with OpenSSH_for_Windows. On 2025.02.26 02:56 Benno Schulenberg wrote: > Op 26-02-2025 om 04:52 schreef Doug Smythies: >>> Thank you for the patch. It made no difference. I even tried a much bigger >>> delay and several in between delays. > > Okay. Then please try this other patch, attached. The patch seems to work. It leaves the spurious "~" character in the pasted text. But rings the bell and has a clear error message. >> I found some other paste buffer sizes that FAIL, in addition to the 5 >> characters already talked about. 85, 197, and 293 (there will be more, but >> that is as far as I got). > > No need to try all kinds of different sizes. But what I'm curious > about: it fails when pasting 5 bytes, but not when pasting 6 or 7? > If not, what does the "Sequence of hex codes" look like for those > pastes? (Because I would expect the end-of-paste escape sequence > to be broken there too.) Yes, I had the same thought, but they were all okay. I didn't include the "Sequence of hex codes", but do so now (edited): 3 character paste buffer: Sequence of hex codes: 102 Sequence of hex codes: 1b 5b 32 30 30 7e 31 32 33 1b 5b 32 30 31 7e Sequence of hex codes: 18 Sequence of hex codes: 6e 4 character paste buffer: Sequence of hex codes: 102 Sequence of hex codes: 1b 5b 32 30 30 7e 31 32 33 34 1b 5b 32 30 31 7e Sequence of hex codes: 18 Sequence of hex codes: 6e 5 character paste buffer (different file): Sequence of hex codes: 104 Sequence of hex codes: 1b 5b 32 30 30 7e 31 30 30 30 30 1b 5b 32 30 31 Sequence of hex codes: 7e Sequence of hex codes: 18 6 character paste buffer: Sequence of hex codes: 102 Sequence of hex codes: 1b 5b 32 30 30 7e 31 32 33 34 35 36 1b 5b 32 30 31 7e Sequence of hex codes: 18 Sequence of hex codes: 6e 7 character paste buffer: Sequence of hex codes: 102 Sequence of hex codes: 1b 5b 32 30 30 7e 31 32 33 34 35 36 37 1b 5b 32 30 31 7e Sequence of hex codes: 18 Sequence of hex codes: 6e 10 character paste buffer: Sequence of hex codes: 102 Sequence of hex codes: 1b 5b 32 30 30 7e 31 32 33 34 35 36 37 38 39 30 Sequence of hex codes: 1b 5b 32 30 31 7e Sequence of hex codes: 18 Sequence of hex codes: 6e I am not sure of the exact key sequence to recreate it, but sometimes a 5 character paste buffer works: Sequence of hex codes: 1b 5b 32 30 30 7e 31 32 33 34 35 1b 5b 32 30 31 Sequence of hex codes: 7e ... Sequence of hex codes: 1b 5b 32 30 30 7e 31 32 33 34 35 1b 5b 32 30 31 Sequence of hex codes: 7e ... Sequence of hex codes: 1b 5b 32 30 30 7e 31 32 33 34 35 1b 5b 32 30 31 7e Sequence of hex codes: 18 >> If I use PuTTY instead of OpenSSH_for_Windows these buffer lengths work >> fine, suggesting that the root issue is with the OpenSSH_for_Windows code. > > Yes, the root issue is the OpenSSH_for_Windows splitting an escape > sequence. But... if PuTTY works fine, I would strongly suggest to > just use that. Fair point. For decades I used to use PuTTY, but now prefer OpenSSH_for_Windows. >> [...] >> Sequence of hex codes: 33 34 35 36 37 38 39 30 31 32 33 34 35 >> 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 >> 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 >> 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 >> 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 >> 32 33 1b 5b 32 30 31 >> >> Sequence of hex codes: 7e > > This seems to suggest that OpenSSH_for_Windows does notice the escape > sequence, but thinks that something that starts with "[2" (5b 32) has > two more bytes, where in fact it has three. I think the attached patch > will catch and work around this issue. Agreed. I have cloned the OpenSSH_for_Windows repository, but so far haven't found the proper area of the code. I think I should move my "discussion" to an "issue". https://github.com/PowerShell/Win32-OpenSSH/discussions/2330 ... Doug