Re: [Bug-readline] key bindings proposal

[frederik]

Hi Chet,

> I don't know as much about R as I know about the shell, but I would think
> that R could implement something -- it's a language of sorts, right? --
> that would expose rl_point and rl_line_buffer to the user and then capture
> changes to those variables.  Those changes could be fed back to readline
> in the same way that bash feeds back modifications to READLINE_LINE and
> READLINE_POINT.  If you wanted to implement this small inter-process
> protocol you described, you could do it there and see how it works out.
> Maybe that mechanism  could be an option if this makes it into readline
> itself.

This isn't a solution that I would be interested in helping out with.
In my original proposal, perhaps I didn't make it very clear but my
intent was to suggest something that a user could put in ~/.inputrc
which would work for all Readline instances, not just Readline usage
by a particular program such as R or Units.

The natural way to do this would be to bind keystrokes to external
shell commands, but if you have a problem with Readline executing
external commands then I guess we are at an impasse.

You can look at the StackOverflow thread I referenced, there is some
demand to do things like this, such as (in the thread) integrating
Readline's kill ring with the X clipboard. I don't think that people
are interested in having separate keybindings or macros for every
Readline client which they want to integrate with X.

Cheers,

Frederick

On Sun, Jun 05, 2016 at 10:35:13PM -0400, Chet Ramey wrote:
> On 6/3/16 2:49 AM, address@hidden wrote:
> 
> > 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.
> 
> You should read the code for the full picture, but the summary is that
> bash uses an alternate keymap, which maps key sequences to command
> strings.  Since they're just strings, and this is a keymap that's only
> used for these command strings, bash can use existing readline primitives
> that deal with binding keys sequences to strings: macros.  Bash uses a
> function it adds to readline's set of bindable functions: it binds that
> same key sequence to that C function (bash_execute_unix_command).  That
> function gets called by readline in the usual way: when a user enters a
> key sequence that is bound to it.  When that function is executed, it
> uses the key sequence the user entered, which readline provides it, looks
> up the macro (command string) bound to that key sequence in the special
> keymap, and executes that string as a shell command.
> 
> You should look at bashline.c:bash_execute_unix_command for the details.
> 
> >> 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? 
> 
> Sure, of course it can.  Bash has builtins and shell functions.  If you
> want to affect readline's behavior by modifying READLINE_LINE and
> READLINE_POINT, you have to do it in the same process (execution context)
> as the shell using readline.  To do that, you would most likely use a
> shell function.
> 
> 
> > 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.
> 
> So you'd basically have to do the same thing that bash does, but either
> write your own code in the language you're using (maybe R) or write
> special commands you could use with this that will implement this protocol
> you're describing.  That seems to artificially limit the functionality,
> doesn't it?  The bash approach allows the command to display arbitrary
> output, and I know that some users are using it.
> 
> I don't know as much about R as I know about the shell, but I would think
> that R could implement something -- it's a language of sorts, right? --
> that would expose rl_point and rl_line_buffer to the user and then capture
> changes to those variables.  Those changes could be fed back to readline
> in the same way that bash feeds back modifications to READLINE_LINE and
> READLINE_POINT.  If you wanted to implement this small inter-process
> protocol you described, you could do it there and see how it works out.
> Maybe that mechanism  could be an option if this makes it into readline
> itself.
> 
> The key seems to be figuring a reasonable way to optionally modify the
> line and point without requiring changes to commands or limiting what the
> commands can do.  Maybe there's no way to do that within readline itself.
> 
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/
>