Skip to content
This repository has been archived by the owner on Apr 5, 2024. It is now read-only.

Feature/refactor quit if only left #40

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

Conversation

weynhamz
Copy link
Contributor

@weynhamz weynhamz commented Dec 2, 2012

Only take action when we are in NERDTree window, and no more
window with normal buffer open.

Before quitting Vim, delete the buffer so that the '0 mark
is correctly set to the previous buffer. This avoids NERDTree
buffer being the last displayed buffer if Vim fails to quit
due to the last file in the argument list has not been edited
yet.

Then quit as usual, we have autocmd nesting open, so the 'quit'
will trigger other plugin window's quiting behavior. If we are
quiting Vim, our current buffer is successfully reset to the
last file buffer, no need to warry about failure.


I see you are a fan of linear commit history and git cherry-pick,
but git merge --no-ff could keep the merge history which is better
I think, just my thought, nothing important.

@jistr
Copy link
Owner

jistr commented Dec 15, 2012

Hmm. I'm kinda used to using :q to close just one tab, not Vim itself. I know that :tabclose makes more sense here, but I'm worried that more people use :q like I do and this would break their workflow too. Would it be possible to fix the '0 mark and keep :q just closing one tab?

Only take action when we are in NERDTree window, and no more
window with normal buffer open.

Before quitting Vim, delete the buffer so that the '0 mark
is correctly set to the previous buffer. This avoids NERDTree
buffer being the last displayed buffer if Vim fails to quit
due to the last file in the argument list has not been edited
yet.

Then quit as usual, we have autocmd nesting open, so the 'quit'
will trigger other plugin window's quiting behavior. If we are
quiting Vim, our current buffer is successfully reset to the
last file buffer, no need to warry about failure.
@weynhamz
Copy link
Contributor Author

Hey, @jistr, I have just updated the whole PR which fixes the problem while closing tabs, now it should be good to go.

@jistr
Copy link
Owner

jistr commented Apr 23, 2013

Heya, thanks for all the code submitted lately :) I'll get to it during the weekend hopefully :)

@jistr
Copy link
Owner

jistr commented Apr 28, 2013

The new code fixes the closing but I get problems with nerdtree width. Here are my steps:

  1. Run gvim.
  2. Select a file in nerdtree and press "t" on it (open in new tab).
  3. Close the tab with ":q".

Then I'm back at the first tab as expected, but now the nerdtree window is very wide and the window for file contents is very narrow. This doesn't happen on current master.

@weynhamz
Copy link
Contributor Author

That's odd, these code is actually already in tagbar, minibufexpl(develop branch), all works as expected, and it is also works in my test environment where only nerdtree and this plugin is loaded. There must be some code in your vimrc that mess it up, where can I find your vimrc file and what nerdtree-tabs setting have you configured?

@weynhamz
Copy link
Contributor Author

I am using a script called vim-reset to develop vim plugins, it could setup an stand alone vim environment where the runtimepath could be configured as disired.

@jistr
Copy link
Owner

jistr commented Apr 28, 2013

Sounds like the problem must indeed be with my setup. I'll try to find the problem.

@jistr
Copy link
Owner

jistr commented May 14, 2013

So I tested with all plugins disabled except for this one and NERDTree, but with my vimrc settings.

The problem happens when i have g:nerdtree_tabs_synchronize_view enabled (set to 1). When I disable it, it's ok. Do you have it enabled?

@weynhamz
Copy link
Contributor Author

Noop, that might be the problem, I will look into it.

@sentilesdal
Copy link

@jistr I was also currently getting the problem of the nerd tree window resizing to most of the screen size after updating a couple days ago. I don't have the g:nerdtree_tabs_synchronize_view option enabled. I was able to roll-back to fix the problem but the issue definitely exists in master right now.

@jistr
Copy link
Owner

jistr commented Feb 28, 2017

@sentilesdal Did you try with the very latest master? :) I think the issue has been fixed a few days ago by reverting a commit. See issue #84

@sentilesdal
Copy link

@jistr, I pulled last week sometime so I'm not sure. I'll try again later tonight after work ;) to cofirm. Thanks!

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

Successfully merging this pull request may close these issues.

3 participants