Mapping $edit:close-mode~ has no effect

[il-k]

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?

[xiaq]

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.

[xiaq]

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.

[xiaq]

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

[il-k]

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

[il-k]

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?

[xiaq]

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:

elvish/pkg/cli/term/setup_unix.go

Lines 24 to 36 in a03125e

	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?

[il-k]

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:

elvish/pkg/cli/term/setup_unix.go

Lines 24 to 36 in a03125e

	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.

[xiaq]

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.

[il-k]

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.

[xiaq]

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.