[github/core] Manage editors more intuitively when branches change

[savetheclocktower]

Have you checked for existing feature requests?

• Completed

Summary

I don't know how feasible this is, but I'm going to throw it out here.

• Suppose you have two git branches in your project.
• File foo.js exists on branch old, but not on branch new.
• You are on branch old. You open foo.js in order to make a change. You commit the change. You leave foo.js open in your workspace.
• You switch to branch new.

What Pulsar does in this situation is what it would always do if it detects that a TextEditor’s backing file has suddenly disappeared: keep the TextEditor open, but adjust its status to be “unsaved.” That's often the right move — you want an “are you sure?” dialog if you try to close the editor, and you want the indication in the tab bar that the item is not committed to disk.

But in a version-control scenario, it's not what I want.

---

Let me try to turn this into a feature request:

If I were more diligent, I could have avoided the situation in my example by closing the foo.js tab in my workspace before switching branches. So could the github package take care of that automatically?

• The package (presumably) detects when I've switched from branch old to branch new.
• It can iterate through each open TextEditor in my workspace and ask these questions:
  • Is this file tracked in this repository? (If not, ignore it.)
  • Is this file present on branch new? (If so, ignore it.)
  • Does this file have untracked changes on branch old? (If so, ignore it; this is a bit paranoid, since Git would forbid the user from switching branches in this scenario, but it's good to be cautious.)
  • Was this buffer “dirty” — e.g., did its contents differ from what was on disk just before the branch switch? (If so, ignore it.)
  • If we get this far, we've identified a workspace item that I would be annoyed at having to close manually.
• Automatically close all the TextEditor workspace items that meet all the above criteria.

What benefits does this feature provide?

Managing the number of open tabs is hard enough, even with zentabs. Any logic that can safely prune my list of open tabs without my intervention is a plus.

It doesn't necessarily have to be default behavior, either; I'd be fine with opting into this.

Any alternatives?

It's possible that the APIs exist for this to be its own package instead of something built into the github package. I'm only suggesting it for that package because I'm pretty sure it would be able to do this with its current libraries… but maybe it's something that any package could do.

I notice that the GitRepository class is a bit short on event subscriptions; I would've expected a way to register a callback on a branch change, but maybe that wouldn't be too hard to add to core.

Other examples:

VS Code, in this scenario, keeps the editor open, but marks the file as “deleted”:

Even though this file has an open editor, VS Code correctly recognizes that it would not be destructive to close the tab at this point, and it will not ask me to confirm when I close this tab.

If I were to edit the buffer, the tab would change to add a “dirty” indicator, and will now show a confirmation dialog if I try to close the tab:

And if I save the open buffer while it's in the “deleted” state — whether I made changes or not — it commits the file to disk, abandons this “deleted” status, and correctly marks it as a new, untracked file in this branch:

---

I'm fine with this behavior, especially as a medium-term goal, but I'd also be OK with VS Code just closing those tabs — if it knows enough to mark them as “deleted,” it knows enough to close them automatically for me. (There might be a setting for that; I haven't looked.)

But I know that's something that would definitely need to change in core, so I'm wondering if we can do the simpler thing in the short term.

[savetheclocktower]

After some further tests, I can confirm that VS Code's behavior here matches what it does even outside the presence of a repository. If I have a file open in VS Code, and I delete the underlying file on disk, VS Code reacts exactly as documented above; it recognizes the “deleted” state of the file and indicates it with the strike-through and the red status color.

We ourselves could have such a state for all files. Aside from cosmetics, the major difference in VS Code is that you can close the editor of a deleted tab without an “are you sure?” confirmation; I suppose they feel like the red text and the strike-through are enough of a warning. (That confirmation will still happen, though, if the TextEditor was in a dirty state when the file was deleted.)

This would have to be a core change, but it's at least possible that this wouldn't be painful.

[savetheclocktower]

The other unknown aspect is how Pulsar, or the github package, detects when the user switches branches in a Git repo. I can't find anything in the docs for git-utils or dugite that would provide me what I want here, which is a callback that gets invoked whenever a given reference is checked out (whether or not it was initiated within Pulsar).

I figure that must exist, since various parts of the github package react when I switch branches. But I'm not sure how it gets notified.