On 2025-05-10 15:49:20 +0100, Andrew Mass wrote: > One seemingly simple way to prevent this would be to sanitize / > disallow pasting buffers that contain this exact sequence. If > bracketed paste mode is active, it seems incorrect to me to allow > writing an "early" end sequence. > > I believe some other terminals take it a step further by sanitizing > all sorts of other potentially "dangerous" characters (e.g.: > https://gitlab.gnome.org/GNOME/vte/-/blob/master/src/pastify.cc)
It seems that xterm changes ESC to a space and NUL to \0 (2 characters). The other control characters seem unfiltered, which is fine with zsh. Note that this is independent on whether bracketed paste mode is active (for instance, this also occurs in cooked mode). Even though such characters should be safe if recognized as being part of the pasted text (it is up to the application running in the terminal to decide what to do with them), at least ESC can be confusing as it could be incorrectly interpreted as starting an arbitrary escape sequence. I suspect that NUL has a special meaning too. > Curious to hear what others' thoughts are on this, and whether a patch > along these lines would be seen as valuable. If so, I could try to > send one over. If you want to pass all characters, I'm wondering whether splitting the pasted text into 2 chunks could be a solution, so that the end sequence does not appear inside a chunk. But as I've said, ESC could be misinterpreted. IMHO, the bracketed paste protocol should have provided a way to pass a pasted ESC character via an escape sequence (and possibly other control characters, in case they would be filtered by the terminal). -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
