GNU bug report logs - #1077
23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil)

Previous Next

Package: emacs;

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

Date: Fri, 3 Oct 2008 17:30:02 UTC

Severity: normal

Tags: moreinfo

Merged with 670

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 1077 <at> debbugs.gnu.org, drew.adams <at> oracle.com
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 <rudalics <at> gmx.at>
> CC: Drew Adams <drew.adams <at> oracle.com>, 1077 <at> debbugs.gnu.org
> 
>  > 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
frame-parameter?

> 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
bug?

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




This bug report was last modified 14 years and 226 days ago.

Previous Next


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