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

[martin rudalics]

> 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