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

relativenumber is turned off for buffers opened in a split via fzf #396

Closed
3 of 9 tasks
naps62 opened this issue Jun 28, 2017 · 10 comments
Closed
3 of 9 tasks

relativenumber is turned off for buffers opened in a split via fzf #396

naps62 opened this issue Jun 28, 2017 · 10 comments

Comments

@naps62
Copy link

naps62 commented Jun 28, 2017

  • Category
    • Question
    • Bug
    • Suggestion
  • OS
    • Linux
    • macOS
    • Windows
    • Etc.
  • Vim
    • Vim
    • Neovim

This seems to happen in neovim (v0.2.0), but not in vim

Reproducing

  1. open a minimal vim setup (taken from the issue template):
nvim -Nu <(curl https://gist.githubusercontent.com/junegunn/6936bf79fedd3a079aeb1dd2f3c81ef5/raw)`
  1. set up relative line numbers:
:set relativenumber
  1. open a file via the :Files command in a horizontal or vertical split or tab (i.e. search for any file, and press Ctrl-X, Ctrl-V or Ctrl-T)

  2. The newly open buffer will not have relative numbers enabled

Doing something such as autocmd BufEnter * set relativenumber does not seem to help
Also, opening the new file in the same buffer instead of in a split does not trigger the issue

This issue does not occur with set number. only relative numbers seem to be affected

@junegunn
Copy link
Owner

Does this seem related? junegunn/fzf#930

@naps62
Copy link
Author

naps62 commented Jun 30, 2017

@junegunn It seems similar, and could be related, but it's not exactly the same thing. That issues seems to disable vim's relativenumber option globally as soon as you open an fzf panel.

My issue happens when I open a split via FZF. But if I later open a new split through some other method (nerdtree, or simply :e, that buffer will have relativenumber set up as expected.

Also, not sure if relevant, but that issue is marked as happening in both neovim and vim, where mine seems to not happen on my vim installation, and only in neovim

@junegunn
Copy link
Owner

The vim plugin of fzf and fzf.vim do not set or unset relativenumber (you can't find the term anywhere in the source code), so I'm pretty sure it's a Neovim issue. If you still have issues with the latest Neovim compiled with neovim/neovim#6796, you might want to contact the Neovim guys.

@naps62
Copy link
Author

naps62 commented Jul 7, 2017

@junegunn I can confirm that building neovim from their master branch fixes the issue. Thanks!

Oh, and thank you for an awesome tool

@rcorre
Copy link

rcorre commented Jul 21, 2017

It seems fixed on neovim master, but the FZF split now has line numbers. Is that expected?

1500601849

@junegunn
Copy link
Owner

Seems like now terminal windows follow the same default options as other windows. Do you think fzf should override and disable line numbers?

@junegunn
Copy link
Owner

Related: neovim/neovim#6832

@rcorre
Copy link

rcorre commented Jul 22, 2017

Do you think fzf should override and disable line numbers?

I would like that, and think it is reasonable. Line numbers don't contribute useful information within the FZF pane and just take up space.

Alternatively FZF could instruct users to use this solution from the issue you referenced:

au TermOpen * setlocal nonumber norelativenumber

That disables lines in all terminal buffers though, which may not be desirable.

junegunn added a commit to junegunn/fzf that referenced this issue Jul 23, 2017
junegunn/fzf.vim#396 (comment)

One can override the setting on FileType fzf autocmd.
@junegunn
Copy link
Owner

See junegunn/fzf@a2604c0

Let me know if you run into any issues.

@rcorre
Copy link

rcorre commented Jul 23, 2017

Works for me, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants