unofficial mirror of bug-gnu-emacs@gnu.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 14:00:25 -0800 (PST)	[thread overview]
Message-ID: <c208aa30-cee6-4851-a599-6fea5c5a305a@default> (raw)
In-Reply-To: <87egsr0xjt.fsf@mail.linkov.net>

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





  reply	other threads:[~2014-11-25 22:00 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 [this message]
2014-11-25 22:56             ` Juri Linkov
2014-11-25 23:40               ` Drew Adams
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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=c208aa30-cee6-4851-a599-6fea5c5a305a@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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).