bug#45688: 28.0.50; New action for display-buffer?

[martin rudalics <rudalics@gmx.at>]

 > XEmacs does absolutely the wrong thing.  When I have a window
 > with a source buffer, then run grep in another window, then
 > want to visit grep hits in the third window, visiting
 > the next file from the grep window obscures the window
 > with the source buffer, it doesn't use the same window
 > where I'm visiting grep hits.

We're asking too much from 'display-buffer' here.  It can't second-guess
a user's intentions in particular with the interpretation of grep and
xref hits.  I see three basic patterns here:

- a hit is detected in a buffer currently shown but that window's point
   is the position where I want to continue to work - show the hit in
   another window,

- a hit is detected in a buffer currently shown and I don't care about
   that window's current point - move that window's point to the hit,

- one or a few hits are already shown in windows and I would like to
   either compare them or at least for the moment not lose any of these
   windows (no matter how small they are) - try popping up yet another
   window.

Do you have more?  In either case, I cannot generally predict beforehand
which of these will apply in a specific situation so I'd like to see
some versatile grep/xref-DWIM layer that handles these patterns ad hoc,
possibly assisted by some simple M-g binding.  But we have to identify
all potentially useful patterns first.

 > I tried to replace get-lru-window with get-mru-window
 > but it selects the current window which is mru indeed,
 > but makes no sense - what is needed is mru-1, then
 > I tried to set the arg NOT-SELECTED of get-mru-window to t
 > in display-buffer-use-some-window, then it works sensibly.

Neither of these will catch all needs: mru-ish replaces the previous hit
found, lru-ish the oldest hit found so far.  Any of these might be the
most interesting one found so far.

martin