bug#34715: 26.1; (1) Add `clone-frame', (2) bind it to `C-x 5 2'

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

> > 2. Use it, not `make-frame-command', as the binding of `C-x 5 2'.
> 
> I'm okay with adding a new command, but rebinding "C-x 5 2" by default
> at the same time is a non-starter.  We should first let people use the
> new command, and should see how many of them ask to change the default
> binding.

Juri suggested binding `clone-frame' to `C-x 5 c'.
That's OK too.

I suggested in my second mail that the use of a
prefix arg could be flipped, so this would then
become a redefinition of `make-frame-command',
where a prefix arg causes cloning instead of
being a no-op (just creating a frame using
`default-frame-alist').

So that's another possibility, which is
backward-compatible (except that a prefix arg
would no longer be a no-op, as it is now).

I personally think the cloning case is more useful
than the make-a-default-frame case.

If `make-frame-command' were updated to just let a
prefix arg clone the selected frame then cloning
would be less discoverable than if the name were
`clone-frame'.

> >    Why change the default behavior of `C-x 5 2'?  If I want the
> >    buffer of the selected window shown in another frame then I
> >    typically want that frame to have the same parameters.
> 
> That's what default-frame-alist is for.

I already have what I need for my own use.  Here
I'm proposing something for Emacs - that's the
point of this enhancement.

> If you are used to change the
> parameters of your frames a lot during their lifetime, which
> presumably means each of your frames might look and work differently,
> it is not entirely clear to me that "C-x 5 2" should produce a clone
> of the random frame where you just happened to type the command.

Sorry, I don't understand your point there.

I don't just "happen to type the command" in "random
frames".  I hit its key (`C-x 5 2', for me) with a
frame selected that I want to clone.

If a frame for some reason has particular, unusual
parameters (e.g., user-defined or from some library)
then presumably a user of such a frame would be
used to its special behavior (even if s?he were
unaware of the particular frame parameters) and
would be able to decide whether cloning it is useful.

> It could even cause trouble/unexpected behavior,
> with some exotic parameters, at least in principle.

I don't see that either.  Could you give an example?
If I want to clone a frame then I want to clone that
frame.  If I don't then I don't.  Cloning includes
copying the frame parameters.

If there were a situation where it would be
problematic to copy some frame parameter then
presumably a user wouldn't ask to clone that frame.
Sure, someone could accidentally invoke the command.
But I don't see the expected unexpected harm.

And if there really were a problem then we could
add a blacklist variable or a predicate that one
could use to inhibit cloning in such a situation.

In sum, unless there is some good reason here to
fear trouble/unexpected behavior I don't see why
this enhancement is different from others.

Sure, something unexpected is always possible.
But without some real expectation of a particular
problem we should just discover it in practice
and take care of it.
 
> So I think we definitely should collect more
> experience before changing this veteran binding.

In that case I'd vote for Juri's suggestion (use
`C-x 5 c', not `C-x 5 2'), as just making cloning
available via a prefix arg for `C-x 5 2' would
make it less discoverable.

It would also be possible to do both: bind
`clone-frame' to `C-x 5 c' and let a prefix arg
to `C-x 5 2' (as `make-frame-command') invoke
`clone-frame'.

> > 3. BTW, I think it would be good to add this to the doc string of
> >    `make-frame-command':
> >
> >    Return the new frame.
> 
> "When called from Lisp, return the new frame."

It returns the frame no matter how it's called.
And only someone interested in calling it from
Lisp is interested in the return value.  But
sure, go for it, if you think it adds something.