Re: [Bug-readline] key bindings proposal

[Chet Ramey]

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/