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

Tab feature #65

Open
wants to merge 18 commits into
base: master
Choose a base branch
from
Open

Tab feature #65

wants to merge 18 commits into from

Conversation

enthudave
Copy link
Contributor

Implements the following:

Copy link
Contributor Author

@enthudave enthudave left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was removed because it caused problems with vim-gitgutter

@enthudave
Copy link
Contributor Author

enthudave commented Jun 14, 2018

mmm, as you know I'm still learning git(hub), that 'review' was meant to accompany commit
91bdf17 about tempname()

@enthudave
Copy link
Contributor Author

enthudave commented Jun 15, 2018

I'm not sure what to do when the user edits a directory but doesn't choose a file.
In light of your decision to not consider the directory buffer for the alternate, it means that if a user has:

  1. fileA
  2. fileB
  3. edits a directory
  4. a. does not choose a file
    he should end up with fileB open and fileA being alternate.
    b. does choose a file
    he should end up with the new file and fileB being alternate

4b is easy, we determine what the alternate buffer is in the directory buffer before opening Ranger, and pass it as a window variable.
4a however I've no idea how to do, the problem is knowing what the alternate buffer was before the user edited a directory. Before they do so, the plugin has no functions running, no way to go back in time to before the new (directory)buffer was created and as a result we have an extra buffer standing between us and an easy way to determine the alternate

@francoiscabrol
Copy link
Owner

About 4a, I found a neovim function let buffers = nvim_list_bufs() that return the buffer numbers as an array. So I guess the third element should be the fileA: let fileA = nvim_list_bufs()[2].

@enthudave
Copy link
Contributor Author

I don't think we can rely on the buffer numbers, that would work in this simple example, but I think the buffer numbers do not represent the order in which buffers are visited, only the order in which they were opened, there's a big difference most of the time.

@enthudave
Copy link
Contributor Author

If there's a function that returns a list of the order in which buffers have been visited for the current session or something that would be exactly what we need

@francoiscabrol
Copy link
Owner

francoiscabrol commented Jun 17, 2018

hum yes I found this PR of fzf junegunn/fzf.vim@852cfa0#diff-7274b7c6c87526542ef9087f2e997dfaR411 that solve this specific problem of getting the buffers list ordered... but it doesn't look obvious. The related issue is junegunn/fzf.vim#100

@enthudave
Copy link
Contributor Author

That is quite similar to the workaround I had in my mind, except that I wasn't thinking to use a timestamp, just a window variable (w:old_alternate) to set on BufLeave with that buffer's alternate, so a new buffer in the window can look into that. I just didn't want to have to do this for every BufLeave

@neumachen
Copy link

neumachen commented Feb 16, 2019

Any plans on merging this @francoiscabrol?

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

Successfully merging this pull request may close these issues.

None yet

3 participants