fzf-tmux: A weird scrolling behavior when tmux pane is closed

[wookayin]

Hello,
First of all, thanks for the awesome utility, fzf.

I have an issue while using it with tmux, and I believe that perhaps tmux, not fzf, is responsible for the problem; however, as I think this situation might happen to a couple of fzf users and similar issues have been never reported to the best of my knowledge, I am going to open a question or issue.

Please take a look at the following animated screenshot:

• When inside a tmux session, fzf-tmux (or other hot-keys) will trigger a tmux pane is spawned, at the bottom of current window.
• Once the fzf pane is closed, the previous tmux pane to which fzf's result is passed would have a weird scroll position, which is quite annoying; specifically,
  
  
  
  • The absolute position of cursor (that user can see) is changed.
  
  
  • The contents (scrollback) before the clear command is (unwantedly) shown. (this is known to take place even when resize happens)
  
  

However, it seems that this does not happen in your animated screenshot at README.

I can reproduce a similar behavior even when I do not use fzf, i.e. closing a splitted pane in tmux would always make the top pane messed. This might be an evidence that this is a tmux problem.

I can reproduce this in all of combinations I could have;

• bash, zsh
• TERM being screen-256color, xterm, xterm-256color, etc.
• my tmux is currently 1.9a, but reproducible as well in 1.8, 2.0 (snapshot)
• Terminal emulator: iTerm2 and the OS X default Terminal.app

How are you using fzf-tmux? I see no differences on dotfiles or tmux configurations between us.
Does it ever happen to anyone other than me?

Thanks!

[junegunn]

Hi, thanks for the report. Actually I experience the same problem. Yeah, it looks like tmux _pulls down_ the content of the above pane when the one below it is closed. (Note that fzf-tmux -l and fzf-tmux -r don't have the issue.) The reason the demo on the README page doesn't have the problem is that it was performed on a new tmux window with empty scrollback buffer. Like you said, I guess it's the way tmux operates, yet I haven't checked if it's a known issue or if there's a workaround to it.

[wookayin]

Thanks for the immediate feedback.

I think I need to delve into the issue in company with tmux developer groups, or I will try to find any possible workaround. I will let you know once I come up with any progress.

[junegunn]

Thanks.

[nunoh]

Also have the same issue, which when opening and closing multiple panes regularly ends up to be kind of a bummer. @wookayin Did you end up finding any workaround? Thanks.

[brandoniffert]

Hey @wookayin, did you ever find a workaround? I just started using fzf and this is a minor annoyance.

[wookayin]

Unfortunately, I do not have any workaround as of now :disappointed:

To the best of my knowledge, after looking into the source code of tmux for a moment, I believe that tmux is not responsible for the issue. When closing a pane or resizing happens, tmux just adjusts the size and offset of each remaining pane while not being aware of scroll positions. The similar phenomenon happens even out of tmux; whenever a single terminal changed its size (e.g. by magnifying the window size of iTerm2 or PuTTY) its scrollback appears.

I suspect that to address this issue, one might utilize some control sequences in xterm related to cursor manipulation. However, my clumsy attempt was not successful.

[chaoren]

You can work around this with

alias clear='clear; tmux clear-history'
alias reset='reset; tmux clear-history'

[alcuadrado]

Thanks for that workaround @chaoren !

[chaoren]

The issue should now be fixed in tmux: https://github.com/tmux/tmux/commit/2627ab322e0e8dffbf86b1c2eb969139a8062174. I think this can be closed.

[junegunn]

@chaoren Just tried the latest build (brew reinstall tmux --HEAD) and it works just as expected. Great job!

[wookayin]

@chaoren Thanks for letting us know! Then we just need a latest version of tmux :)

Tmux 2.3 includes this.