bug-readline
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-readline] key bindings proposal


From: frederik
Subject: Re: [Bug-readline] key bindings proposal
Date: Thu, 2 Jun 2016 23:49:10 -0700
User-agent: Mutt/1.6.1 (2016-04-27)

Hi Chet,

Thanks for getting back.

On Thu, Jun 02, 2016 at 02:23:10PM -0400, Chet Ramey wrote:
> On 5/20/16 2:25 PM, address@hidden wrote:
> 
> > What I envisioned was a facility to execute external commands, not
> > alternate-keymap macros. This would be needed in order to get a
> > solution which applies to all readline applications, not just Bash. I
> > was thinking that in addition to normal ~/.inputrc bindings like
> > 
> > "\e[1;5C": forward-word
> > 
> > and macros like
> > 
> > "\ex": 'cd !$ \015ls\015'
> > 
> > Readline could also support some syntax like
> > 
> > "\C-x\C-w": `x-clip-kill-region`
> 
> I understand your proposal, and agree that your proposed syntax is probably
> the most straightforward.
> 
> However, this requires fairly extensive changes to readline.  The bash
> approach, while bash-specific, uses existing readline features and yet
> has already uncovered some holes in readline's support for things like
> this.  This is why I wrote that I wouldn't mind seeing another
> implementation outside readline proper that would uncover any remaining
> holes in readline's support.

How do you envision the "bash approach" being used in other programs?
For instance, take the example I gave of interacting with 'xclip'. How
would this be done in R or Units? As I understand it, the "bash
approach" involves binding keys to macros, which consist of strings
that are meaningful to bash... I should have asked about this earlier,
because I was confused when you first made the suggestion.

> > It could update the value of these variables by outputting e.g.
> > "READLINE_POINT=...\0READLINE_LINE=...\0" on STDOUT (or whatever is
> > easiest to parse).
> 
> This is probably a non-starter.  To parse this optional output, readline
> would have to run the command with its standard output, at least,
> connected to a pipe to readline and handle displaying all the command's
> output.  Many commands change their behavior based on whether they're
> writing to a pipe.
> 
> Bash is able to do this because it can execute commands without creating
> a child process.

Bash can execute commands without creating a child process? Can you
elaborate on this? I'm not very much of a Unix expert, so I may be
missing some distinction between "process" and "child process", but I
think that the purpose of my proposal was to allow users to bind keys
to commands which would execute as processes, with pipes, input and
output, and so on.

> and handle displaying all the command's output

I wasn't suggesting that any output would have to be displayed to the
user, basically anything to be passed back to Readline would be passed
in the format I proposed. Perhaps STDERR would be shared by default,
but without requiring any work from Readline.

Thanks,

Frederick



reply via email to

[Prev in Thread] Current Thread [Next in Thread]