Focus gets confused, ends up with no split focused

[eapache]

environment

• vim: 7.4.1707 (Homebrew Macvim)
• vim-airline: 1bb8b62 (latest master at time of filing)
• OS: Mac 10.11.4 El Capitan
• terminal: iTerm 2.1.4 / ZSH

I discovered this via Tim Pope's fugitive originally, but it turns out that's just a convenient way to run the correct sequence of buffer commands to confuse airline. In a fresh vim (no need for fugitive):

• :e file1
• :split
• :e file2
• <leader>wj (switch to the bottom split)
• :e file2
• <leader>wk (switch back up)
• :bd
  Now the airline status bar is dimmed out (unfocused) incorrectly, even though there is no other split present which could possibly take focus.

[eapache]

possibly related to #1125 although nothing in this case is a preview, they're all regular file splits.

[chrisbra]

what are those mappings please?

[eapache]

The example steps that are now in the description are all pure (built-in) vim commands, no mappings needed. I will try to reproduce with a minimal vimrc/plugins to make sure nothing else is interfering.

[eapache]

It seems that this is a conflict with vim-stay somehow; I can reproduce the issue with just vim-stay and airline loaded via pathogen, and no other vimrc.

[chrisbra]

Yeah, I can't replicate this behaviour currently

[eapache]

I've filed a twin bug with vim-stay, but I'm not really sure which plugin is the root cause. If there's anything else you need please let me know.

[zr40]

I've encountered this bug without having vim-stay installed. List of possibly relevant plugins I do have installed:

Plug 'airblade/vim-gitgutter'
Plug 'ctrlpvim/ctrlp.vim'
Plug 'scrooloose/syntastic'
Plug 'tpope/vim-fugitive'
Plug 'vim-airline/vim-airline'
Plug 'vim-airline/vim-airline-themes'

[chrisbra]

Well if you can reliably reproduce, I would be interested how to do so

[kopischke]

@chrisbra I have been able to reproduce it in conjunction with vim-stay: the issue manifests itself whenever loading a session (or view session, in stay’s case) changes the buffer’s &statusline value. If the user did not change the default values for &viewoptions and &sessionoptions (which include options by default), that will happen on all session loads. The issue thus is not exactly stay-specific, but a plug-in constantly loading view session files does of course tend to make that problem surface ;).

[chrisbra]

hm, perhaps we need an OptionSet autocommand (if the Vim/Nvim supports it) to reset the statusline, if it is changed?

[kopischke]

perhaps we need an OptionSet autocommand (if the Vim/Nvim supports it) to reset the statusline, if it is changed?

That would cover all cases. For versions of Vim without OptionSet autocommand support, you might also consider handling SessionLoadPost as the defaults for session and view session files seem to be most likely to cause issues.

[chrisbra]

I think you are right, using OptionSet might not be the best choice (and would prevent the user from setting the option itsself (althought it wouldn't work anyhow)), so let's go ahead and use the SessionLoadPost autocommand. That's what i did in #1140.
@eapache when you used vim-stay, did you somehow disable airline earlier or does vim-stay reset the statusline option @kopischke ?

[kopischke]

@chrisbra the &statusline option was overwritten by the view session files Vim creates with default viewoptions settings and which vim-stay automatically loads on BufWinEnter – the plug-in is little more than an automation wrapper around :mkview / :loadview.

[eapache]

Using latest master (including #1140) of vim-airline does not fix the issue with master vim-stay. Switching to the pending 1.4 release of vim-stay does fix the issue, but I thought I'd mention it since my understanding was that the vim-airline fix was supposed to work regardless?

[chrisbra]

@kopischke Yes, but shouldn't the default viewfile include the statusline setting from vim-airline? e.g. the created sessionfile should save the statusline setting (with the value from vim-airline) so on restore, it resets back the statusline setting from vim-airline?

[kopischke]

@chrisbra yes it does, but that seems to throw airline off somehow. I might be wrong in assuming that it is specifically the &statusline change that causes this, of course, but that looks like the most likely culprit. What I can say for sure is that when view sessions store options and are loaded on BufWinEnter, the issue is present; when they don’t, it’s not. Would it help if I uploaded a view session file causing the issue?

[chrisbra]

Hi Martin!

On Do, 21 Apr 2016, Martin Kopischke wrote:

@chrisbra yes it does, but that seems to throw airline off somehow. I might be wrong in assuming that it is specifically the &statusline change that causes this, of course, but that looks like the most likely culprit. What I can say for sure is that when view sessions store options and are loaded on BufWinEnter, the issue is present; when they don’t, it’s not. Would it help if I upload a view session file causing the issue?

Yes, that would be appreciated!

[kopischke]

@chrisbra I’ve uploaded the view session file created when following the issue’s step by step instructions (which do reproduce the issue) and, for comparison purposes, the view session file for the same buffer when the options flag is not in &viewoptions, as a Gist.

[chrisbra]

I think, I understand now why this happens. e.g. when you create your viewfile the buffer is in a different window than when you restore the view. That would break, since the statusline setting includes the window number. However, since #1140 has been merged, I can't reproduce this issue anymore.

@eapache please test again

[eapache]

I can definitely still reproduce using the steps outlined in my original comment, with vim 7.4.1707 (Homebrew Macvim), vim-airline at d36085a (includes #1140) and vim-stay at zhimsel/vim-stay@89e5a31 (does not include zhimsel/vim-stay@6742c38).

[chrisbra]

okay, I think I found the problem. Going to create a PR in a second