API extension of magit-status which can reuse existing status buffer without refresh?

[aspiers]

Hi there,

I did some research and reading of the code and couldn't find an existing API for this, so I hope it's a valid feature request but please forgive me if I missed something!

It's already well-known (e.g. discussed at length in #2982) that magit-status is an expensive operation in terms of constructing / refreshing a status buffer, and #2982 suggests many excellent routes for improving various aspects of this, some of which I believe are already in progress.

In this feature request, I would like to focus on one aspect, i.e. the use case where a user is invoking magit-status either directly, or indirectly via something like counsel-projectile-switch-project-action-vc. In this case, one possible optimisation which is very naive but nonetheless useful in some circumstances is simply to check whether there is already an existing magit status buffer for the repo, and if so, switch to it without refresh. While I'm guessing this may result in displaying outdated information in some cases, even then I think it would have value for the following reasons:

• Personally I am invoking counsel-projectile-switch-project countless times per day, so reducing this from a few seconds of delay[1] to near instant is well worth the sacrifice in accuracy of the displayed status.
• Often I want to see sections of the status buffer which I know have not changed since I last looked.
• Some sections (e.g. forge-insert-pullreqs and forge-insert-issues) can easily become out of date anyway, and that is already considered perfectly acceptable, so a similar argument for tolerating other sections becoming outdated seems reasonable.
• It is trivial to hit g to manually refresh the status buffer after switching to it if a refresh is required.

Of course I am not proposing that existing magit-status behaviour should be changed, but I think it would be great if some kind of simple API was offered for users like myself who prefer to have the choice of whether to reuse an existing status buffer without refresh where possible. This could either be something as simple as:

(defun magit-switch-to-status-buffer ()
  "A wrapper around `magit-status' which just switches to an existing
magit status buffer if it exists, to save rebuilding it."
  (interactive)
  (let ((buf (magit-get-mode-buffer 'magit-status-mode)))
    (if buf (switch-to-buffer buf)
      (magit-status))))

or perhaps an extra reuse-buffer argument to magit-status. (BTW I saw that magit-status already has a cache argument, but that appears to be an unrelated optimization.)

If such an API was available, then projectile could take advantage by offering it as an extra choice for projectile-switch-project-action, and similarly for other consumers of magit-status.

Hope that makes sense. Thanks for your consideration, and as always thanks for your incredibly awesome work!

[1]: I have identified and reported one cause of the delay in magit/forge#300, but based on my profiling described in that issue I think there are other causes too.

[tarsius]

Initial response: sounds like a good idea!

[aspiers]

FWIW, here is my quick and dirty hack to get the behaviour I want:

aspiers/emacs@8a0c676...786b29d

but it would be great if there was a cleaner way as part of the magit API.

Also, I have just filed a corresponding feature request for projectile: bbatsov/projectile#1609

[aspiers]

@tarsius Does the suggested implementation of magit-switch-to-status-buffer above look like it might be in the right ballpark (albeit perhaps with a directory argument currently missing)? If so I'm happy to submit a PR, but equally happy to be told it's way off and that you have a better way in mind ;-)

[tarsius]

Does the suggested implementation of magit-switch-to-status-buffer above look like it might be in the right ballpark (albeit perhaps with a directory argument currently missing)?

When taking this general approach and when prefix arguments are involved, then the wrapper command should probably deal with the prefixes by just interactively calling magit-status. The special prefix behavior should not be lost because (I assume) users who want to use this wrapper would just replace the global magit-status key binding and the alternative behavior should never-the-less remain available.

I am not sure this approach is the best. One alternative would be a custom option. Or a command that lets the user switch to any existing magit buffer for the current repository, not just the status buffer.

[aspiers]

Thanks. I'll try to fix the prefix behaviour as you've suggested.

I am not sure this approach is the best. One alternative would be a custom option.

I imagine that some users might want to be able to invoke both behaviours (e.g. via different key bindings, or via their own custom wrappers); bearing that in mind, adding a custom option for the behaviour seems like it might be a less clean solution, since that would require

(let ((new-custom-option 'some-value))
   (magit-status ...))

and if you have to do that, you might as well wrap it in a separate function to avoid duplication, at which point you're back to having two functions. Although I suppose there is some advantage to supporting a choice via the Custom UI.

Or a command that lets the user switch to any existing magit buffer for the current repository, not just the status buffer.

You mean a generic mechanism for reusing existing buffers like magit-log, magit-revision etc.? That sounds like it could be nice. Maybe a new magit-with-buffer-reuse macro which uses magit-get-mode-buffer in a similar way to the above example wrapper? Or did you have something else in mind?

[tarsius]

I went with your original proposal (plus tweaks) and the "switch to any repo buffer" command I proposed later.

[aspiers]

Awesome, thanks a lot!