This comment has been minimized.

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.

This comment has been minimized.

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!.

This comment has been minimized.

edited

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>.

This comment has been minimized.

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:

make some code happen

Open Gstatus via <leader>gs

C-n to jump to first modified file

tap - a few times to stage each modified file

hit cc to replace the status split with a Gcommit buffer.

Type a commit message, hit ZZ.

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...?

This comment has been minimized.

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.

This comment has been minimized.

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.

This comment has been minimized.

edited

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.