Re: bracketed paste - chopping trailing newlines

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sep 14,  8:35pm, Daniel Shahaf wrote:
}
} As to interaction with the region: in my workflow, I sometimes do
} <set-mark-command>, <typing>, <quote-region>.  During that sequence,
} even I happen to do a paste during the <typing> part, I wouldn't want
} MARK to move to the start of the paste.  I don't know <paste> should
} default to moving MARK.

Hm.  This is down to whether pasting is an actual editor action, or
just another form of user input.  For example MARK and CURSOR are
reset by the yank widget in exactly the circumstance you describe,
and bracketed-paste is currently implemented mostly 'as if' the pasted
text were cut into the kill ring and then yanked.

Also, just as an aside, if the region is highlighted ("active") but a
paste does NOT change the region, then how do you decide what ends up
highlighted after the paste?  And if the answer is "both", then how
can the default paste highlight be the same as the default region
highlight without being really confusing?

We still seem to have three competing desires here, depending on who
you ask:

(1) Insert exactly what I pasted, as if it were a single keystroke,
    without further interpretation or change to the editor state.

(2) Handle paste as an atomic editor command similar to yanking from
    an external buffer instead of from the kill ring (as currently).

(3) Treat a paste like multiple keystrokes, so that url-quote-magic
    and other input-related rebindings apply, but don't execute any
    non-input bindings (accept-line, motions, yanks, kills, etc.)

Obviously there can be some overlap, i.e., you might want it treated
as multiple keystrokes but still without change to the editor state.

Maybe we should have stuck with (1) in the C code and built out (2)
in script code the way bracketed-paste-magic builds out (3).  Or
maybe e.g. $zle_bracketed_paste should have more fields to specify
which bits of (2) should be performed.