On Mon, Nov 06, 2023 at 03:18:00PM -0500, Chet Ramey wrote: > On 11/6/23 10:16 AM, John Tsiombikas wrote: > > > >I will not submit a patch, but I can explain what I meant. For instance > >if termcap says the sequence for homing the cursor is "ESC [ H" or the > >8bit equivalent, then you're probably dealing with an ANSI-compatible > >terminal, that will happily either take heed or correctly parse and > >ignore your bracketed paste sequence. > > OK, that's a start. Are there other capabilities that you can use to > differentiate between ANSI- and pre-ANSI- terminals? I'd rather not rely > on just one.
Sure, you could grab the ANSI spec (or the more easily available ECMA equivalent) and take your pick: https://ecma-international.org/publications-and-standards/standards/ecma-48/ Some examples: - clear screen: some combination of "ESC [ H" (home) with "ESC [ J" (clear from cursor to end of screen). - cursor move absolute: ESC [ <row> ; <col> H. - kill line: ESC [ K (can be "ESC [ 0 K" or "ESC [ 1 K" for cursor to begin, or cursor to end of line). - bold text: ESC [ 1 m (multiple rendition attributes can be combined before the m). - normal text: ESC [ 0 m, or just ESC [ m. "ESC [" in all that is the CSI (control sequence introducer), which in 7bit mode is the two-char sequence "ESC [", but alternatively, in 8bit mode it can be a single byte: 0x9b. > It's not any easier than users who have non-ANSI terminals turning off > bracketed paste in a bash or readline startup file. Sure, I just assume you want readline to do the right thing for each terminal automatically, and leave the config files for user preferences. I would consider sending ANSI sequences to a non-ANSI terminal as a bug, not a matter of preference to be left for user configurability, which is why I reported it in the first place. -- John Tsiombikas http://nuclear.mutantstargoat.com/
