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

In vim normal mode, Ctrl + i does not work as expected (i.e. does not move forward in jump list) #214

Closed
krishnakumarg1984 opened this issue Jun 10, 2020 · 8 comments
Labels
bug Something isn't working

Comments

@krishnakumarg1984
Copy link

krishnakumarg1984 commented Jun 10, 2020

Bug description

Inside vim, after performing a jump action to a previous position, the Ctrl + i sequence is used to jump forward in the jump list. This does not work in the current version of wezterm and instead, we enter vim's insert mode in the buffer.

Environment

  • OS: macOS
  • Version: wezterm 20200608-110940-3fb3a61
  • Vim: 8.2.0539

To Reproduce

  1. Fire up vim without any plugins or startup file like so: vim -u NONE
  2. Open up any moderately long text file. Just as an example to demo this issue, in normal mode, perform a sequence of some random jumps, eg. G, gg, 50%,25%, 75%
  3. Now, press Ctrl + o to go to an older position
  4. Now, press Ctrl + i to go forward in jump list (i.e. to the newer position)
  5. vim unexpectedly enters insert mode!

Configuration

This issue occurs even with a default install of wezterm. No specific configuration file was created.

Expected behavior

vim should jump forward in the jump list when Ctrl + i sequence is pressed in normal mode.

Additional context

The same issue occurs in neovim (v0.4.3) as well.

@krishnakumarg1984 krishnakumarg1984 added the bug Something isn't working label Jun 10, 2020
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.
@wez
Copy link
Owner

wez commented Jun 11, 2020

(this is the same underlying issue as #213

@wez wez closed this as completed Jun 11, 2020
@krishnakumarg1984
Copy link
Author

Thanks for the fix!

@krishnakumarg1984 krishnakumarg1984 changed the title In vim normal model, Ctrl + i does not work as expected (i.e. does not move forward in jump list) In vim normal mode, Ctrl + i does not work as expected (i.e. does not move forward in jump list) Jun 11, 2020
@krishnakumarg1984
Copy link
Author

@wez Hopefully this will make it to homebrew soon.

@wez
Copy link
Owner

wez commented Jun 11, 2020

I tend to review and tag releases roughly every 4-6 weeks, and we just had a tag last weekend.

You can however use brew install --HEAD wezterm to pick up the nightly build via our homebrew tap!

@krishnakumarg1984
Copy link
Author

krishnakumarg1984 commented Jun 12, 2020

@wez Using the head (nightly) version shall not work for me because every brew update will trigger downloads everyday, and I am on a metered internet connection.

Perhaps it is best for me to wait out until the next release. In the meantime, do you think this issue should be open?

@wez
Copy link
Owner

wez commented Jun 12, 2020

brew update just syncs the recipe definitions. brew upgrade is what will install recipes if their versions have changed. If you have performed a HEAD install, brew will consider you to already be on head and won't actually upgrade unless you first uninstall; I tried this just now:

$ brew upgrade wezterm
Warning: wez/wezterm/wezterm HEAD already installed

so I don't think this will impose any additional cost on your metered connection.
WezTerm will display a window advising you of when the next tag is made,
and at that time you can switch back to the normal tagged install if you wish.

@krishnakumarg1984
Copy link
Author

krishnakumarg1984 commented Jun 13, 2020

@wez Yup. This works now. Thanks a lot for your support!

@github-actions
Copy link
Contributor

github-actions bot commented Feb 4, 2023

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants