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.
signature.asc
Description: OpenPGP digital signature
