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

Fish should check the current vi-mode when gaining focus and send the corresponding cursor shape sequence #4788

Closed
kmoschcau opened this issue Mar 7, 2018 · 2 comments
Assignees
Milestone

Comments

@kmoschcau
Copy link

@kmoschcau kmoschcau commented Mar 7, 2018

Hi, this isn't really a problem that I encounter when I have fish running in just a plain gnome-terminal.
But it really becomes apparent, when using tmux.

When you change the vi-mode in a fish session inside tmux, that works fine. As soon as you switch to another pane or window, which has currently something running that also modifies the cursor shape (like (n)vim or another fish session with a different vi-mode) and then switch back, the cursor shape is not returned to how it was when leaving the first pane.
This also occurs, when you exit a tmux pane or window, that already has another fish session running, because for the execution time of the command, the cursor shape is returned to the default.
From what I gather, this might be fixable, if you have fish check it's current vi-mode when gaining focus and then sending the corresponding cursor shape sequence again.

Here is some system info from me (I masked the machine name):

$ fish --version
fish, version 2.7.1
$ uname -a
Linux XXXXXXXXXXXX 4.13.0-36-generic #40-Ubuntu SMP Fri Feb 16 20:07:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 17.10
Release:	17.10
Codename:	artful
$ echo $TERM
xterm-256color-italic
$ tmux new
$ echo $TERM
tmux

If you want me to record an asciinema recording, I can do so. I never used it before so I didn't do it right now. Not sure cursor shapes would show up on it anyway.

@kmoschcau kmoschcau changed the title Fish should check the current vi-mode when gaining focus and set the corresponding cursor shape sequence Fish should check the current vi-mode when gaining focus and send the corresponding cursor shape sequence Mar 7, 2018
@faho faho added this to the fish-future milestone Mar 7, 2018
faho added a commit to faho/fish-shell that referenced this issue Mar 7, 2018
@faho
Copy link
Member

@faho faho commented Mar 7, 2018

I have an implementation of this that seems to be working - in my tmux-focus branch.

It works suchlike:

  • When tmux is detected (via the $TMUX variable being set) fish sends \e\[\?1004h to enable focus reporting on startup, postexec and \e\[\?1004l to deactivate it on preexec. I believe by sending the sequence we trigger it without requiring configuration on the tmux side (set -g focus-reporting on or something like that).

  • Then tmux will send \e\[I when fish's pane gains focus and \e\[O when it loses it (In/Out).

  • Fish binds \e\[I to an event (via the cheesy bind \e\[I 'emit fish_focus_in') and explicitly ignores \e\[O (and also \e\[\?1004h because I managed to get that while testing).

  • The fish-vi-cursor function listens to that fish_focus_in event in addition to the other triggers.

I believe this is nicely encapsulated and could be extended to other terminals and ways of signalling focus.

HOWEVER: I don't want to add this for 3.0 (which is scheduled for next month) unless it receives a bunch of testing from people on a wide variety of terminals, with and without tmux. I've been burned too many times by how much variety in terminals there is.

If it doesn't get that testing, I'll add it after 3.0 so it gets some more time to bake.

@kmoschcau
Copy link
Author

@kmoschcau kmoschcau commented Mar 7, 2018

Sounds good to me. It's no hurry, just a cosmetic thing anyway.

@faho faho self-assigned this Mar 7, 2018
@faho faho removed this from the fish-future milestone Jan 26, 2019
@faho faho added this to the fish 3.1.0 milestone Jan 26, 2019
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants