Newlines in paste not working in Alacritty / Kitty

[lentinj]

With the Debian unstable package of alacritty (0.16.1) & kitty (0.45.0), mainline ne (3827b58) doesn't seem to interpret newlines in bracketed paste correctly.

With bracketed-paste enabled, copy-paste more than one line into ne, e.g:

abc123
abc456

Instead of 2 lines, the newline triggers gotoline, and abc456ends up in the line number prompt. Running ne with --no-bpaste means everything works fine. This is not a problem under xterm, there bracketed paste works as expected.

Note that KeyCode for Ctrl-j (i.e. line number) reports 0x0a (i.e. "\n"), which is where the confusion likely comes in.

This isn't just ne, buggy bracketed paste seems to be a common refrain in both Alacritty & Kitty issue trackers, variously blaming applications, tmux, TERM settings & issues closed.

I think the most interesting is this one: kovidgoyal/kitty#994 / https://savannah.gnu.org/bugs/?49176, which resulted in bodging newlines in (non-bracketed) paste to \r before sending on. Both KiTTY and Alacritty do this. I've not investigated why it's not a problem in xterm. Presumably whatever converts to \r happens regardless of paste mode though.

I'm guessing what needs to happen is that the CHAR_CLASS should always be ALPHA when in bracketed paste mode, but I've not tried fixing yet.

[vigna]

I really don't know anything about that part, as @utoddl implemented it in its entirety. Seems like a terminal problem, tho. Did you try in Mac Terminal/iTerm?

[lentinj]

Seems like a terminal problem, tho

I don't disagree, but the terminal authors seem pretty adamant this is how it should work, and apps should handle \n in bracketed paste input.

Did you try in Mac Terminal/iTerm?

Nope, I don't have a mac to hand. However...

Suckless terminal does \n -> \r regardless of bracketed paste or not, so ne works fine there: https://git.suckless.org/st/file/st.c.html#l622

xterm.js will also do \n -> \r on bracketed paste (both the highlighted methods are run in turn on a paste).

Even if kitty & alacritty are technically correct, I'm not sure they're winning the battle.

Regardless of who is right though, not accepting COMMAND input when cur_buffer->bpasting == 1 seems like it'd be a sensible thing for ne to do.

---

One workaround is to bind ctrl-J to "Return", i.e. in .ne/.keys:

KEY 0x0a InsertLine

...and then the issue becomes moot (well, bar ctrl-j not working of course).

[utoddl]

This is the result of an unfortunate, long-standing misunderstanding on the part of @kovidgoyal about the purpose of bracketed paste. To be fair, he has a point, and I actually have some sympathy for his principled stance, which is

The whole point of bracketed paste mode is that it allows pasting unmodified text (barring the bracket paste termination sequence), without security issues.

That's not correct. It's to notify the program that the incoming data was "typed" by a paste rather than the normal method. In the absence of the bracketed paste start and end sequences, the data should be identical. His implementation breaks that principle.

Later he says

[another editor] is not interpreting newlines in pasted text when bracketed paste is enabled. It is expecting carriage return instead of newline to terminate lines. This is wrong. kitty converts newlines to carriage returns when not in bracketed paste only. See kovidgoyal/kitty#994 for discussion.

This also is wrong. Except for the begin/end sequences and timing, the input streams should be indistinguishable. Instead he's chosen a terminal implementation of bracketed paste which is at odds with all other terminal implementations (with the exception of alacritty apparently). In other implementations, a begin and end sequence brackets the pasted data. That's it. In his implementation, in addition to bracketing the data, he alters how he handles that data, specifically he quits doing the \n->\r conversion the editors otherwise expect.

We can put in an awful hack that does the missing \n->\r conversion when in bracketed paste mode to work around this alacritty/kitty implementation issue.

That will open wider a somewhat ignored issue: If the bracketed paste begin sequence is received but the end sequence is never received, then the editor is stuck in bracketed paste mode. This wasn't an issue before because you could still enter ^j, but with this hack in place that functionality will be broken until a bracketed paste end sequence is received. It may be prudent to deactivate bracketed paste after some period of inactivity. Oh well, one awful hack at a time...

[vigna]

We can put in an awful hack that does the missing \n->\r conversion when in bracketed paste mode to work around this alacritty/kitty implementation issue.

I beg you, let's not 😂.

[utoddl]

Oh. Um. Hm. It does seem to be the "solution" adopted by other editors.
And I did just push it. (Sorry!)

[vigna]

Ha ha ok. We resisted 35 years without "fixing" the backspace thing, I guess we can have some wiggle room for bracketed pastes 😂.