bug#74361: [PATCH] New option xref-navigation-display-window-action

[Juri Linkov <juri@linkov.net>]

> We can't reasonably expect packages to set up yet another alist entry
> type like 'group'.  package writers just would not understand it.  So it
> simply _has_ to be 'category' (or something else but still only one
> thing).

Better to use something else.  The 'category' alist entry
is intended to be used only in display-buffer calls like this:

  (display-buffer (get-buffer-create "*info*")
                  '(nil (category . Info-mode)))

to allow using 'category' in the condition part of display-buffer-alist
to match the display-buffer call:

  (add-to-list 'display-buffer-alist
               '((category . Info-mode)
                 (display-buffer-same-window)))

What you proposed is a different usage of 'category'
that makes sense in the action part of display-buffer-alist:

  (add-to-list 'display-buffer-alist
               '("\*Help\*"
                 (display-buffer-same-window)
                 (category . Info-mode)))

It would be cleaner to use a different action for this feature, e.g.:

  (add-to-list 'display-buffer-alist
               '("\*Help\*"
                 (display-buffer-reuse-category-window)
                 (category . Info-mode)))

or without an alist entry:

  (add-to-list 'display-buffer-alist
               '("\*Help\*"
                 (display-buffer-reuse-category-window)))

> Hence any magic users might not want would have to be implemented within
> 'display-buffer'.  If say 'run-scheme' wants the same window, then we
> already have a problem since a *scheme* window might already exist from
> a previous run and it should try 'display-buffer-reuse-window' first.
> But this is something for people setting up the default.
>
> Now if no 'inhibit-same-window' alist entry is found and the selected
> window is not dedicated to another buffer, 'display-buffer' would use
> the selected window as requested.  No automagic here.  Otherwise, it
> would look for a window with a 'category' window parameter equaling
> 'comint' which could, let's assume the worst, mean to use an existing
> *shell* window with a running process the user might be attentively
> following at that moment.  But the same could happen with your proposal
> as well.  So any automagic here should not harm either.
>
> The automagic would come into play when neither caller nor user specify
> a particular preference for a window or all other preferences have been
> exhausted and 'display-buffer' invokes 'display-buffer-use-some-window'
> (not 'display-buffer-reuse-window') in which case that function would
> look for a window with a matching 'category' parameter.  Which problems
> do you see here?

The only problem is that it will change the current default behavior,
so instead of using the lru window it will prefer to use the window
with the same category.  I customized 'display-buffer-base-action'
to use 'get-mru-window', so I won't be affected by this change,
but I care about other users.  Are you sure it would be expectable
for users to display buffers with the same category in one window?
How they could revert this behavior back to the previous default?

This is why I suggest to create a separate action.  If you are sure
it should be used by default, then it could be inserted
before display-buffer-use-some-window here:

  (defconst display-buffer-fallback-action
    '((display-buffer--maybe-same-window
       display-buffer-reuse-window
       display-buffer--maybe-pop-up-frame-or-window
       display-buffer-in-previous-window
       display-buffer-reuse-category-window ;; <-- NEW!
       display-buffer-use-some-window
       display-buffer-pop-up-frame))

Otherwise, users will be able to use the new action
display-buffer-reuse-category-window in their customizations
of display-buffer-alist.