elves / elvish

Powerful scripting language & versatile interactive shell

Home Page:https://elv.sh/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Mapping `$edit:close-mode~` has no effect

il-k opened this issue · comments

commented

As I understand, looking at readline-binding.elv, $edit:close-mode~ should close all non-insert modes back to insert-mode. (and $edit:completion:close~ has been removed, right?)

I am trying to remap C-q to do the same thing. I try

set edit:global-binding[C-q] = $edit:close-mode~
set edit:global-binding[Ctrl-Q] = $edit:close-mode~
set edit:completion:binding[C-q] = $edit:close-mode~
set edit:listing:binding[C-q] = $edit:close-mode~

and others, but none of them have any effect: while C-g continues to close modes, C-q does nothing.

Am I doing something wrong?

Ctrl-Q is most likely reserved for flow control by the terminal driver, so you can't bind it to anything. Try another key like Ctrl-X.

I'll close this because it's a terminal issue - in the meantime I've added some notes to https://elv.sh/ref/edit.html#format-of-keys that some keys may not be available due to limitations of the terminal.

I've also removed the doc for edit:completion:close.

commented

thank you! for your prompt responses and actions :))
you were right, C-x works correctly. didn't even occur to me to check another key haha

commented

But it's weird that C-q are received properly by other applications! Is it possible that elvish does not disable its IXON flag of its termios when it establishes a connection with the terminal?

But it's weird that C-q are received properly by other applications! Is it possible that elvish does not disable its IXON flag of its termios when it establishes a connection with the terminal?

Yes - these are all the termios manipulation Elvish does:

savedTermios := term.Copy()
term.SetICanon(false)
term.SetIExten(false)
term.SetEcho(false)
term.SetVMin(1)
term.SetVTime(0)
// Enforcing crnl translation on readline. Assuming user won't set
// inlcr or -onlcr, otherwise we have to hardcode all of them here.
term.SetICRNL(true)
err = term.ApplyToFd(fd)

I haven't really dug deep enough into termios stuff to know whether it's safe for Elvish to always disable IXON. I guess you can always call stty -ixon yourself - are there precedents from other shells or terminal programs to disable IXON?

commented

But it's weird that C-q are received properly by other applications! Is it possible that elvish does not disable its IXON flag of its termios when it establishes a connection with the terminal?

Yes - these are all the termios manipulation Elvish does:

savedTermios := term.Copy()
term.SetICanon(false)
term.SetIExten(false)
term.SetEcho(false)
term.SetVMin(1)
term.SetVTime(0)
// Enforcing crnl translation on readline. Assuming user won't set
// inlcr or -onlcr, otherwise we have to hardcode all of them here.
term.SetICRNL(true)
err = term.ApplyToFd(fd)

I haven't really dug deep enough into termios stuff to know whether it's safe for Elvish to always disable IXON. I guess you can always call stty -ixon yourself - are there precedents from other shells or terminal programs to disable IXON?

yes.
fish disables IXON and IXOFF by default, but provides a way to enable it.
zsh enables IXON by default, but provides an option (see FLOW_CONTROL) to disable it.

Fish is valued for its better defaults over zsh. I think keymaps should take precedence over old features – most people won't know it's there, but those who do should know exactly what they're missing. I don't think this specialised piece of knowledge should be required by default.

yes. fish disables IXON and IXOFF by default, but provides a way to enable it. zsh enables IXON by default, but provides an option (see FLOW_CONTROL) to disable it.

Fish is valued for its better defaults over zsh. I think keymaps should take precedence over old features – most people won't know it's there, but those who do should know exactly what they're missing. I don't think this specialised piece of knowledge should be required by default.

Nice, I filed #1803.

The user would still need to know quirks like Ctrl-I being identical to Tab, but at least we get two keys back.

commented

The user would still need to know quirks like Ctrl-I being identical to Tab

Yess, but they won't need to learn about the historical curiosities of flow control! And when Kitty keyboard protocol is implemented, even Ctrl-I will go away.

The user would still need to know quirks like Ctrl-I being identical to Tab

Yess, but they won't need to learn about the historical curiosities of flow control! And when Kitty keyboard protocol is implemented, even Ctrl-I will go away.

If they use a terminal that supports the kitty protocol... which none of the more mainstream ones support yet :-/

In any case it's a small incremental improvement, but Elvish is just a small piece of the puzzle.