[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-readline] Executing any bound shell command redraws the prompt
Re: [Bug-readline] Executing any bound shell command redraws the prompt which seems unnecessary
Fri, 11 Oct 2019 10:50:11 -0400
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
On 10/6/19 2:05 PM, Šimon Let wrote:
> Thank you for your reply.
> If I understand correctly, the issue is that the output of the command can
> modify the terminal contents.
Yes. Readline can't know what the command is going to do.
> So theoretically, if there was a way to only allow the command to interact
> with the terminal contents by modifying $READLINE_LINE and/or
> $READLINE_POINT, Readline wouldn't have to redraw the prompt?
> Would it be desirable to add a feature like this to Readline?
It would have to be some option to bind that guaranteed to readline that
the command wouldn't produce any output or modify the contents of the
current input line without using readline commands (which, if you were
going to do that, why use `bind -x'?)
The first thing bash does when it executes a command string from `bind -x'
is to put the cursor in column 0 on a new line. This ensures that the
command won't overwrite any of the command line and the command line won't
obscure any command output. To avoid this, bash would have to know a priori
that the command doesn't produce output. There's no place to store this in
the current readline keymap structure, so you'd have to use some additional
data structure, and that seems overkill just to avoid some screen flicker.
> Maybe an option for `bind -x` that makes Readline throw away any output
> produced by the command?
How is readline going to do that? It doesn't know where the cursor is
located or the screen contents.
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU address@hidden http://tiswww.cwru.edu/~chet/