bug#19170: 25.0.50; enhancement request: `compare-windows' use across frames

[Drew Adams <drew.adams@oracle.com>]

> Below is the smallest patch that implements this feature.
> It refactors the next-window choosing logic into a separate
> function that you can redefine using define-advice if you want
> to define own logic.  By default, it provides a special command
> `compare-windows-set-next-window' that you can bind to an own key
> and use to define the next window that `compare-windows' will use,
> then move back to the original window and execute `compare-windows'
> normally (with or without its current argument to ignore
> whitespace).

Thanks for working on this, Juri.

I don't have the time to check it out well now, but a quick try
says please go for it.

Some things that I think are missing, or that might be helpful:

1. Maybe echo some indication of which two windows are compared (?).

2. Have a command that goes back and forth between the selected
   window and the previously selected one.  E.g., make the
   window-selecting command swap the values, so that the previous
   window is always the other one.

#2 will let you easily go between the two windows being compared,
but you will also be able to use it more generally.  IOW, whenever
another window is selected, update the previous-window value.

I guess maybe I'm specifying a different approach, where
instead of using `compare-windows-get-next-window' we would
use just (a) the selected window and (b) the previously selected
window.  (That would be the default behavior.)

And every command (should it be limited to interactive only?)
that selects a different window would automatically update the
saved value of the last-used window (a variable).

In sum, instead of having `compare-windows' be the one that
gets the "next window" (per `compare-windows-get-next-window'),
and instead of having command `compare-windows-set-next-window',
`compare-window' would just use the last two windows selected
(by default).  The real change would be in having the "last
window selected" be kept up to date automatically.

If that were done always, and not just when you select a window
interactively (dunno whether that is the right thing to do)
then presumably it could be, for example, `select-window' that
does it (updates a variable `last-window-selected').

I'm thinking that having that last-selected window recorded
always might be a good thing, useful for more than just
`compare-windows'.  (And perhaps (?) the NORECORD arg of
`select-window' should control updating of `last-window-selected'
also.  Dunno.)

What do you think?  Does this make sense?  If not, please go
with what you have; I'm sure it's an improvement on what is
there now.  Thx.