how to bind the "Ctrl-l" to empty the screen instead of clearing the terminal buffer?

[c02y]

I use fish with tmux, fish provides a default binding for "C-l":

bind \cl 'clear; commandline -f repaint'

but it will clear the terminal buffer (leaving only one whole screen of content if I scroll it) and I won't be able to scroll the terminal to view the content or the result of the history commands.

I can make it work by defining a key binding in tmux configuration file, but it seems there is a bug with it because of the conflict of two bindings in fish and tmux. And I have to call a function defined in ~/.config/fish/functions when hitting Ctrl-l (clear and then call the function), so it is better to make a binding in config.fish to replace the default one.

So how can I do that?

[krader1961]

The way to create your own key bindings, including overriding a default binding, is to create a function named fish_user_key_bindings and put your own bindings in that function. For example, you might put something like the following in your config.fish:

if status --is-interactive
    source $HOME/.config/fish/interactive.fish
    function fish_user_key_bindings
       bind \n backward-delete-char
       bind -M insert \n backward-delete-char
       bind -m insert \n backward-delete-char
    end
end

[c02y]

I know how to bind a key in fish,

Please read the description.

On March 25, 2016 01:58:27 Kurtis Rader notifications@github.com wrote:

The way to create your own key bindings, including overriding a default
binding, is to create a function named fish_user_key_bindings and put
your own bindings in that function. For example, you might put something
like the following in your config.fish:

if status --is-interactive
    source $HOME/.config/fish/interactive.fish
    function fish_user_key_bindings
       bind \n backward-delete-char
       bind -M insert \n backward-delete-char
       bind -m insert \n backward-delete-char
    end
end

---

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#2855 (comment)

[krader1961]

Please read the description.

I did and couldn't make sense of what you're asking. But you ended with

so it is better to make a binding in config.fish to replace the default one. So how I do that?

So I took a guess that you needed a pointer on how to create a binding to replace the default one for [ctrl-L].

[faho]

Of note here is that clear is an external command that as far as I can tell just does the same thing as echo \e\[H\e\2J - an escape sequence that the terminal recognizes and then proceeds to do its thing.

So the question here is if the mechanism is just deficient for you in tmux (which acts as a terminal), or in your actual terminal (to which tmux talks).

What happens for me (and presumably @krader1961, which is why he does not understand what you're asking), is that the terminal adds a full screen's worth of whitespace, pushing the old content out. I can still scroll back, though. This is with KDE's konsole (version 15.12) and no multiplexer (screen or tmux).

[faho]

Works about the same in tmux for me, except that tmux will buffer the output instead of the actual terminal, so I'd need to use the tmux bindings to scroll up or down ("Ctrl-b [", then arrow keys to move around, then "q" to stop scrolling).

[c02y]

I'd need to use the tmux bindings to scroll up or down ("Ctrl-b [", then arrow keys to move around, then "q" to stop scrolling

This is what I do.

The Weird thing is I got three computers, the same configuration works just as what I want in two of them:
Work:

1. Ubuntu 14.04. LTS 32-bit, fish-shell v2.2.0, tmux v2.2, yakuake v2.9.9 based on konsole v2.13.2
2. Centos 6.5 32-bit, fish-shell v2.2.0, tmux v2.2, yakuake v2.9.8 based on konsole v.2.3.3

Not work:
Fedora 23 63-bit

I currently got no access to the Fedora computer, I'll provide more info about the as soon as I can.

[krader1961]

I see the same behavior that @faho mentioned. Although when he says "the terminal adds a full screen's worth of whitespace, pushing the old content out" that isn't an entirely accurate description of what occurs. Still, what we're all seeing is the expected behavior. So I still do not understand what the problem is let alone what behavior you would prefer.

Is it simply that you don't want the current screen to be cleared, thus losing the ability to see that content by scrolling back in the tmux or terminal buffer? If so, then simply replace the clear command in the \cL binding with a command that actually writes enough spaces to fill the screen. Thereby actually "pushing the old content out" as @faho described. Unfortunately, doing so efficiently (i.e., with the minimum number of space characters) requires parsing the output of the stty -a command to get the rows and columns values. Then compute their product and write that many spaces.

[c02y]

simply replace the clear command in the \cL binding with a command that actually writes enough spaces to fill the screen.

do I have to do this, is there any existed smarter command or function to replace clear?

[krader1961]

is there any existed smarter command or function to replace clear?

Not that I am aware of but try this:

function slow_clear --description 'Clear screen by writing lots of spaces'
    set -l size (string match -r '(\d+) (\d+)' (stty size))
    set -l chars (math "$size[2] * $size[3]")
    for x in (seq $chars)
        echo -n ' '
    end
    echo ''
end

That assumes your system supports stty size writing the rows and columns of the terminal.

[c02y]

the slow_clear is really slow and I can see some movements in the screen, besides, the prompt will be at the bottom of the terminal not the top after executing slow_clear function.

[zanchey]

What about

bind \cl 'for i in (seq 1 $LINES); echo; end; clear; commandline -f repaint'

This pushes enough blank lines into the output buffer that clear overwrites them all.

[peterstory]

Doesn't requiring configuration like this to get expected behavior go against Fish's philosophy of having a great out-of-box experience? Coming from Bash, I think that the expected behavior is not to kill scrollback. So I think Fish should have a similar default behavior, unless there's a good reason not to.

[faho]

@peterstory: The expectation here is that this is a weird terminal/multiplexer bug that can be worked around via binding something different.

It originally didn't seem like anyone but @c02y had this issue, so we couldn't reproduce it and just chalked it up to weirdness elsewhere. Are you saying that you have this issue?

Because I'd certainly consider using a different binding, but we then need to figure out what proper behavior here is. We certainly don't intentionally do anything to "kill scrollback".

If you have this issue, we're going to need to know your terminal and multiplexer (if any) so we can attempt to reproduce.