From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 1077@debbugs.gnu.org
Subject: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil)
Date: Mon, 29 Nov 2010 21:14:27 +0100 [thread overview]
Message-ID: <4CF409A3.1030906@gmx.at> (raw)
In-Reply-To: <8362vg9ctt.fsf@gnu.org>
> 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?
I think so. Hopefully `menu-updating-frame' has the correct parameters
in place.
> Sorry, I don't follow: are you saying that we must not evaluate Lisp
> code inside `define-key', or are you saying something else?
I thought about wrapping the Lisp code so that the call fails more
gracefully. Crashing seems a bit too harsh to me, at least for such
a trivial reason.
>> (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?
IIRC it's somewhere documented that `menu-bar-lines' and
`tool-bar-lines' can be nil. And a user can always remove a parameter
completely so any frame parameter can be nil.
>> (3) Frame parameters of `menu-bar-lines' and actual appearance of a
>> menubar are inconsistent for minibuffer-only frames.
Though unrelated this strikes me as the strangest bug of them all. It
means that we can't rely on the actual value of a frame parameter even
if it's non-nil.
martin
next prev parent reply other threads:[~2010-11-29 20:14 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-03 17:22 bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil) Drew Adams
2008-10-04 16:38 ` Drew Adams
2008-11-22 16:46 ` bug#670: " Drew Adams
2009-10-06 16:19 ` Drew Adams
2010-11-27 2:52 ` Drew Adams
2010-11-27 8:22 ` bug#1077: " Eli Zaretskii
2010-11-27 16:15 ` Drew Adams
2010-11-27 20:10 ` Eli Zaretskii
2010-11-27 23:32 ` Drew Adams
2010-11-28 7:21 ` Eli Zaretskii
2010-11-28 9:50 ` martin rudalics
2010-11-28 13:41 ` Eli Zaretskii
2010-11-28 14:12 ` martin rudalics
2010-11-28 17:29 ` Drew Adams
2010-11-28 17:26 ` Drew Adams
2010-11-28 17:50 ` Eli Zaretskii
2010-11-28 18:42 ` Drew Adams
2010-11-28 19:54 ` Eli Zaretskii
2010-11-28 22:38 ` Drew Adams
2010-11-28 20:43 ` Stefan Monnier
2010-11-28 19:40 ` Eli Zaretskii
2010-11-28 19:46 ` Drew Adams
2010-11-28 20:23 ` Eli Zaretskii
2010-11-29 10:56 ` martin rudalics
2010-11-29 18:58 ` Eli Zaretskii
2010-11-29 20:14 ` martin rudalics [this message]
2010-11-29 21:18 ` Eli Zaretskii
2010-11-29 21:33 ` Drew Adams
2010-11-30 4:05 ` Eli Zaretskii
2010-11-30 7:56 ` martin rudalics
2010-11-30 11:23 ` Eli Zaretskii
2010-11-30 14:01 ` martin rudalics
2010-11-30 15:11 ` Eli Zaretskii
2010-11-30 15:56 ` Drew Adams
2010-11-30 17:07 ` martin rudalics
2010-11-30 17:57 ` Drew Adams
2010-11-30 19:49 ` martin rudalics
2010-11-30 20:16 ` Drew Adams
2010-11-30 18:20 ` Eli Zaretskii
2010-11-30 18:16 ` Eli Zaretskii
2010-11-30 19:16 ` Drew Adams
2010-11-30 17:05 ` martin rudalics
2010-11-30 17:57 ` Drew Adams
2010-11-30 18:27 ` Eli Zaretskii
2010-11-30 19:50 ` martin rudalics
2010-11-30 20:18 ` Drew Adams
2010-12-01 9:58 ` martin rudalics
2010-12-01 15:13 ` Drew Adams
2010-12-01 17:28 ` martin rudalics
2010-12-01 18:19 ` Drew Adams
2010-11-30 19:49 ` martin rudalics
2010-11-30 20:17 ` Drew Adams
2010-11-30 18:18 ` Eli Zaretskii
2010-12-01 9:58 ` martin rudalics
2010-12-01 17:21 ` Eli Zaretskii
2010-12-01 15:05 ` Lennart Borgman
2010-11-30 11:42 ` Eli Zaretskii
2010-11-30 15:42 ` Drew Adams
2010-11-30 18:12 ` Eli Zaretskii
2010-11-30 19:16 ` Drew Adams
2010-12-09 19:11 ` Eli Zaretskii
2010-12-01 15:48 ` Stefan Monnier
2010-12-01 17:27 ` martin rudalics
2010-11-30 20:21 ` Drew Adams
2010-11-30 21:28 ` 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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CF409A3.1030906@gmx.at \
--to=rudalics@gmx.at \
--cc=1077@debbugs.gnu.org \
--cc=eliz@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).