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

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

[Drew Adams]

Provide support for `compare-windows' to compare two windows in
different frames.  Ediff lets you compare buffers in different frames.
It would be great if `compare-windows' did also.

Yes, this would require users to choose the windows, instead of just
using the selected window and the next window.  This could be optional.

Or it could be solicited by, e.g., using a particular prefix arg value.
E.g., with a non-negative prefix arg, do what the presence of any prefix
arg does now.  With a non-positive prefix arg, prompt the user to choose
the 2 windows.  (So a zero prefix arg would do both.)

Choosing a window could take any reasonable form: click mouse-1 in it,
choose by its buffer name (with uniquification when multiple windows
show the same buffer),...

Successive calls (with no prefix arg) should, as now, keep using the
same two windows.

(None of the current behavior should be lost, in particular, behavior
per `compare-windows-sync'.)

In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
 of 2014-10-20 on LEG570
Bzr revision: 118168 rgm@gnu.org-20141020195941-icp42t8ttcnud09g
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking=yes,glyphs CPPFLAGS=-DGLYPH_DEBUG=1'

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

[Juri Linkov]

> (None of the current behavior should be lost, in particular, behavior
> per `compare-windows-sync'.)

Thanks for the bug report.  The patch below fixes it in
`compare-windows-sync' to use the same frame-selecting logic
like existed for a long time in `compare-windows':

diff --git a/lisp/vc/compare-w.el b/lisp/vc/compare-w.el
index 25d4cf7..26f8be4 100644
--- a/lisp/vc/compare-w.el
+++ b/lisp/vc/compare-w.el
@@ -304,6 +304,9 @@ on third call it again advances points to the next difference and so on."
   (if (not compare-windows-sync-point)
       (let* ((w1 (selected-window))
              (w2 (next-window w1))
+             (w2 (if (eq w2 (selected-window))
+		     (next-window (selected-window) nil 'visible)
+		   w2))
              (b2 (window-buffer w2))
              (point-max2 (with-current-buffer b2 (point-max)))
              (op2 (window-point w2))

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

[Drew Adams]

> > (None of the current behavior should be lost, in particular,
> > behavior per `compare-windows-sync'.)
> 
> Thanks for the bug report.  The patch below fixes it in
> `compare-windows-sync' to use the same frame-selecting logic
> like existed for a long time in `compare-windows':

Thanks, that does indeed seem to take care of the sync behavior,
for `compare-windows-sync-default-function', at least.

The main reason for the bug report, however, is the inability
to choose the two windows, especially when they are in different
frames.  Cycling via `other-window' is limited when you have
multiple frames (each possibly with multiple windows).  It is
even somewhat limited in the typical case of two windows in the
same frame.

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

[Drew Adams]

BTW, while you're at it, you might also want to remove the unused variable
`w1' from `compare-windows'.  Not important, but it's useless.

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

[Juri Linkov]

> The main reason for the bug report, however, is the inability
> to choose the two windows, especially when they are in different
> frames.  Cycling via `other-window' is limited when you have
> multiple frames (each possibly with multiple windows).  It is
> even somewhat limited in the typical case of two windows in the
> same frame.

Ediff-windows is session-based, whereas compare-windows is stateless.
It would be a major inconvenience to select a window to compare
before every invocation of compare-windows.  Although I'm aware
of this problem in the single frame with three windows, at least
the rule of selecting a window is simple, so it's easy to arrange
windows in the previous-next order for comparison.

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

[Drew Adams]

> > The main reason for the bug report, however, is the inability
> > to choose the two windows, especially when they are in different
> > frames.  Cycling via `other-window' is limited when you have
> > multiple frames (each possibly with multiple windows).  It is
> > even somewhat limited in the typical case of two windows in the
> > same frame.
> 
> Ediff-windows is session-based, whereas compare-windows is
> stateless.
> It would be a major inconvenience to select a window to compare
> before every invocation of compare-windows.

I didn't say before every invocation of compare-windows, did I?

I said that an optional behavior would be to choose the second
window in some way.  IOW, on user request (e.g., via non-positive
prefix arg), a user would be able to choose the second window.

How to choose?  Click the mouse in a window, or choose a window
by name using the keyboard - those are two possibilities I
suggested.

I can code something up as a POC, when I get a moment, if that
helps.

Yes, I realize that things are different for Ediff: `buffer-list'
is ordered wrt access time, and there is no equivalent list for
windows (AFAIK).  For Ediff, you can just click two buffers with
the mouse and they become the defaults, because of the time-ordering
of `buffer-list'.  (Ediff only needs the buffer, regardless of which
window you click in that might be showing the same buffer.)

> Although I'm aware
> of this problem in the single frame with three windows, at least
> the rule of selecting a window is simple, so it's easy to arrange
> windows in the previous-next order for comparison.

I guess I'm not aware of this.  What is the "rule of selecting a
window", so that I can get `compare-windows' to compare the
selected window against any other window that I choose?

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

[Juri Linkov]

> How to choose?  Click the mouse in a window,

This is what `ediff-get-window-by-clicking' does.
But what to do if the user doesn't use the mouse?

> or choose a window by name using the keyboard -
> those are two possibilities I suggested.

You mean to choose a window by it's buffer name?
I.e. like `ediff-buffers'?  But the problem is that the
uniqueness of buffer names is not guaranteed in this case.

What do you think about such workflow: select a target window
using normal keybindings or mouse clicks.  Then mark the
selected window as the target window using a new prefix
of `compare-windows'.  Then switch back to the original window
using standard keybindings, and run `compare-windows'.
It could use the remembered target window.

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

[Drew Adams]

> > How to choose?  Click the mouse in a window,
> 
> This is what `ediff-get-window-by-clicking' does.

Yes.

> But what to do if the user doesn't use the mouse?

See next.

> > or choose a window by name using the keyboard -
> > those are two possibilities I suggested.
> 
> You mean to choose a window by it's buffer name?
> I.e. like `ediff-buffers'?  But the problem is that the
> uniqueness of buffer names is not guaranteed in this case.

See what I wrote at the outset:

  Choosing a window could take any reasonable form: click mouse-1
  in it, choose by its buffer name (with uniquification when
  multiple windows show the same buffer),...

FWIW, I use this in Icicles.  Maybe it helps to give an idea what
I had in mind wrt window naming.  If not, ignore.

(defun icicle-make-window-alist (&optional all-p)
  "Return an alist of entries (WNAME . WINDOW), where WNAME names WINDOW.
The name of the buffer in a window is used as its name, unless there
is more than one window displaying the same buffer.  In that case,
WNAME includes a suffix [NUMBER], to make it a unique name.  The
NUMBER order among window names that differ only by their [NUMBER] is
arbitrary.

Argument ALL-P determines which frames to use when gathering windows,
as follows:

* `visible'         - include windows from all visible frames.
* otherwise non-nil - include windows from all frames (including
                      those that are iconified and invisible).
* nil               - include only windows from the selected frame."
  (lexical-let ((win-alist  ())
                (count      2)
                wname new-name)
    (walk-windows
     (lambda (w)            ; FREE here: COUNT, NEW-NAME, WIN-ALIST, WNAME.
       (setq wname  (buffer-name (window-buffer w)))
       (if (not (assoc wname win-alist))
           (push (cons wname w) win-alist)
         (setq new-name  wname)
         (while (assoc new-name win-alist)
           (setq new-name  (format "%s[%d]" wname count)
                 count     (1+ count)))
         (push (cons new-name w) win-alist))
       (setq count  2))
     'no-mini
     (case all-p
       (visible 'visible)
       ((nil)   'this-frame)
       (otherwise  t)))
    win-alist))

> What do you think about such workflow: select a target window
> using normal keybindings or mouse clicks.  Then mark the
> selected window as the target window using a new prefix
> of `compare-windows'.  Then switch back to the original window
> using standard keybindings, and run `compare-windows'.
> It could use the remembered target window.

Not sure I understand what you describe, but it sounds like you
mean to just somehow select the other window (the one you want,
not `other-window'), then move back to the original window, and
have the fact that the other window was the previously selected
window let it be used as the default second window for the
comparison.

If so, yes, that's what I was suggesting by comparison with
Ediff.  With buffers it is enough to select another buffer, to
make it become recorded as the previous buffer, so it becomes
the default.

But that works because `buffer-list' records chronological access.
AFAIK, we do not have that (yet) for windows.  And yes, we need
only record the previously selected window, not a whole access
history (at least for this command).

This would be for the click-in-another-window approach.  But
for keyboard use the problem really is, as I see it, that when
there are many windows (this is across possibly many frames)
the usual way to select one of them, which is to repeat `C-x o',
is tedious.  That's why I suggested choosing by name in this case.

HTH.

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

[Juri Linkov]

> And yes, we need only record the previously selected window,
> not a whole access history (at least for this command).

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).

diff --git a/lisp/vc/compare-w.el b/lisp/vc/compare-w.el
index 25d4cf7..a8a0a17 100644
--- a/lisp/vc/compare-w.el
+++ b/lisp/vc/compare-w.el
@@ -140,6 +140,22 @@ out all highlighting later with the command `compare-windows-dehighlight'."
 (defvar compare-windows-overlays2 nil)
 (defvar compare-windows-sync-point nil)
 
+(defvar compare-windows-next-window nil)
+
+(defun compare-windows-set-next-window ()
+  (interactive)
+  (setq compare-windows-next-window (selected-window)))
+
+(defun compare-windows-get-next-window ()
+  (let ((w2 (if (window-live-p compare-windows-next-window)
+		compare-windows-next-window
+	      (next-window))))
+    (if (eq w2 (selected-window))
+	(setq w2 (next-window (selected-window) nil 'visible)))
+    (if (eq w2 (selected-window))
+	(error "No other window"))
+    w2))
+
 ;;;###autoload
 (defun compare-windows (ignore-whitespace)
   "Compare text in current window with text in next window.
@@ -179,11 +195,7 @@ on third call it again advances points to the next difference and so on."
                            'compare-windows-sync-regexp
                          compare-windows-sync)))
     (setq p1 (point) b1 (current-buffer))
-    (setq w2 (next-window))
-    (if (eq w2 (selected-window))
-	(setq w2 (next-window (selected-window) nil 'visible)))
-    (if (eq w2 (selected-window))
-	(error "No other window"))
+    (setq w2 (compare-windows-get-next-window))
     (setq p2 (window-point w2)
 	  b2 (window-buffer w2))
     (setq opoint2 p2)
@@ -303,7 +315,7 @@ on third call it again advances points to the next difference and so on."
 (defun compare-windows-sync-default-function ()
   (if (not compare-windows-sync-point)
       (let* ((w1 (selected-window))
-             (w2 (next-window w1))
+             (w2 (compare-windows-get-next-window))
              (b2 (window-buffer w2))
              (point-max2 (with-current-buffer b2 (point-max)))
              (op2 (window-point w2))

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

[Drew Adams]

> 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.

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

[Juri Linkov]

> Some things that I think are missing, or that might be helpful:
>
> 1. Maybe echo some indication of which two windows are compared (?).

Currently `compare-windows' displays in the echo area "Mark set"
which is mostly useless.  We could overwrite it with more specific
messages, e.g.

  Next difference between window1 and window2
  Next match between window1 and window2
  No more matching points between window1 and window2

> 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?

We already have a lot of `last-...' variables, so a new variable
for the last selected window makes sense.  Then it would be
convenient to compare `(selected-window)' with `last-selected-window'.

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

[Drew Adams]

> > Some things that I think are missing, or that might be helpful:
> >
> > 1. Maybe echo some indication of which two windows are compared
> > (?).
> 
> Currently `compare-windows' displays in the echo area "Mark set"
> which is mostly useless.  We could overwrite it with more specific
> messages, e.g.
> 
>   Next difference between window1 and window2
>   Next match between window1 and window2
>   No more matching points between window1 and window2

Please do.

And maybe print the point values too, unless they're the same buffer?

Different, A: 2349, B: 1358
Same: A: 2349, B: 1358
No match

Dunno what the names might be.  They could be the buffer names
(possibly truncated, if long), if different.

> > 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?
> 
> We already have a lot of `last-...' variables, so a new variable
> for the last selected window makes sense.  Then it would be
> convenient to compare `(selected-window)' with `last-selected-
> window'.

Please do.  I'm sure that whatever you come up with will be good.

IMO, this will make the command much more useful.  I've been
using it for decades, but never gave much thought to trying
to improve it.  It is a very useful command.

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

[Juri Linkov]

> And maybe print the point values too, unless they're the same buffer?
>
> Different, A: 2349, B: 1358
> Same: A: 2349, B: 1358
> No match

Or the size of the region of difference or sameness.

> Dunno what the names might be.  They could be the buffer names
> (possibly truncated, if long), if different.

There is no displayable information associated with windows
other than buffer names.

>> We already have a lot of `last-...' variables, so a new variable
>> for the last selected window makes sense.  Then it would be
>> convenient to compare `(selected-window)' with `last-selected-
>> window'.
>
> Please do.

There are still open questions about this new variable, e.g.:
what should be recorded in `last-selected-window' in case of
`C-x 0' (`delete-window') when the last window is deleted?

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

[martin rudalics]

 > There are still open questions about this new variable, e.g.:
 > what should be recorded in `last-selected-window' in case of
 > `C-x 0' (`delete-window') when the last window is deleted?

You mean when the window referenced by `last-selected-window' is
deleted?  The one returned by (get-mru-window t t t) I presume.  In any
case `window-use-time' allows to order all windows by the time when they
were selected.

martin

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

[Drew Adams]

> > And maybe print the point values too, unless they're the same
> > buffer?
> >
> > Different, A: 2349, B: 1358
> > Same: A: 2349, B: 1358
> > No match
> 
> Or the size of the region of difference or sameness.

Maybe.  Or both:

Diff: 623 chars, A: 2349, B: 1358
Same: 623 chars, A: 2349, B: 1358
No match

> > Dunno what the names might be.  They could be the buffer names
> > (possibly truncated, if long), if different.
> 
> There is no displayable information associated with windows
> other than buffer names.

Yes, but names can be assigned.  In this case, only two names
are needed.  Just as for Ediff, we could use A & B, e.g., A
for the selected window.

> >> We already have a lot of `last-...' variables, so a new variable
> >> for the last selected window makes sense.  Then it would be
> >> convenient to compare `(selected-window)' with `last-selected-
> >> window'.
> 
> There are still open questions about this new variable, e.g.:
> what should be recorded in `last-selected-window' in case of
> `C-x 0' (`delete-window') when the last window is deleted?

Pick one.  The (newly) selected window, for example.  Or reset
it to nil or whatever (i.e., none).  Selected window makes
sense, I think.

Unless we are going to record a whole history, as for buffers,
we cannot set it to the previous "last".  Imagine five `C-x 0'
in a row.

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

[Drew Adams]

>  > There are still open questions about this new variable, e.g.:
>  > what should be recorded in `last-selected-window' in case of
>  > `C-x 0' (`delete-window') when the last window is deleted?
> 
> You mean when the window referenced by `last-selected-window' is
> deleted?  The one returned by (get-mru-window t t t) I presume.  In
> any case `window-use-time' allows to order all windows by the time
> when they were selected.

That (too) sounds good.  But maybe (get-mru-window 0 t t) is better.
Or (get-mru-window 'visible t t).  I'm not that familiar with use
of frames in terminal mode, so it's not clear to me what the
restriction of these to "the current terminal" entails.  That
restriction is not mentioned in regard to an ALL-FRAMES value of `t'.

I wasn't aware of (or forgot about) `window-use-time'.

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

[Juri Linkov]

> You mean when the window referenced by `last-selected-window' is
> deleted?  The one returned by (get-mru-window t t t) I presume.  In any
> case `window-use-time' allows to order all windows by the time when they
> were selected.

Thank you, Martin.  This is exactly what we need.

diff --git a/lisp/vc/compare-w.el b/lisp/vc/compare-w.el
index 25d4cf7..8e5cf11 100644
--- a/lisp/vc/compare-w.el
+++ b/lisp/vc/compare-w.el
@@ -140,9 +140,37 @@ out all highlighting later with the command `compare-windows-dehighlight'."
 (defvar compare-windows-overlays2 nil)
 (defvar compare-windows-sync-point nil)
 
+(defcustom compare-windows-get-window-function 'compare-windows-get-recent-window
+  "Function that provides the window to compare with."
+  :type '(choice
+	  (function-item :tag "Most recently used window"
+			 compare-windows-get-recent-window)
+	  (function-item :tag "Next window"
+			 compare-windows-get-next-window)
+	  (function :tag "Your function"))
+  :group 'compare-windows
+  :version "25.0")
+
+(defun compare-windows-get-recent-window ()
+  (let ((w2 (get-mru-window 'visible t t)))
+    (if (eq w2 (selected-window))
+	(error "No other window"))
+    w2))
+
+(defun compare-windows-get-next-window ()
+  (let ((w2 (next-window)))
+    (if (eq w2 (selected-window))
+	(setq w2 (next-window (selected-window) nil 'visible)))
+    (if (eq w2 (selected-window))
+	(error "No other window"))
+    w2))
+
 ;;;###autoload
 (defun compare-windows (ignore-whitespace)
-  "Compare text in current window with text in next window.
+  "Compare text in current window with text in another window.
+The option `compare-windows-get-window-function' defines how
+to get another window.
+
 Compares the text starting at point in each window,
 moving over text in each one as far as they match.
 
@@ -179,11 +207,7 @@ on third call it again advances points to the next difference and so on."
                            'compare-windows-sync-regexp
                          compare-windows-sync)))
     (setq p1 (point) b1 (current-buffer))
-    (setq w2 (next-window))
-    (if (eq w2 (selected-window))
-	(setq w2 (next-window (selected-window) nil 'visible)))
-    (if (eq w2 (selected-window))
-	(error "No other window"))
+    (setq w2 (funcall compare-windows-get-window-function))
     (setq p2 (window-point w2)
 	  b2 (window-buffer w2))
     (setq opoint2 p2)
@@ -255,12 +279,15 @@ on third call it again advances points to the next difference and so on."
             (recenter (car compare-windows-recenter))
             (with-selected-window w2 (recenter (cadr compare-windows-recenter))))
           ;; If points are still not synchronized, then ding
-          (when (and (= p1 opoint1) (= p2 opoint2))
-            ;; Display error message when current points in two windows
-            ;; are unmatched and next matching points can't be found.
-            (compare-windows-dehighlight)
-            (ding)
-            (message "No more matching points"))))))
+          (if (and (= p1 opoint1) (= p2 opoint2))
+	      (progn
+		;; Display error message when current points in two windows
+		;; are unmatched and next matching points can't be found.
+		(compare-windows-dehighlight)
+		(ding)
+		(message "No more matching points with %s" b2))
+	    (message "Match with %s" b2)))
+      (message "Difference with %s" b2))))
 
 ;; Move forward over whatever might be called whitespace.
 ;; compare-windows-whitespace is a regexp that matches whitespace.
@@ -303,7 +330,7 @@ on third call it again advances points to the next difference and so on."
 (defun compare-windows-sync-default-function ()
   (if (not compare-windows-sync-point)
       (let* ((w1 (selected-window))
-             (w2 (next-window w1))
+             (w2 (funcall compare-windows-get-window-function))
              (b2 (window-buffer w2))
              (point-max2 (with-current-buffer b2 (point-max)))
              (op2 (window-point w2))

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

[Drew Adams]

> Thank you, Martin.  This is exactly what we need.

Looks good to me.  Please apply it.  But "matching points"
should be "match positions" - "point" can be confusing.

Possible enhancements, but not required to close this
enhancement request:

1. I do still think it would be good to provide more info
   in the message.

2. As I proposed in the past, I think it would be good to
   (as I do) bind comparison commands to the same prefix.
   I bind them to prefix `C-=' (just one possibility):

   C-= b  is ediff-buffers
   C-= d  is diff
   C-= e  is ediff-files
   C-= f  is ediff-files
   C-= w  is compare-windows-repeat

3. `compare-windows-repeat' is just a repeatable version
   of `compare-windows', so you can repeat it using, for
   example, `C-= w w w w w'.  Very handy, especially
   given the improvements you've just made.

Maybe consider doing #3 even if you don't want to do #2.
I use the definition below, but you can do it another way
(e.g., using `set-transient-map').

I use this helper function all the time.  It makes it
trivial to make a repeatable command:

(defun repeat-command (command)
    "Repeat COMMAND."
    (let ((repeat-message-function  'ignore))
      (setq last-repeatable-command  command)
      (repeat nil)))

So for example:

(defun compare-windows-repeat (ignore-whitespace)
  "Compare text in current window with text in next window.
You can repeat this by hitting the last key again...
See `compare-windows' - this is the same, except repeatable."
  (interactive "P")
  (require 'repeat)
  (repeat-command 'compare-windows))

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

[Juri Linkov]

> Looks good to me.  Please apply it.  But "matching points"
> should be "match positions" - "point" can be confusing.

Wouldn't a shorter phrase be valid too: "No more matches"?

> Possible enhancements, but not required to close this
> enhancement request:
>
> 1. I do still think it would be good to provide more info
>    in the message.

All extra info is easy to get using standard commands:

a) point values are easy to get with `C-x ='
b) the previous point with `C-x C-x'
c) the size of the skipped region with `M-='

The only info that is not obvious is the name of another
window compared with the selected window.

> 2. As I proposed in the past, I think it would be good to
>    (as I do) bind comparison commands to the same prefix.
>    I bind them to prefix `C-=' (just one possibility):
>
>    C-= b  is ediff-buffers
>    C-= d  is diff
>    C-= e  is ediff-files
>    C-= f  is ediff-files
>    C-= w  is compare-windows-repeat
>
> 3. `compare-windows-repeat' is just a repeatable version
>    of `compare-windows', so you can repeat it using, for
>    example, `C-= w w w w w'.  Very handy, especially
>    given the improvements you've just made.

Binding `compare-windows' to a single key `C-=' makes it easy
to repeat in a long sequence of its invocations :)

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

[Drew Adams]

> > Looks good to me.  Please apply it.  But "matching points"
> > should be "match positions" - "point" can be confusing.
> 
> Wouldn't a shorter phrase be valid too: "No more matches"?

Sure, for that case.

> > Possible enhancements, but not required to close this
> > enhancement request:
> >
> > 1. I do still think it would be good to provide more info
> >    in the message.
> 
> All extra info is easy to get using standard commands:
> 
> a) point values are easy to get with `C-x ='
> b) the previous point with `C-x C-x'
> c) the size of the skipped region with `M-='

Not for both windows/buffers, not without moving between them.

Think about `diff' output, for instance.  Sometimes it can
be helpful to see the point or line numbers.  Admittedly, it's
not essential.  Whatever info we show should be because we
want to show the two together, for comparison.

> The only info that is not obvious is the name of another
> window compared with the selected window.

I don't agree - see previous.  But I don't feel strongly about it.

> > 2. As I proposed in the past, I think it would be good to
> >    (as I do) bind comparison commands to the same prefix.
> >    I bind them to prefix `C-=' (just one possibility):
> >
> >    C-= b  is ediff-buffers
> >    C-= d  is diff
> >    C-= e  is ediff-files
> >    C-= f  is ediff-files
> >    C-= w  is compare-windows-repeat
> >
> > 3. `compare-windows-repeat' is just a repeatable version
> >    of `compare-windows', so you can repeat it using, for
> >    example, `C-= w w w w w'.  Very handy, especially
> >    given the improvements you've just made.
> 
> Binding `compare-windows' to a single key `C-=' makes it easy
> to repeat in a long sequence of its invocations :)

Sure, but why not put comparison commands on the same, mnemonic
prefix key?  If you forget a particular comparison command
binding, `C-= C-h' will tell you.

And as soon as you put `compare-windows' on a prefix key you
cannot use it repeatedly, the way it is currently defined.

Operations that one might want to use repeatedly (e.g. because
they perform an incremental operation) should, in general, be
repeatable from a prefix key too, IMO.

But this is not part of this particular enhancement request.

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

[Juri Linkov]

> Think about `diff' output, for instance.

Thanks for the comparison with `diff' output.  I installed the patch
that adds a message similar to `diff' output, e.g.:

  Diff -7069,7233 +8280,8323 with compare-w.el