[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