bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] bracketed paste support


From: Daniel Colascione
Subject: Re: [PATCH] bracketed paste support
Date: Thu, 06 Nov 2014 02:45:49 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

On 11/06/2014 02:38 AM, Chet Ramey wrote:
> On 11/5/14 9:02 PM, Daniel Colascione wrote:
>> On 10/29/2014 08:49 PM, Chet Ramey wrote:
>>>> On 10/27/14, 6:35 PM, Daniel Colascione wrote:
>>>>> This patch adds support for "bracketed paste mode" to readline. In
>>>>> this mode, readline instructs the terminal to wrap pasted strings in
>>>>> special control sequences so that programs can distinguish them from
>>>>> typed input.
>>>>
>>>> Thanks for the contribution.  I'll look at the code; the approach seems
>>>> sound.
>>>
>>> It went in very easily, though I changed some things around.  This
>>> will be in the next release of bash and readline.
> 
>> The code appeared in the snapshot, so I was able to look at how you
>> "changed some things around". You removed the code that tries to
>> determine whether a terminal actually supports the feature; instead, you
>> blindly send the enable sequence to *any* terminal when
>> enable-bracketed-paste is enabled, with potentially unknown consequences
>> on those terminals.
> 
>> There's a comment in the code that indicates you expect users to enable
>> the feature only on terminals where it's supported. I don't think it's
>> reasonable to expect people to maintain a terminal database in their
>> inputrc files.
> 
> People rarely use more than one, maybe two, different terminals or
> terminal emulators.  I don't doubt that people who enable this feature
> know enough to figure out whether or not it's going to work.

You're assuming users are experts.  In reality, users are going to just
paste "set enable-bracketed-paste on" into their inputrc files; they'll
then see an inscrutable control sequence appear in places they didn't
expect and have no idea what's wrong with their system.

Please optimize for what real users actually do, not what perfectly
intelligent users with perfect understanding of their systems would
ideally do.

I'm already going to have to contact every readline and bash distributor
on earth and ask them to enable this feature by default. I don't want to
have to ask them to apply a code patch too.

>> Please restore the part of my patch,
>> rl_bracketed_paste_probably_supported, that detects terminal support for
>> this feature.
> 
> It doesn't `detect terminal support' as such.  It uses a heuristic to
> guess whether or not a terminal supports bracketed paste by checking for
> the presence of  a string in another termcap sequence.  Those kinds of
> heuristics always end up having an exception.

I don't think they will in this case, and at least it's a *conservative*
heuristic. All terminals I've tested (urxvt, xterm, linux, and vte)
either fail the heuristic, pass the heuristic and ignore the control
sequence (which is harmless), or pass the heuristic and enable bracketed
paste mode.

Terminal emulation at this point is very mature. I don't expect
significant development of new terminal types and new kinds of terminal
emulators. The heuristic should work well for a long time.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]