Re: Get Terminal to Echo line in buffer on backspace
On Mon 30 Aug 2021 at 11:39:14 (-0400), Greg Wooledge wrote:
> On Mon, Aug 30, 2021 at 05:05:49PM +0200, Nicolas George wrote:
> > With Zsh, there is the "redisplay" zle command, it does exactly that:
> > redraw the prompt and command without clearing the screen.
> >
> > I do not know if readline, used by bash, has the same feature available.
>
> Interesting. I've never looked into this stuff before.
>
> There is a "redraw-current-line" action in readline, but bash doesn't
> bind any keys to it by default, neither in emacs nor vi mode.
>
> But before I could even test that, I came across this section in the
> man page:
>
> clear-screen (C-l)
> Clear the screen, then redraw the current line, leaving the cur‐
> rent line at the top of the screen. With an argument, refresh
> the current line without clearing the screen.
>
> That bit about "With an argument" is totally new information for me.
> I'm a vi mode user, so I tried it as indicated: I typed some random
> stuff, and then I pressed ESC 0 Ctrl-L. It didn't work (it cleared the
> whole screen). So maybe an argument of 0 doesn't count... oh, right.
> That's because 0 is a movement command ("jump to first column"). Next I
> tried with a non-zero argument: ESC 1 Ctrl-L. That worked. It redrew
> the current prompt and command line, without clearing the screen.
>
> I also tested in emacs mode, but I'm not as proficient there. Again,
> ESC 1 Ctrl-L seems to work. And so does Alt-1 Ctrl-L, in my terminal
> (but Alt-1 may not work in all terminals, so be warned).
>
> For extra fun: Alt-0 Ctrl-L also works in emacs mode. Apparently emacs
> can handle an argument of 0, because 0 isn't a movement command in
> emacs the way it is in vi.
>
> So, there's that. And that will do what the OP wants, albeit not
> "automatically" the way they seemed to want. They actually have to
> press the keys.
>
> I'll let others play around with binding redraw-current-line to some
> unused key combo. I'm betting it does the same thing, once bound.
Bound or unbound, I couldn't make ESC 1 Ctrl-L do anything useful
while output is in progress (like a clean display of the typeahead
so far typed). I couldn't see a way to force echoing the line at
that time.
I bound ESC 1 Ctrl-L to Alt-SPACE in ~/.inputrc¹ and the main
effect (during output) was that Alt-SPACE reflected a Space
(whereas ESC 1 Ctrl-L reflected the expected ^[1^L.)
The only useful effect of that binding that I've seen is not when
typing ahead, but at the normal command line: the Alt-SPACE would
redraw the prompt and commandline without ceremony, whereas typing
the characters ESC 1 Ctrl-L produces a dialogue as it does its work,
printing (arg: 1) at the beginning of the line, then overwriting it.
Typing ahead into (normally infinite) output, like ping, is of
limited use anyway, because AIUI stopping the output with ^C
throws away the typeahead buffer anyway.
Six decades or so ago, when teletypes ran at lamentable speeds,
typeahead was fairly essential for power users. I remember that
the Phoenix/MVS system at Cambridge had a facility where typing
a space would suspend printing output at the end of a line
(like a perfectly timed XOFF), whereupon you could type a command
line undisturbed for up to 60 secs, until you either sent it or
aborted it (which would resume printing output).
But as songbird suggested, when you have multiple channels of
communication, facilities such as these become unnecessary.
¹ Normally, I have Alt-SPACE bound to " ", so that accidentally
catching the Alt key when typing Space is ignored.
Cheers,
David.
Reply to: