Re: bracketed paste ANSI sequence on non-ANSI terminals

[Chet Ramey]

On 11/6/23 10:16 AM, John Tsiombikas wrote:
> On Mon, Nov 06, 2023 at 08:57:28AM -0500, Chet Ramey wrote:
> > On 11/4/23 4:35 AM, John Tsiombikas wrote:
> >
> > > Detecting if a terminal is not ANSI-compatible and refraining from
> > > transmitting any, such as the bracketed paste in question, could be done
> > > at the very least by comparing termcap escape sequences for various
> > > things, if there's no better way I'm not aware of.
> >
> > Well, let's expand on these "various things." If you want to write up a
> > patch that encapsulates your meaning, I'll take a look at it.
>
> 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.

> Of course a more direct alternative, assuming there aren't going to be
> any new non-ANSI terminals coming out in the future (which is a good
> bet), is to just build a list of known non-ANSI terminals, but that's
> more work, and you might still miss some.

It's not any easier than users who have non-ANSI terminals turning off
bracketed paste in a bash or readline startup file.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/