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

Gstatus not being wiped out #1158

Closed
sodapopcan opened this Issue Jan 4, 2019 · 11 comments

Comments

Projects
None yet
4 participants
@sodapopcan
Copy link
Contributor

sodapopcan commented Jan 4, 2019

Gstatus's bufhidden is set to delete instead of wipe. I'm not sure if this is intentional or not but it (or something, at least) is causing the Gstatus buffer to appear my jumplist.

As an aside: I'm loving the recent work you've been doing on fugitive—great quality of life improvements. Thank you!

@tracyone

This comment has been minimized.

Copy link

tracyone commented Jan 5, 2019

same here!

@tpope

This comment has been minimized.

Copy link
Owner

tpope commented Jan 5, 2019

Is this news? As far as I can remember it's always been delete.

@sodapopcan

This comment has been minimized.

Copy link
Contributor

sodapopcan commented Jan 5, 2019

I just checked and, yes, it has always been delete—I shouldn't have suggested a cause without looking into it further. My bad.

The issue stands, however, in that Gstatus is now showing up the jumplist when it never did before. I reported it firstly to see if you even consider it a bug and, if so, if you knew off the bat what was up.

If it's not something that bothers you but you wouldn't mind being fixed, I'd be happy to dig into it.

@tpope

This comment has been minimized.

Copy link
Owner

tpope commented Jan 5, 2019

I don't need you to dig into changing the word delete to wipe, but if you want to figure out why the buffer list changed, have at it. It might be related to no longer using a preview window. You can get the old behavior with :Gstatus!.

@sodapopcan

This comment has been minimized.

Copy link
Contributor

sodapopcan commented Jan 5, 2019

I just meant "dig in" to see if such a change would have side effects elsewhere or anything like that—a bit of hyperbole for sure, but I wasn't trying to be a smartass or anything.

I failed to notice that the original status window was a preview window, so that makes sense that it wouldn't appear in the jumplist. All in all, having bufhidden=wipe actually makes it behave like the Gcommit buffer which does appear in the buffer list but is wiped when closed.

Again, if this behaviour doesn't bother you then that's cool, but I very much like the new status window but find it bothersome to hit it when using <c-o>/<c-i>.

@rdlugosz

This comment has been minimized.

Copy link

rdlugosz commented Jan 10, 2019

Not sure that this is exactly the same thing, but I've also noticed a new behavior in Gstatus that is different than what I've been used to. My normal workflow is:

  1. make some code happen
  2. Open Gstatus via <leader>gs
  3. C-n to jump to first modified file
  4. tap - a few times to stage each modified file
  5. hit cc to replace the status split with a Gcommit buffer.
  6. Type a commit message, hit ZZ.
  7. All fugitive splits are now closed and I'm back in the file I had been editing.

With the new Gstatus it seems that hitting cc opens a new split with Gcommit and upon completing the commit the status split stays open. I tried using :Gstatus! instead, but observed the same behavior.

Is there a way to have the status buffer close automatically when you use cc to commit? Or, perhaps the problem is that my workflow isn't in line with how you intend people to use fugitive...?

@tpope

This comment has been minimized.

Copy link
Owner

tpope commented Jan 10, 2019

The reason for :Gcommit replacing the :Gstatus window was almost entirely to do with their visual similarity and the slick effect transitioning between them produced. Functionally, I think it was pretty much a wash, as closing the window was usually what you would want, but it only saves you a single q versus the larger annoyance when leaving it open was desired. And with the additional functionality of the new status buffer, "usually" is increasingly questionable.

@tpope

This comment has been minimized.

Copy link
Owner

tpope commented Jan 10, 2019

@sodapopcan the :Gstatus window should have a separate jump list regardless of whether or not it's a preview window. Are you navigating to another file in that window, or something?

@sodapopcan

This comment has been minimized.

Copy link
Contributor

sodapopcan commented Jan 10, 2019

I must have been been doing that as I've been sitting on this issue for the past week and hasn't happened since the first couple of days of upgrading. Clearly it just took some getting used to. Thanks for you reply—this is a non-issue as far as I'm concerned.

@tpope tpope closed this Jan 10, 2019

@sodapopcan

This comment has been minimized.

Copy link
Contributor

sodapopcan commented Jan 14, 2019

Sorry to come back to this but I finally was able to reproduce what was happening: It's being set to the alternate file after close. So open any file, :Gstatus<CR>q<c-^>, you get taken to the status window.

I use a mapping so updating it to call :keepalt Gstatus works for me, but I thought I'd share.

@tpope

This comment has been minimized.

Copy link
Owner

tpope commented Jan 14, 2019

More precisely, :split sets the alternate file, which is kind of strange, but that's Vim for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment