Re: pasting in bracketed-paste mode breaks reverse-i-search

[Chet Ramey]

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/