GNU bug report logs - #32736
26; Bind `C-x 5 2' to `clone-frame' by default

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Fri, 14 Sep 2018 16:34:02 UTC

Severity: wishlist

Merged with 34715

Found in version 26.1

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32736 in the body.
You can then email your comments to 32736 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Fri, 14 Sep 2018 16:34:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Drew Adams <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Fri, 14 Sep 2018 16:34:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26; Bind `C-x 5 2' to `clone-frame' by default
Date: Fri, 14 Sep 2018 09:32:42 -0700 (PDT)
Possible enhancement: Change default binding of `C-x 5 2' to
`clone-frame'.  Unlike `make-frame-command', `clone-frame' would use the
same frame-parameter values as the selected frame.  Here's a possible
definition of `clone-frame':

(defun clone-frame (&optional frame)
  "Make a new frame with the same parameters as 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)
  (let* ((default-frame-alist  (frame-parameters frame))
         (new-fr  (make-frame)))
    (unless (display-graphic-p) (select-frame new-fr))))

In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32)
 of 2018-05-30
Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea
Windowing system distributor `Microsoft Corp.', version 10.0.16299
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Fri, 14 Sep 2018 18:59:02 GMT) Full text and rfc822 format available.

Message #8 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 32736 <at> debbugs.gnu.org
Subject: Re: bug#32736: 26; Bind `C-x 5 2' to `clone-frame' by default
Date: Fri, 14 Sep 2018 20:57:54 +0200
Drew Adams <drew.adams <at> oracle.com> writes:

> Possible enhancement: Change default binding of `C-x 5 2' to
> `clone-frame'.  Unlike `make-frame-command', `clone-frame' would use the
> same frame-parameter values as the selected frame.  Here's a possible
> definition of `clone-frame':

Hmm, how common is it to have a frame that doesnʼt have the same frame
parameters as 'default-frame-alist', and you want to replicate them?
Personally I quite like the current behaviour.

> (defun clone-frame (&optional frame)
>   "Make a new frame with the same parameters as 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)
>   (let* ((default-frame-alist  (frame-parameters frame))
>          (new-fr  (make-frame)))
>     (unless (display-graphic-p) (select-frame new-fr))))

How about you make it take a prefix argument to get back
'make-frame-command' semantics (or keep the current ones, and add
'clone-frame' semantics to the prefix arg)?

Robert




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Fri, 14 Sep 2018 19:37:01 GMT) Full text and rfc822 format available.

Message #11 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 32736 <at> debbugs.gnu.org
Subject: RE: bug#32736: 26; Bind `C-x 5 2' to `clone-frame' by default
Date: Fri, 14 Sep 2018 12:35:58 -0700 (PDT)
> > Possible enhancement: Change default binding of `C-x 5 2' to
> > `clone-frame'.  Unlike `make-frame-command', `clone-frame' would use the
> > same frame-parameter values as the selected frame.  Here's a possible
> > definition of `clone-frame':
> 
> Hmm, how common is it to have a frame that doesnʼt have the same frame
> parameters as 'default-frame-alist', and you want to replicate them?
> Personally I quite like the current behaviour.

It's definitely the case for me. I use several kinds of special-display frames. If I use it on a *Help* frame get a *Help* frame (same background etc.). If I use it on an *info* frame I get an *info* frame, and so on.

If it's not the case for you then you should get pretty much the same behavior as now. I don't think you'll notice a difference.

> How about you make it take a prefix argument to get back
> 'make-frame-command' semantics (or keep the current ones, and add
> 'clone-frame' semantics to the prefix arg)?

Fair enough.

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

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* ((default-frame-alist  (frame-parameters frame))
           (new-fr  (make-frame)))
      (unless (if (fboundp 'display-graphic-p) (display-graphic-p) window-system)
        (select-frame new-fr)))))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Sat, 15 Sep 2018 00:23:01 GMT) Full text and rfc822 format available.

Message #14 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Robert Pluim <rpluim <at> gmail.com>, Drew Adams <drew.adams <at> oracle.com>
Cc: 32736 <at> debbugs.gnu.org
Subject: Re: bug#32736: 26; Bind `C-x 5 2' to `clone-frame' by default
Date: Sat, 15 Sep 2018 12:22:42 +1200
On 15/09/18 06:57, Robert Pluim wrote:
> How about you make it take a prefix argument to get back
> 'make-frame-command' semantics (or keep the current ones, and add
> 'clone-frame' semantics to the prefix arg)?

I don't have an opinion on which behaviour should be the default,
but I like the idea of adding such prefix argument behaviour to the
C-x 5 2 binding so that users can choose between the two, so +1 to
that idea in general.

-Phil




Merged 32736 34715. Request was from Noam Postavsky <npostavs <at> gmail.com> to control <at> debbugs.gnu.org. (Sun, 03 Mar 2019 12:53:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Wed, 01 Sep 2021 09:44:01 GMT) Full text and rfc822 format available.

Message #19 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org
Subject: Re: bug#32736: 26; Bind `C-x 5 2' to `clone-frame' by default
Date: Wed, 01 Sep 2021 11:43:34 +0200
Drew Adams <drew.adams <at> oracle.com> writes:

> 1. Add a `clone-frame' command such as this one, which is similar to
>    what I've been using:
>
> (defun clone-frame (&optional frame no-clone)

I've now added this to Emacs 28 (with some trivial changes) -- bound to
`C-x 5 c'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug marked as fixed in version 28.1, send any further explanations to 32736 <at> debbugs.gnu.org and Drew Adams <drew.adams <at> oracle.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 01 Sep 2021 09:45:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Wed, 01 Sep 2021 12:49:02 GMT) Full text and rfc822 format available.

Message #24 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#34715: bug#32736: 26;
 Bind `C-x 5 2' to `clone-frame' by default
Date: Wed, 01 Sep 2021 15:47:42 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Wed, 01 Sep 2021 11:43:34 +0200
> Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org
> 
> Drew Adams <drew.adams <at> oracle.com> writes:
> 
> > 1. Add a `clone-frame' command such as this one, which is similar to
> >    what I've been using:
> >
> > (defun clone-frame (&optional frame no-clone)
> 
> I've now added this to Emacs 28 (with some trivial changes) -- bound to
> `C-x 5 c'.

Did you try that command in a -nw session?  It has some bug with
faces.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Wed, 01 Sep 2021 12:54:01 GMT) Full text and rfc822 format available.

Message #27 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#34715: bug#32736: 26; Bind `C-x 5 2' to `clone-frame' by
 default
Date: Wed, 01 Sep 2021 14:53:05 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

> Did you try that command in a -nw session?  It has some bug with
> faces.

Nope; didn't try it with -nw, but I see the problem.  Any idea what's
causing that?

Here's frame-parameters in the initial frame:

((buried-buffer-list)
 (buffer-list #<buffer *scratch*> #<buffer  *Minibuf-1*>)
 (name . "F1")
 (tab-bar-lines . 0)
 (menu-bar-lines . 1)
 (unsplittable)
 (modeline . t)
 (width . 80)
 (height . 23)
 (font . "tty")
 (background-color . "unspecified-bg")
 (foreground-color . "unspecified-fg")
 (scroll-bar-foreground . "white")
 (cursor-color . "white")
 (background-mode . dark)
 (display-type . color)
 (tty . "/dev/tty")
 (tty-type . "xterm-256color")
 (minibuffer . t))

And here's the one after C-x 5 c:

((tab-bar-lines . 0)
 (menu-bar-lines . 1)
 (buried-buffer-list #<buffer *Completions*>)
 (buffer-list #<buffer *scratch*> #<buffer  *Minibuf-1*>)
 (unsplittable)
 (modeline . t)
 (width . 80)
 (height . 23)
 (font . "tty")
 (background-color . "unspecified-bg")
 (foreground-color . "unspecified-fg")
 (name . "F2")
 (minibuffer . t))



-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Wed, 01 Sep 2021 13:40:02 GMT) Full text and rfc822 format available.

Message #30 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#34715: bug#32736: 26; Bind `C-x 5 2' to `clone-frame' by
 default
Date: Wed, 01 Sep 2021 16:38:43 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: drew.adams <at> oracle.com,  34715 <at> debbugs.gnu.org,  32736 <at> debbugs.gnu.org
> Date: Wed, 01 Sep 2021 14:53:05 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Did you try that command in a -nw session?  It has some bug with
> > faces.
> 
> Nope; didn't try it with -nw, but I see the problem.  Any idea what's
> causing that?

There are error messages in *Messages* that could give a clue; did you
see them?  (No, I didn't yet think about that more than 3 sec, so have
no ideas yet.)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Wed, 01 Sep 2021 13:41:01 GMT) Full text and rfc822 format available.

Message #33 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#34715: bug#32736: 26; Bind `C-x 5 2' to `clone-frame' by
 default
Date: Wed, 01 Sep 2021 15:40:26 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

> There are error messages in *Messages* that could give a clue; did you
> see them?  (No, I didn't yet think about that more than 3 sec, so have
> no ideas yet.)

Ah, didn't notice the messages:

Invalid face reference: font-lock-comment-delimiter-face
Invalid face reference: font-lock-comment-face
Invalid face reference: font-lock-comment-delimiter-face
Invalid face reference: font-lock-comment-face
Invalid face reference: font-lock-comment-delimiter-face
Invalid face reference: font-lock-comment-face
Invalid face reference: font-lock-comment-delimiter-face
Invalid face reference: font-lock-comment-face
Invalid face reference: mode-line-buffer-id
Invalid face reference: minibuffer-prompt [7 times]
Invalid face reference: mode-line-buffer-id [2 times]

So basically all the fonts are gone?  Well, that's a clue; I'll try to
debug...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Wed, 01 Sep 2021 13:43:01 GMT) Full text and rfc822 format available.

Message #36 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org
Subject: Re: bug#32736: bug#34715: bug#32736: 26; Bind `C-x 5 2' to
 `clone-frame' by default
Date: Wed, 01 Sep 2021 15:41:54 +0200
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> So basically all the fonts are gone?  Well, that's a clue; I'll try to
> debug...

(I mean faces.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Wed, 01 Sep 2021 13:56:02 GMT) Full text and rfc822 format available.

Message #39 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org
Subject: Re: bug#32736: bug#34715: bug#32736: 26; Bind `C-x 5 2' to
 `clone-frame' by default
Date: Wed, 01 Sep 2021 15:55:29 +0200
If I filter out the `name' and `background-color' elements, then it
works.  I can kinda see the first one, but...

Hm...  no, it's `background-color' in combination with something else;
just background-color works fine.

I wonder whether this is points to a bug somewhere in the tty frame
mechanism...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Wed, 01 Sep 2021 14:12:02 GMT) Full text and rfc822 format available.

Message #42 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org
Subject: Re: bug#32736: bug#34715: bug#32736: 26; Bind `C-x 5 2' to
 `clone-frame' by default
Date: Wed, 01 Sep 2021 17:11:08 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 34715 <at> debbugs.gnu.org,  32736 <at> debbugs.gnu.org
> Date: Wed, 01 Sep 2021 15:55:29 +0200
> 
> If I filter out the `name' and `background-color' elements, then it
> works.  I can kinda see the first one, but...
> 
> Hm...  no, it's `background-color' in combination with something else;
> just background-color works fine.
> 
> I wonder whether this is points to a bug somewhere in the tty frame
> mechanism...

If the problem is background-color, why does redisplay complain about
faces saying they are *invalid*?  I could understand if it said it
cannot load some color, but why "invalid face"?

The only funky thing about background-color on TTY I can think of is
the unspecified-bg thingy.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Wed, 01 Sep 2021 14:19:01 GMT) Full text and rfc822 format available.

Message #45 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org
Subject: Re: bug#32736: bug#34715: bug#32736: 26; Bind `C-x 5 2' to
 `clone-frame' by default
Date: Wed, 01 Sep 2021 16:18:13 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

> If the problem is background-color, why does redisplay complain about
> faces saying they are *invalid*?  I could understand if it said it
> cannot load some color, but why "invalid face"?
>
> The only funky thing about background-color on TTY I can think of is
> the unspecified-bg thingy.

The following is the minimal case for reproduction here:

(let ((default-frame-alist
        '((background-color . "red"))))
  (make-frame))

This reliably makes all the faces go AWOL on the new frame.  (It doesn't
matter what the colour is.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Wed, 01 Sep 2021 14:29:01 GMT) Full text and rfc822 format available.

Message #48 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org
Subject: Re: bug#32736: bug#34715: bug#32736: 26; Bind `C-x 5 2' to
 `clone-frame' by default
Date: Wed, 01 Sep 2021 16:28:23 +0200
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> (let ((default-frame-alist
>         '((background-color . "red"))))
>   (make-frame))
>
> This reliably makes all the faces go AWOL on the new frame.  (It doesn't
> matter what the colour is.)

And it is indeed the problem.  If I remove this:

	  if (EQ (prop, Qforeground_color)
	      || EQ (prop, Qbackground_color))
	    update_face_from_frame_parameter (f, prop, val);

Then the faces aren't destroyed...  So the bug is in
update_face_from_frame_parameter somewhere, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Wed, 01 Sep 2021 15:58:02 GMT) Full text and rfc822 format available.

Message #51 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org
Subject: Re: bug#32736: bug#34715: bug#32736: 26; Bind `C-x 5 2' to
 `clone-frame' by default
Date: Wed, 01 Sep 2021 18:57:23 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 34715 <at> debbugs.gnu.org,  32736 <at> debbugs.gnu.org
> Date: Wed, 01 Sep 2021 16:18:13 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > If the problem is background-color, why does redisplay complain about
> > faces saying they are *invalid*?  I could understand if it said it
> > cannot load some color, but why "invalid face"?
> >
> > The only funky thing about background-color on TTY I can think of is
> > the unspecified-bg thingy.
> 
> The following is the minimal case for reproduction here:
> 
> (let ((default-frame-alist
>         '((background-color . "red"))))
>   (make-frame))
> 
> This reliably makes all the faces go AWOL on the new frame.  (It doesn't
> matter what the colour is.)

Shouldn't we copy the parameters alist?  Maybe even deep-copy?  And
faces are supposed to be frame-local, so maybe faces also need to be
copied?  Otherwise, you are basically manipulating faces that don't
"belong" to the frame, no?  And likewise with frame's parameters
alist, I think.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Thu, 02 Sep 2021 07:45:02 GMT) Full text and rfc822 format available.

Message #54 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org
Subject: Re: bug#32736: bug#34715: bug#32736: 26; Bind `C-x 5 2' to
 `clone-frame' by default
Date: Thu, 02 Sep 2021 09:44:24 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> The following is the minimal case for reproduction here:
>> 
>> (let ((default-frame-alist
>>         '((background-color . "red"))))
>>   (make-frame))
>> 
>> This reliably makes all the faces go AWOL on the new frame.  (It doesn't
>> matter what the colour is.)
>
> Shouldn't we copy the parameters alist?  Maybe even deep-copy?

Do you mean in this particular test case or in `clone-frame'?  If it's
the latter, the list we get is fresh (but not very deep).

If it's this particular test case, then I don't understand what you mean.

> And faces are supposed to be frame-local, so maybe faces also need to
> be copied?  Otherwise, you are basically manipulating faces that don't
> "belong" to the frame, no?  And likewise with frame's parameters
> alist, I think.

Anyway, debugging further shows that the problem seems to be in
`frame-set-background-mode', but I've yet to isolate what exactly is
triggering the bug.

	    (dolist (face (face-list))
	      (and (not (get face 'face-override-spec))
[...]

                         (face-spec-match-p face
                                            (face-user-default-spec face)
                                            frame)))
		   (push face locally-modified-faces)))
	    ;; Now change to the new frame parameters
	    (modify-frame-parameters frame params)
	    ;; For all unmodified named faces, choose face specs
	    ;; matching the new frame parameters.
	    (dolist (face (face-list))
	      (unless (memq face locally-modified-faces)
		(face-spec-recalc face frame)))))))))

The face-spec-recalc messes up the face...  but so does the call to
face-spec-match-p, apparently?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Thu, 02 Sep 2021 07:52:01 GMT) Full text and rfc822 format available.

Message #57 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org
Subject: Re: bug#32736: bug#34715: bug#32736: 26; Bind `C-x 5 2' to
 `clone-frame' by default
Date: Thu, 02 Sep 2021 10:51:18 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 34715 <at> debbugs.gnu.org,  32736 <at> debbugs.gnu.org
> Date: Thu, 02 Sep 2021 09:44:24 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Shouldn't we copy the parameters alist?  Maybe even deep-copy?
> 
> Do you mean in this particular test case or in `clone-frame'?  If it's
> the latter, the list we get is fresh (but not very deep).

You mean, we get a fresh list because of the call to seq-filter?
(Which btw means we now need to preload seq.el?)  Is that guaranteed
to return a copy of the original alist?

And the faces aren't copied, I think, they reference the same faces
the original frame had.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Thu, 02 Sep 2021 08:02:01 GMT) Full text and rfc822 format available.

Message #60 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org
Subject: Re: bug#32736: bug#34715: bug#32736: 26; Bind `C-x 5 2' to
 `clone-frame' by default
Date: Thu, 02 Sep 2021 10:01:27 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

> You mean, we get a fresh list because of the call to seq-filter?

No, because of this:

DEFUN ("frame-parameters", Fframe_parameters, Sframe_parameters, 0, 1, 0,
       doc: /* Return the parameters-alist of frame FRAME.

[...]
  alist = Fcopy_alist (f->param_alist);

> (Which btw means we now need to preload seq.el?)

No, it's autoloaded.

> And the faces aren't copied, I think, they reference the same faces
> the original frame had.

Right -- I don't really know how the face/frame stuff actually works.
If it was a very general problem, then surely we'd stumble across this
whenever we make a new frame.  But the bug seems to manifest only on
terminal frames -- when we change the background mode.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Thu, 02 Sep 2021 08:20:01 GMT) Full text and rfc822 format available.

Message #63 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org
Subject: Re: bug#32736: bug#34715: bug#32736: 26; Bind `C-x 5 2' to
 `clone-frame' by default
Date: Thu, 02 Sep 2021 11:19:34 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 34715 <at> debbugs.gnu.org,  32736 <at> debbugs.gnu.org
> Date: Thu, 02 Sep 2021 10:01:27 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > You mean, we get a fresh list because of the call to seq-filter?
> 
> No, because of this:
> 
> DEFUN ("frame-parameters", Fframe_parameters, Sframe_parameters, 0, 1, 0,
>        doc: /* Return the parameters-alist of frame FRAME.
> 
> [...]
>   alist = Fcopy_alist (f->param_alist);

Ah, right.

> > (Which btw means we now need to preload seq.el?)
> 
> No, it's autoloaded.

But frame.el is preloaded, so won't that get in the way during
bootstrap?

> > And the faces aren't copied, I think, they reference the same faces
> > the original frame had.
> 
> Right -- I don't really know how the face/frame stuff actually works.
> If it was a very general problem, then surely we'd stumble across this
> whenever we make a new frame.  But the bug seems to manifest only on
> terminal frames -- when we change the background mode.

That's true, but it doesn't mean we don't have a deeper problem.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Thu, 02 Sep 2021 08:58:02 GMT) Full text and rfc822 format available.

Message #66 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org
Subject: Re: bug#32736: bug#34715: bug#32736: 26; Bind `C-x 5 2' to
 `clone-frame' by default
Date: Thu, 02 Sep 2021 10:57:24 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> > (Which btw means we now need to preload seq.el?)
>> 
>> No, it's autoloaded.
>
> But frame.el is preloaded, so won't that get in the way during
> bootstrap?

It won't get loaded until the user uses the `C-x 5 c' command.

>> > And the faces aren't copied, I think, they reference the same faces
>> > the original frame had.
>> 
>> Right -- I don't really know how the face/frame stuff actually works.
>> If it was a very general problem, then surely we'd stumble across this
>> whenever we make a new frame.  But the bug seems to manifest only on
>> terminal frames -- when we change the background mode.
>
> That's true, but it doesn't mean we don't have a deeper problem.

True.  I'll continue to debug this, but won't have time today, I
think...  If you want to have a look meanwhile, please go ahead.  :-)
It reproduces easily, and the bug seems to be caused by something called
by `frame-set-background-mode', but that may or may not be correct
(perhaps it's just doing something that triggers the real problem caused
somewhere else).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Thu, 02 Sep 2021 12:05:02 GMT) Full text and rfc822 format available.

Message #69 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org
Subject: Re: bug#32736: bug#34715: bug#32736: 26; Bind `C-x 5 2' to
 `clone-frame' by default
Date: Thu, 02 Sep 2021 15:03:58 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 34715 <at> debbugs.gnu.org,  32736 <at> debbugs.gnu.org
> Date: Thu, 02 Sep 2021 10:57:24 +0200
> 
> >> > And the faces aren't copied, I think, they reference the same faces
> >> > the original frame had.
> >> 
> >> Right -- I don't really know how the face/frame stuff actually works.
> >> If it was a very general problem, then surely we'd stumble across this
> >> whenever we make a new frame.  But the bug seems to manifest only on
> >> terminal frames -- when we change the background mode.
> >
> > That's true, but it doesn't mean we don't have a deeper problem.
> 
> True.  I'll continue to debug this, but won't have time today, I
> think...  If you want to have a look meanwhile, please go ahead.  :-)
> It reproduces easily, and the bug seems to be caused by something called
> by `frame-set-background-mode', but that may or may not be correct
> (perhaps it's just doing something that triggers the real problem caused
> somewhere else).

I think I fixed this.  The problem was indeed with letting the new
frame manipulate a separate set of faces: we arrange for that in
make-terminal-frame, but we were doing that a tad too late.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#32736; Package emacs. (Thu, 02 Sep 2021 16:06:02 GMT) Full text and rfc822 format available.

Message #72 received at 32736 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34715 <at> debbugs.gnu.org, 32736 <at> debbugs.gnu.org
Subject: Re: bug#32736: bug#34715: bug#32736: 26; Bind `C-x 5 2' to
 `clone-frame' by default
Date: Thu, 02 Sep 2021 18:05:31 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

> I think I fixed this.  The problem was indeed with letting the new
> frame manipulate a separate set of faces: we arrange for that in
> make-terminal-frame, but we were doing that a tad too late.

Ah, I see!  And I can confirm that this fixes the problem here, too.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 01 Oct 2021 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 180 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.