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, [email protected] 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 _______________________________________________ Bug-readline mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-readline
