all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Juri Linkov <juri@linkov.net>
Cc: 19170@debbugs.gnu.org
Subject: bug#19170: 25.0.50; enhancement request: `compare-windows' use across frames
Date: Tue, 25 Nov 2014 15:40:19 -0800 (PST)	[thread overview]
Message-ID: <c3392ec2-e361-4607-8247-8e03bcb7091f@default> (raw)
In-Reply-To: <87egsqzy74.fsf@mail.linkov.net>

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





  reply	other threads:[~2014-11-25 23:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-24 19:24 bug#19170: 25.0.50; enhancement request: `compare-windows' use across frames Drew Adams
2014-11-24 22:19 ` Juri Linkov
2014-11-24 22:34   ` Drew Adams
2014-11-25  0:13     ` Drew Adams
2014-11-25  0:37     ` Juri Linkov
2014-11-25  4:09       ` Drew Adams
2014-11-25 21:39         ` Juri Linkov
2014-11-25 22:00           ` Drew Adams
2014-11-25 22:56             ` Juri Linkov
2014-11-25 23:40               ` Drew Adams [this message]
2014-11-27  0:57                 ` Juri Linkov
2014-11-27  3:18                   ` Drew Adams
2014-11-28  0:54                     ` Juri Linkov
2014-11-28  7:29                       ` martin rudalics
2014-11-28 15:31                         ` Drew Adams
2014-11-28 21:15                         ` Juri Linkov
2014-11-28 22:20                           ` Drew Adams
2014-11-29  0:50                             ` Juri Linkov
2014-11-29  1:53                               ` Drew Adams
2014-12-05  0:51                                 ` Juri Linkov
2014-11-28 15:25                       ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c3392ec2-e361-4607-8247-8e03bcb7091f@default \
    --to=drew.adams@oracle.com \
    --cc=19170@debbugs.gnu.org \
    --cc=juri@linkov.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.