configurable bindings for X clipboard

[Frederick Eaton]

Dear Bug GNU Readline,

Thank you for your responses. Yes, it is true that allowing Readline bindings to be extended would be 
more useful for copying rather than pasting text, now that bracketed-paste-mode has been implemented. 
To copy text from Readline programs, I currently use a Perl extension to Urxvt which adapts 
"url-select" to instead recognize text at prompts ("> ..."). But this seems 
silly, I would rather just be able to talk to Readline directly via ~/.inputrc; also, the terminal 
output decoding method is somewhat unreliable due to line wrapping and so on.

I think I proposed a design outline for extensible bindings here some years ago, but Chet 
was not ultimately interested. Obviously it requires putting a bit of Unix IPC into 
Readline, so that a named script can be executed, for example one which echoes an 
environment variable into "xsel -bi".

Maybe some people will complain that this would allow old-school hackers to put malicious 
code into my ~/.inputrc, supposing that I accidentally give it the wrong permissions; or 
perhaps running "strace" on 'gdb' becomes more difficult. Maybe Richard 
Stallman would prefer Readline to be extended with a new LISP variant. I'd rather just be 
using my mouse and fingers less.

By the way, I think there are some Emacs configuration variables which make it 
so the X clipboard is synchronized with the Emacs cut buffer. I found this to 
be a terrible idea, as the cut buffer is often populated in the course of 
editing even small bits of text, wiping out the clipboard before I have a 
chance to paste it. So I use and advocate separate bindings for clipboard 
synchronization - I use C-x C-w to copy to the X clipboard, and C-x C-y to 
paste from it, in both Zsh and Emacs. This is somewhat distinct from the 
greater issue of Readline configurability.

Of course there are other ways to think of making Readline more configurable, for example I would 
like certain Zsh commands ("copy-earlier-word"? 
"history-incremental-pattern-search-backward"?), but I can't see an easy way to do these 
with the interface I proposed; they would probably be better in C anyway.

I hope this clarifies the point I was making on Thursday.

Thanks again,

Frederick

P.S. I also have a global binding in X, via xbindkeys, which opens the 
clipboard contents in a new Emacs terminal window, so that I can edit it. I 
only got around to setting up this binding about a year ago, but find it very 
useful for editing URLs, or things I want to paste into a web form. The window 
opens with negligible delay, as both Emacs and Urxvt have client-server 
interfaces. Now that I have this tool, it seems strange to me, and possibly 
risky, that in my previous workflow, in order to be able to inspect the 
contents of the clipboard, I would have had to paste it somewhere.


On Fri, Feb 25, 2022 at 07:16:30AM -0600, Karl O. Pinc wrote:
> On Thu, 24 Feb 2022 23:12:46 -0800
> Frederick Eaton <frederik@ofb.net> wrote:
>
> > I appreciate your thoughtful attention to this matter. But your
> > message is very long
>
> Unfortunately I'd just got done watching "Bridgerton", which
> fixed my mind in 18th century loquaciousness.  The TV
> made me do it!  ;-)
>
> > and I'm not sure if I understand the importance
> > you attach to the two threats.
>
> My opinion is that it's "important" to address unintended
> readline command execution, and pretty silly (and complicated)
> to provide an extra "Do you really mean to paste?" step.  But the
> maintainers have the only opinions that matter.
>
> > I think a better observation is that
> > before backeted-paste-mode had been implemented, Chet should have
> > provided some way to bind a readline key to a shell binding in
> > ~/.inputrc.
>
> Since readline is used in many more places than shells that
> does not seem to be a universal solution.
>
> <snip>
> > If I could paste from the X
> > clipboard (or some other shared clipboard) within Readline, then I
> > think I would have no need for bracketed-paste-mode.
> <snip>
>
> That sounds universal.  But I can't imagine how to implement it.
> Which is not to say it couldn't be done.
>
> Thanks for your reply.
>
> Regards,
>
> Karl <kop@karlpinc.com>
> Free Software:  "You don't pay back, you pay forward."
>                 -- Robert A. Heinlein

On Fri, Feb 25, 2022 at 11:55:20AM -0500, Chet Ramey wrote:
> On 2/25/22 2:12 AM, Frederick Eaton wrote:
> > Dear Karl,
> >
> > I think a better observation is that
> > before backeted-paste-mode had been implemented, Chet should have
> > provided some way to bind a readline key to a shell binding in
> > ~/.inputrc. This is possible in Zsh, and I use it to create bindings
> > to copy/paste to/from the X clipboard there.
>
> This is application-specific functionality, and bash already provides a way
> to bind a readline key sequence to a shell command (bind -x). It's possible
> in the same way in zsh, because the zsh line editor is tightly integrated
> with the shell.
>
> This doesn't change anything about whether or how bracketed paste mode is
> implemented or used. If you have a command that takes text and copies it
> to the X clipboard, or returns the text in the X clipboard, you can use it
> from a shell function and bind a key sequence to it. You have access to
> the current readline line buffer and point, so you can do pretty much
> whatever you want.
>
> I suppose what you're looking for is some readline equivalent to bind -x:
> run an arbitrary shell command, read the output, and insert it into the
> current line. But is that useful to provide within readline when it's so
> easy to accomplish in other ways?
>
> > If I could paste from the X
> > clipboard (or some other shared clipboard) within Readline, then I
> > think I would have no need for bracketed-paste-mode.
>
> I don't see why you think there's a useful distinction here. The purpose of
> bracketed-paste mode is to paste from the X (or whatever) clipboard. It's
> what you do with the pasted text that differs.
>
> --
> ``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/

On Fri, Feb 25, 2022 at 06:42:44AM -0800, Per Bothner wrote:
> On 2/24/22 23:12, Frederick Eaton wrote:
> > But all the other interactive programs I use are based
> > on Readline, and so I can't use the X clipboard with them, like I do
> > with my custom bindings in Zsh and Emacs. If I could paste from the X
> > clipboard (or some other shared clipboard) within Readline, then I
> > think I would have no need for bracketed-paste-mode.
>
> What do you mean you can't paste from the X clipboard? That is what
> bracketed-paste-mode is meant to support.  Most modern terminal emulators
> have a key-binding to paste from the clipboard. On Unix-like systems
> it is usually Ctrl-Shift-V and/or Shift-Insert.
>
> What are harder problem is
> (a) the reverse problem: copying to clipboard; and
> (b) co-oordinating with the X selection.
>
> A related problem is that one should be able move the readline cursor
> by clicking with the mouse.  (The DomTerm terminal implements this by sending
> left-arrow/right-arrow commands as needed, when emabled by certain escape 
> sequences.)t
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/

On Fri, Feb 25, 2022 at 12:03:05PM -0500, Chet Ramey wrote:
> On 2/25/22 9:42 AM, Per Bothner wrote:
>
> > What are harder problem is
> > (a) the reverse problem: copying to clipboard; and
>
> This is fairly easy to accomplish if you have a command that copies text
> supplied as an argument to the clipboard (like macOS's `pbcopy'). You can
> run it from a shell function bound with `bind -x' and feed it whatever text
> you like.
>
> > (b) co-oordinating with the X selection.
>
> I'm not even sure how you would do this in a portable way, even if it were
> X specific. I suppose if you could read the character positions
> corresponding to the start and end of the selection you could translate
> them into the readline point and mark. You could do that from a shell
> function bound with `bind -x' as well.
>
> > A related problem is that one should be able move the readline cursor
> > by clicking with the mouse.  (The DomTerm terminal implements this by sending
> > left-arrow/right-arrow commands as needed, when emabled by certain 
> > escape sequences.)
>
> This is appropriate functionality for a terminal emulator to provide, since
> readline is window-system agnostic and doesn't have a way to read mouse
> events.
>
> --
> ``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/