[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker

From: Eli Zaretskii
Subject: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil)
Date: Mon, 29 Nov 2010 20:58:22 +0200

> Date: Mon, 29 Nov 2010 11:56:09 +0100
> From: martin rudalics <address@hidden>
> CC: Drew Adams <address@hidden>, address@hidden
>  > And it's a different frame from what we saw in Fx_create_frame, observe:
>  > [...]
>  > But down below, in frame #3, where `(frame-parameter nil 'menu-bar-lines)'
>  > is evaluated, it _will_ use selected_frame, right?  So what's going on
>  > here?  Any ideas are welcome.
> Do you mean the selected frame changes in between?

No.  We are in the middle of creating a new frame, remember?  The
frame that we are creating is not constructed yet, so it cannot yet
become the selected_frame.  It will become that later.  The currently
selected frame is still the minibuffer frame:

 (gdb) p selected_frame
 $9 = 49998341
 (gdb) xframe
 $10 = (struct frame *) 0x2faea00
 "Emacs Minibuffer"

The problem is that the offending menu item accesses the currently
selected frame's parameters:

 (define-key menu-bar-showhide-menu [menu-bar-mode]
    `(menu-item ,(purecopy "Menu-bar") toggle-menu-bar-mode-from-frame
               :help ,(purecopy "Turn menu-bar on/off")
               :button (:toggle . (> (frame-parameter nil 'menu-bar-lines) 0))))

The frame we are creating is not yet ready, and is certainly not yet
the selected frame!  Isn't that a bug? shouldn't we use
menu-updating-frame instead of nil, in the above call to

> Anyway, I think there are at least three other bugs:
> (1) Evaluating Lisp code in `define-key' can crash Emacs.

Sorry, I don't follow: are you saying that we must not evaluate Lisp
code inside `define-key', or are you saying something else?

> (2) The menu-bar define-key operations to toggle `menu-bar-mode' and
>      `tool-bar-mode' do not take into account that the values of the
>      respective frame parameter can be nil.

As you see above, this happens for the minibuffer frame.  Can you
explain how we get `(menu-bar-lines)' instead of having the usual
`(menu-bar-lines . 1)' or `(menu-bar-lines . 0)' in the parameters
alist of the minibuffer frame?  Is that normal, or is that another

> (3) Frame parameters of `menu-bar-lines' and actual appearance of a
>      menubar are inconsistent for minibuffer-only frames.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]