search

drmikehenry / vim-fixkey

https://github.com/drmikehenry/
125 stars 10 forks source link

Fix some issues with VTE terminals and tmux #15

Closed prurigro closed 3 years ago

prurigro commented 3 years ago

This solves two problems I've been having:

  1. VTE terminals that use xterm-256color (namely xfce4-terminal, I don't have gnome-terminal installed but assume it works as expected) has had an issue where the first key you hit does nothing, and this seemed to be the case when setting COLORTERM to gnome-terminal too. Skipping the functionality specific to gnome-terminal and xterm eliminates this issue.

  2. The mouse couldn't click anything past the ~210th character in tmux, this turned out to be because the plugin was overriding my ttymouse=sgr setting. To keep consistent with the way the plugin worked before I updated xterm to sgr, though it might be more kosher to simply drop the declaration and let the user decide.

drmikehenry commented 3 years ago

Hi, Kevin,

Taking the issues in reverse order, I think it makes sense to avoid unconditionally setting ttymouse when TERM=tmux*. This was a work-around added in 2016 to fix problems with the Home and End keys (see #7). At the time, Vim would detect TERM=screen* and set ttymouse=xterm, but it had no such help for tmux. However, as of Vim v8.0.0030 (from late 2016), ttymouse defaults to xterm before .vimrc is sourced. In order to support older versions of Vim, it seems reasonable to keep setting ttymouse=xterm for the tmux* case, but only if ttymouse is empty. That way, on newer versions of Vim, Fixkey won't get in the way of later logic that performs terminal probing and potentially changes ttymouse to a more specific value, and it will not clobber the user's preferences from .vimrc.

Regarding the first issue, I don't recall ever testing against xfce4-terminal. I'm running Kubuntu 18.04, so I just installed xfce-terminal 0.8.7.4. I setup a test user with the Fixkey plugin and the following minimal ~/.vim/vimrc and using Vim v8.2.1195:

syntax on

set rtp^=$HOME/.vim/vim-fixkey

With this configuration, I'm unable to replicate the issue you mention with Vim ignoring the first keypress.

But I'm also unclear about the goal of your pull request for this issue. Based on the proposed change, Fixkey would be disabled when TERM=xterm* and COLORTERM is non-empty but not equal to gnome-terminal. I don't know the usual expected value of COLORTERM for this terminal, but on my system, COLORTERM=truecolor when running xfce4-terminal, so Fixkey ends up completely disabled. For example, the test mapping map <m-u> :echo 'm-u'<CR> currently works for me on my system, but stops working with the application of the change in the pull request.

It would be helpful if you could strip down your Vim configuration to a trivial ~/.vim/vimrc like the one above and remove all other plugins, then see if the issue remains. This would help rule out issues from other plugins or settings from your normal configuration, and we can determine if the version of xfce4-terminal matters.

Also, you might try setting a larger value for g:Fixkey_setupDelay to see if there's a timing-related problem with Vim's terminal negotiation phase on your system. Adding let g:Fixkey_setupDelay=500 to your vimrc would give 500 milliseconds of time for Vim to complete any terminal negotiation before setting up Fixkey. This configuration option was added in response to #11; maybe your issue has a related underlying cause.

In my (limited) testing with xfce4-terminal, Fixkey is working correctly; hopefully we can figure out what's different on your system so it can work for you as well.

prurigro commented 3 years ago

Hmm, for some reason when I was playing with it before it seemed like fixkey was still doing something, but I just tried without vim-fixkey and it seems like the special cases that weren't working in other terminals without it are still working in xfce4-terminal. I have to admit that I didn't dive deep enough to see if anything was still running with an undetected terminal type.

As for the flash issue, I get that on multiple archlinux-based boxes (including one archlinuxarm) as well as in termux on my phone (which has COLORTERM set to truecolor). It's possible that I have additional configuration interfering with the plugin (the issue doesn't present itself in the same terminals within tmux on that note).

I'll close this PR, but I think it might be worth seeing if vim-fixkey is actually necessary on vte3-based terminals and termux these days.

drmikehenry commented 3 years ago

That's interesting; in my testing, I find that xfce4-terminal works much like other xterm-compatible terminals. Without Fixkey on xfce4-terminal I find that alt-letter, alt-number, and the newly supported alt-shift-number keys don't work, though function keys (with or without modifiers) are working. Based on my testing, I believe Fixkey is needed for xfce4-terminal. I'm quite possibly running an older version of the terminal (especially if you are an Arch user :-)), so perhaps things work better without Fixkey on newer versions of that terminal.

I've released Fixkey v0.3.13; this version now avoids overwriting a non-empty ttymouse setting, addressing that portion of your pull request.

If you want to investigate further, I'd recommend sourcing Fixkey's test script (found in scripts/fixkeytest.vim) to get convenient mappings for all of the keys that Fixkey attempts to fix. You can test both with and without Fixkey itself being active to determine whether Fixkey is doing anything useful for your setup.

Another way I test is to make a clean environment containing only Fixkey as follows:

Then press a bunch of keys (alt-letter (uppercase/lowercase), alt-number, function keys, etc.) and see what works.

If your testing uncovers some way that Fixkey could behave better with xfce4-terminal, feel free to open a new ticket.