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: emacs-devel@gnu.org
Subject: RE: master 57d2f24: * lisp/frame.el (make-frame-on-monitor): New command. (Bug#34516)
Date: Sun, 3 Mar 2019 16:01:32 -0800 (PST)	[thread overview]
Message-ID: <e67f135d-f55d-4c72-ae2e-c80bc5e769ec@default> (raw)
In-Reply-To: <87sgw3r98y.fsf@mail.linkov.net>

> > As an aside and FWIW, I think `C-x 5 2' should, by
> > default, make a new frame that is a clone of the
> > selected one (same parameters).  I proposed this in
> > bug #34715.
> 
> `clone-frame' would be a useful command since it will also
> maximize the cloned frame if the original was maximized.
> 
> But why rebind `C-x 5 2' to it?

Because I found I was pretty much always using
`make-frame-command' to open the current buffer
in another frame.  For my use it was thus kind of
a frame-duplication anyway, but without everything
about the frame getting duplicated.

See also below, for more "why". 

> Like the following existing key binding:
>   `C-x 4 c' - clone-indirect-buffer-other-window
> shouldn't the new command be bound to a similar key sequence:
>   `C-x 5 c' - clone-frame

Obviously such choices are judgment calls and subject
to opinion.

Normally I'd argue not to change the default behavior
(of `C-x 5 2'), for backward compatibility.  But in
this case I'd argue to change it, and keep the current
behavior on `C-u'.

But as I said, that's maybe partly because I typically
do not have multiple windows in a frame where I use
`C-x 5 2'.

To me it's natural to have a prefix arg change
between cloning and just doing `make-frame-command'.
Just which of those behaviors should be the default
behavior is a separate question.  I don't insist
that the default behavior must change.  But I do
think that the natural place for the clone behavior
is on `C-x 5 2', not `C-x 5 c'.

Yes, in some ways you can say this is similar to
`clone-indirect-buffer-other-window.  But it's not
really very similar.  It's not about indirect
buffers, and it's not about cloning a buffer.  It's
about showing a buffer in another place (frame).

FWIW, the code I actually use is a bit more involved,
as follows:

1. Cloning the frame to keep the same parameters,
particularly the same size, is handy.  But
giving the new frame the exact same position (as
well as size) puts it right on top of the frame
that's cloned.  I find it handier to position it
a bit offset.  That makes it more apparent that
the frame was cloned, and gives me instant access
to both frames.

Someone else might prefer the exactly-on-top
behavior.  Or someone might prefer a different
offset amount or direction.  Or someone might
prefer to always use some particular set of
frame parameters for cloning.

2. The code I use always selects the new frame
(except when `C-u' is used, to just invoke
`make-frame-command').  I find that this is
what I want nearly always.  And this behavior
is what `clone-indirect-buffer-other-window'
does: you generally clone a frame to work in
it, I think; you don't want to keep working
in the original (cloned) frame.

Below is the code I actually use, FWIW.  (The
binding of `fit-frame-inhibit-fitting-flag'
has an effect only if someone is using my
`fit-frame.el' code - you can ignore it.)

The user option lets you choose a particular
set of frame parameters to use.  Or you can
choose an offset and otherwise keep the same
parameters as the current frame.  Or you can
choose nil or zero offsets, to get exactly
the same frame parameters.

------8<------------

(defcustom clone-frame-parameters (cons 30 30)
  "Frame parameter settings that override those of the frame to clone.
The value can be an alist of frame parameters or a cons of two
integers, (LEFT-OFFSET . TOP-OFFSET).

The latter case sets parameters `left' and `top' of the new frame to
the `left' and `top' of the selected frame, offset by adding
LEFT-OFFSET and TOP-OFFSET to them, respectively."
  :type '(choice
          (cons :tag "Offset from current frame location"
                (integer :tag "Left")
                (integer :tag "Top"))
          (alist :tag "Parameters to augment/replace those of current frame"
                 :key-type (symbol :tag "Parameter")))
  :group 'Frame-Commands)

(defun clone-frame (&optional frame no-clone)
  "Make and select a new frame with the same parameters as FRAME.
With a prefix arg, don't clone - just call `make-frame-command'.
Return the new frame.

FRAME defaults to the selected frame.  The frame is created on the
same terminal as FRAME.  If the terminal is a text-only terminal then
also select the new frame."
  (interactive "i\nP")
  (if no-clone
      (make-frame-command)
    (let* ((fit-frame-inhibit-fitting-flag  t)
           (clone-frame-parameters
            (if (and clone-frame-parameters
                     (not (consp (car clone-frame-parameters))))
                `((left
                   . ,(+ (car clone-frame-parameters)
                         (or (cdr (assq 'left
                                        (frame-parameters frame)))
                             0)))
                  (top
                   . ,(+ (cdr clone-frame-parameters)
                         (or (cdr (assq 'top
                                        (frame-parameters frame)))
                             0))))
              clone-frame-parameters))
           (default-frame-alist  (append clone-frame-parameters
                                         (frame-parameters frame)))
           (new-fr               (make-frame)))
      (select-frame new-fr)
      new-fr)))



  reply	other threads:[~2019-03-04  0:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190225211142.21954.14993@vcs0.savannah.gnu.org>
     [not found] ` <20190225211144.0DD23206A2@vcs0.savannah.gnu.org>
2019-02-26  9:12   ` master 57d2f24: * lisp/frame.el (make-frame-on-monitor): New command. (Bug#34516) Robert Pluim
2019-02-26 15:23     ` Eli Zaretskii
2019-02-27 20:59       ` Juri Linkov
2019-02-28  9:38         ` Robert Pluim
2019-02-28 16:52           ` Robert Pluim
2019-02-28 20:40             ` Juri Linkov
2019-03-01 13:40               ` Robert Pluim
2019-03-02 21:09                 ` Juri Linkov
2019-03-03  1:05                   ` Drew Adams
2019-03-03 21:30                     ` Juri Linkov
2019-03-04  0:01                       ` Drew Adams [this message]
2019-03-04  8:53                   ` Robert Pluim
2019-02-28 18:11         ` Eli Zaretskii

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=e67f135d-f55d-4c72-ae2e-c80bc5e769ec@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@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.