Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add <c-s> prompt command to turn in select mode #1818

Open
alexherbo2 opened this issue Jan 27, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@alexherbo2
Copy link
Contributor

commented Jan 27, 2018

Select mode

  • Completion candidate’s selected
  • Argument being completed doesn’t expand until being validated

Commands

  • Return: Validate completion and execute command
  • Alt Return: Validate completion

Use case

Behave like a regular fuzzy finder.

Examples

map global normal <ret> :buffer<space><c-s>
map global normal <a-ret> :find<space><c-s>
@alexherbo2

This comment has been minimized.

Copy link
Contributor Author

commented Jan 27, 2018

Could be useful with #1508.

@lenormf

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2018

How robust would a bind on <c-s> be, knowing that it's a shortcut that locks the terminal by default?

@Screwtapello

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2018

<c-s> only freezes the terminal when the terminal is in "cooked" mode and the kernel converts certain control characters into signals (like <c-c> for SIGINT and <c-z> for SIGTSTP, etc.)

Kakoune puts the terminal into "raw" mode at startup so it can handle those key-sequences itself. Binding <c-s> would be no more difficult than binding any other control-character. In fact, Kakoune already has a binding for <c-s> ("save current selections"), but I expect it only works in normal mode, so the keybinding would still be available on the command-line.

@lenormf

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2018

Why do urxvt users have issues with bindings like <a-s>, handled by the terminal itself as well, then?

@Screwtapello

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2018

It looks like urxvt handles <a-s> itself, so I guess there's nothing an application running inside the terminal can do to avoid it.

On the other hand, the <c-s>/<c-q> flow-control behaviour is provided by the kernel, and the kernel allows applications to switch to "raw mode" to disable it.

I've just realised I'm confusing different definitions of "terminal" here. To clarify:

  • "a terminal emulator" (like xterm or urxvt) is responsible for taking GUI keyboard events and encoding them according to ECMA-48, then sending them to the kernel to pass to the application running "inside". Apparently urxvt takes some key-sequences that ECMA-48 supports and interprets them itself instead of passing them to the kernel; nothing much we can do.
  • "a terminal device node" (like /dev/pts/5) is the kernel object between the terminal emulator process and the application process, and for historical reasons it's very closely tied to the model of RS-232 serial ports. That's the bit that converts control characters to signals, and the bit that the application can reconfigure at will (see stty(1)).
@alexherbo2

This comment has been minimized.

Copy link
Contributor Author

commented Mar 11, 2019

I’ve suggested Control + s, but it could be another key.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.