Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Chet Ramey <chet.ramey@case.edu>
Newsgroups: gnu.bash.bug
Subject: Re: pasting in bracketed-paste mode breaks reverse-i-search
Date: Tue, 21 Apr 2020 17:50:36 -0400
Organization: ITS, Case Western Reserve University
Lines: 84
Approved: bug-bash@gnu.org
Message-ID: <mailman.912.1587505848.3066.bug-bash@gnu.org>
References: <M5PMSNi--3-2@tutanota.com> <62817207-4c7b-491e-2c5a-a57128e04b88@case.edu> <M5SqQR7--3-2@tutanota.com> <e194ddfe-a4f1-933c-5adf-b9126514247e@case.edu>
Reply-To: chet.ramey@case.edu
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Cc: chet.ramey@case.edu, bug-bash@gnu.org
To: gentoo_eshoes@tutanota.com
Envelope-to: bug-bash@gnu.org
Autocrypt: addr=chet.ramey@case.edu; prefer-encrypt=mutual; keydata= mQGiBEEOsGwRBACFa0A1oa71HSZLWxAx0svXzhOZNQZOzqHmSuGOG92jIpQpr8DpvgRh40Yp AwdcXb8QG1J5yGAKeevNE1zCFaA725vGSdHUyypHouV0xoWwukYO6qlyyX+2BZU+okBUqoWQ koWxiYaCSfzB2Ln7pmdys1fJhcgBKf3VjWCjd2XJTwCgoFJOwyBFJdugjfwjSoRSwDOIMf0D /iQKqlWhIO1LGpMrGX0il0/x4zj0NAcSwAk7LaPZbN4UPjn5pqGEHBlf1+xDDQCkAoZ/VqES GZragl4VqJfxBr29Ag0UDvNbUbXoxQsARdero1M8GiAIRc50hj7HXFoERwenbNDJL86GPLAQ OTGOCa4W2o29nFfFjQrsrrYHzVtyA/9oyKvTeEMJ7NA3VJdWcmn7gOu0FxEmSNhSoV1T4vP2 1Wf7f5niCCRKQLNyUy0wEApQi4tSysdz+AbgAc0b/bHYVzIf2uO2lIEZQNNt+3g2bmXgloWm W5fsm/di50Gm1l1Na63d3RZ00SeFQos6WEwLUHEB0yp6KXluXLLIZitEJLQwQ2hldCBSYW1l eSAoQ2FzZSBzdGFuZGFyZCkgPGNoZXQucmFtZXlAY2FzZS5lZHU+iF8EExECAB8FAkPi19EC GwMHCwkIBwMCAQMVAgMDFgIBAh4BAheAAAoJELtYafBk6nSrelkAn31Gsuib7GcCZHbv5L5t VKYR9LklAJ4hzUHKA49Z0QXR+qCb80osIcmPSbkBDQRBDrBvEAQAkK6TAOKBEM+EC4j6V/7o /riVZqcgU5cid2qG9TXdwNtD9a3kvA/ObZBO93sX59wc6Bnwo4VJxsOmMlpGrAjJsxNwg3QH akEtf8LXRbVpj5xStdmBdQZUhIQyalo/2/TZq5OijtddUQcL5cs70hTv/FpT3wUvr2Xr8rjF 41IFEz8AAwcD/A0CZEGlzIrT5WCBnl6xBog/8vKiUCbarByat3d1mL6DbizvKNXQRTC9E/vE dENAWCQCjr75Bu55xT8n3SXGtWdDC5xmZ/P3OBYORP8yl8H8I1FIosWOFirbIeYdZPq8SPD1 HL+EXo9zSiHVrrZRJ19ooCKKbSdXHFCY+aJG+0KZiEkEGBECAAkFAkEOsG8CGwwACgkQu1hp 8GTqdKvjcACfZlkVCDwaz/NTO9cy3t69oWpVPNwAnRwe0qk/WL/gfhH346xh5B3HFbFN
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
In-Reply-To: <M5SqQR7--3-2@tutanota.com>
Content-Language: en-US
Received-SPF: pass client-ip=129.22.103.227; envelope-from=chet.ramey@case.edu; helo=mpv1-2015.case.edu
Precedence: list
Xref: csiph.com gnu.bash.bug:16221

On 4/21/20 4:25 PM, gentoo_eshoes@tutanota.com wrote:

>> It's the ESC prefix. You can use it if you remove ESC from the list of
>> characters that terminate an incremental search. The problem is that most
>> of the key sequences that begin with ESC (e.g., arrow keys) are intended to
>> terminate the isearch and use the ESC as the first character of a key
>> sequence. You have to look farther ahead in the input stream than
>> incremental search presently does to differentiate between an ESC-prefixed
>> key sequence you want to use for searching and one you want to terminate
>> the search and use as a command.
>>
> Did you mean to say that bracketed-mode pastes ESC, perhaps as a way to highlight(ie. that white background) ?
> interesting

Not exactly. Bracketed paste mode is called that because it `brackets' the
pasted text with special escape sequences. That's how you can recognize it
as a paste -- otherwise it just shows up in the input stream as if the text
had been typed.

The escape sequences, like just about everything else with terminals, start
with ESC.

$ grep BRACK_P rlprivate.h
#define BRACK_PASTE_PREF	"\033[200~"
#define BRACK_PASTE_SUFF	"\033[201~"
#define BRACK_PASTE_LAST	'~'
#define BRACK_PASTE_SLEN	6
#define BRACK_PASTE_INIT	"\033[?2004h"
#define BRACK_PASTE_FINI	"\033[?2004l\r"

The last two are what you send when you want to start and stop using
bracketed paste mode, respectively.

The bracketed paste prefix and suffix serve only to delimit the text.
They allow readline to recognize that a paste took place and mark the
boundaries of the pasted text so the redisplay can highlight them
later.

> 
>   static char * const default_isearch_terminators = "\033\012";                                                  
> ESC and newline(ie. \n) hmm...
> 
> oh hey, I found out how I know that Ctrl+R is the key that invokes reverse-i-search:
> $ bind -q reverse-search-history
> reverse-search-history can be invoked via "\C-r".
> 
> ok, so to translate what you said... the default is this:
> $ bind "set isearch-terminators '\033\012'"
> even though `bind -v | grep isearch-terminators` shows nothing before I run that command because it's not set.

You haven't set it, so it gets the default.

> 
> So if I run this:
> $ bind "set isearch-terminators '\012'"
> then the issue is gone and reverse-i-search works, with the caveat that it breaks when you try to rpess left/right arrows by it typing in "[D" respectively "[C" , but it doesn't happen the first time right after paste, only if I just do Ctrl+R type some string, press arrow...
> I see that left/right arrow keys yield ESC[D and ESC[C respectively. So it eats the ESC, it still terminates the i-search, then continues to type what's left: "[D" or "[C". Confused as to why. I thought ESC shouldn't terminate i-search 

It doesn't really. What happens is that it reads enough characters to
resolve to a bound key sequence, finds the function (backward-char), and
assumes that it should break the search and execute that function (this is
standard incremental search behavior). The problem is that it doesn't save
enough of the key sequence to do that -- it just pushes the current and
previous characters back onto the input. I should do something about that
sometime, but it really hasn't been a problem until now.

> I'm still not sure where the ESC that breaks it comes from, is it from the highlight?

See above.

> like something similar to $ echo -e '\033[47mPASTED' to get white-ish background?

Similar.

> I'm confused whether or not this is fixable by bash, or should I have to use that \012 terminator workaround? Please advise :) Thx.

I'll have to add something to change this.


-- 
``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/