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

Review and adopt http://www.leonerd.org.uk/hacks/fixterms/ #63

Open
wez opened this issue Nov 6, 2019 · 7 comments
Open

Review and adopt http://www.leonerd.org.uk/hacks/fixterms/ #63

wez opened this issue Nov 6, 2019 · 7 comments
Labels
enhancement New feature or request keyboard Keyboard mapping/handling

Comments

@wez
Copy link
Owner

wez commented Nov 6, 2019

This page has a plan for fixing input in terminals:
http://www.leonerd.org.uk/hacks/fixterms/

@wez wez added the enhancement New feature or request label Nov 6, 2019
wez added a commit that referenced this issue Nov 16, 2019
wez added a commit that referenced this issue Nov 16, 2019
wez added a commit that referenced this issue Nov 23, 2019
I keep holding shift while pressing space and seeing stuff get
undone in vim.  Super annoying.  I didn't see a good way to
teach applications about this via terminfo, so this is off
by default for now.

refs: #63
wez added a commit that referenced this issue Dec 30, 2019
Previously we would try to pass through the Backspace and Delete
code points without interference, but that behavior wasn't quite
right.

With this commit our behavior is now:

- At the window layer: Classify a `Backspace` key press as logically
  `BS` and a `Delete` key press as logically `DEL` unless the
  `swap_backspace_and_delete` is true (macOS is true by default), in
  which case `Backspace` is mapped to `Delete` and vice versa.

- At the terminal input layer: A `Backspace` input from the Window sends
  the `DEL` sequence to the pty as that matches the default `VERASE` stty
  configuration.  A `Delete` input from the Window emits `\033[3~`,
  which matches up to the `TERMINFO` for `xterm-256color` which we
  claim to be compatible with, and is our default `$TERM` value.

The net result of this is that `Backspace` will now start to emit `^?`
which should match folks stty verase.   Heads up to @fanzeyi!

I've tested this only on a linux system so far and will follow up on
a macOS system a little later today.

Refs: #88
Refs: #63
wez added a commit that referenced this issue Jan 24, 2020
This isn't a 100% righteous fix, but is sufficient to reduce
the irritation in refs: #126

The full fix is pending another round of review of the CSI-u stuff
in refs: #63
wez added a commit that referenced this issue Jun 11, 2020
This was originally intended to be swept in and dealt with as part of
adopting CSI-u (refs: #63) but the
default shift-space mapping is super irritating in vim (refs:
#126) so it got partially walked
back, but as a consequence we accidentally dropped the modifiers from
those keys (refs: #213 refs:
#214).

This commit restores the modifiers for that case.

In addition, since we now have a way to plumb configuration directly
into the term crate, this adds a config option to enable CSI-u for those
that want to use it.
@bew
Copy link
Sponsor Contributor

bew commented Jun 11, 2020

Hello, with the latest commits, what is missing to be complete?

@wez
Copy link
Owner Author

wez commented Jun 11, 2020

I think this is probably done, but would appreciate feedback from someone that would notice the difference!

I believe that neovim will natively recognize CSI-u key bindings.

There probably should be a terminfo variant for CSI-u.

@wez
Copy link
Owner Author

wez commented Jun 21, 2020

What's left to call this done is to review this doc and verify that we're conforming when csi-u mode is enabled:
https://gitlab.freedesktop.org/gnachman/specifications/-/blob/feature_reporting/proposals/feature-reporting/csi_u.md

@alexherbo2
Copy link

Hello,

I was wondering how to see the list of options and their default values. I was looking for CSI u mode and was only able to find a reference in the change log to enable it.

~/.config/wezterm/wezterm.lua

return {
  enable_csi_u_key_encoding = true
}

@wez
Copy link
Owner Author

wez commented Nov 11, 2020

I was wondering how to see the list of options and their default values.

Ideally, the docs will have a clear section on each option. I try to make a point of covering the major features as they are completed.

In this case, it's not quite complete because it does require making another pass over the spec and then writing up the docs; one of the other items on my list here is work in progress in documenting all of the supported escape sequences input and output, and this is related.

If you wanted to go snooping for options, it's slightly awkward because the definition in code is in Rust, and there's a little bit of automated translation from lua. If you prefer reading code, the config/src directory is where the main Config struct is defined.
Alternatively, if you run: RUST_LOG=trace wezterm 2> /tmp/wezterm.trace and search for Config in /tmp/wezterm.trace you'll see the effective Config struct being used by wezterm.

wez added a commit that referenced this issue Feb 20, 2021
@ariasuni
Copy link

Kitty adopted a slightly different version of fixterms, according to them:

The protocol is based on initial work in fixterms, however, it corrects various issues in that proposal, listed at the bottom of this document. For public discussion of this spec, see #3248.

@stevenxxiu
Copy link

Thanks for this. I was trying to do this manually yesterday, and didn't see WezTerm's flag for this.

For some keys WezTerm appears to have not implemented the spec for:

Key Combo Spec (my reading) WezTerm's output
Alt + UpArrow \x1b[1;3A \x1b\x1b[A
Alt + LeftArrow \x1b[1;3B \x1b\x1b[B
Alt + RightArrow \x1b[1;3D \x1b\x1b[D
Alt + DownArrow \x1b[1;3C \x1b\x1b[C
Alt + Home \x1b[1;3H \x1b\x1b[H
Alt + End \x1b[1;3F \x1b\x1b[F
Ctrl + Shift + UpArrow \x1b[1;6A N/A
Ctrl + Shift + DownArrow \x1b[1;6B N/A
Ctrl + Shift + LeftArrow \x1b[1;6D N/A
Ctrl + Shift + RightArrow \x1b[1;6C N/A

@wez wez added the keyboard Keyboard mapping/handling label Jan 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request keyboard Keyboard mapping/handling
Projects
None yet
Development

No branches or pull requests

5 participants