Re: bracketed paste ANSI sequence on non-ANSI terminals

[John Tsiombikas]

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/