From: "Drew Adams" <drew.adams@oracle.com>
To: "'martin rudalics'" <rudalics@gmx.at>
Cc: 12406@debbugs.gnu.org
Subject: bug#12406: 24.2.50; frame parameter `menu-bar-lines' and `menu-bar-mode'
Date: Wed, 12 Sep 2012 08:33:46 -0700 [thread overview]
Message-ID: <2642D1C71B064D30A09DABF179962841@us.oracle.com> (raw)
In-Reply-To: <5050A571.3060809@gmx.at>
> >> IMHO it should update a frame iff that frame has no
> >> `menu-bar-lines' frame parameter.'
> >
> > Why? Why shouldn't a user be ABLE to turn on/off showing
> > the menu bar in all existing frames?
>
> Because this way we'd have a consistent interface: The presence of a
> frame parameter would signal "leave this frame alone".
That's inconsistent with the convention that absence of a frame parameter is
equivalent to its presence with a nil value. It is similar to proposing that we
give some special signification to the absense of a key in an alist, as opposed
to a key with value nil.
Please find another way to say "leave this frame alone". That should not be
difficult, and it should be possible to find something that has general
applicability (i.e., any frames, any frame parameter, any function that affects
a frame parameter).
More precisely, we should be able to say "leave this frame alone for parameter
BLAH". And even perhaps "make function FOO leave this frame alone for parameter
BLAH". In this case, FOO is `menu-bar-mode' and BLAH is `menu-bar-lines'.
And this should be 100% orthogonal to the presence or absence of the parameter,
and 100% orthogonal to what the parameter's current value (nil or not) might be.
> > One way or the other, we should find ways for users to
> > alternatively easily do that (affecting all existing
> > frames) OR protect some frames from that toggling.
>
> Do you have a practical use case where my proposal harms?
You are unnecessarily coupling things that do not belong together. That's a bad
idea. Whether a given parameter should be affected by a given function is
logically unrelated to whether the parameter is currently present for a given
frame, and is logically unrelated to the parameter's current value for a given
frame.
next prev parent reply other threads:[~2012-09-12 15:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-10 17:59 bug#12406: 24.2.50; frame parameter `menu-bar-lines' and `menu-bar-mode' Drew Adams
2012-09-10 20:39 ` Stefan Monnier
2012-09-10 21:41 ` Drew Adams
2012-09-12 8:09 ` martin rudalics
2012-09-12 14:13 ` Drew Adams
2012-09-12 15:08 ` martin rudalics
2012-09-12 15:33 ` Drew Adams [this message]
2012-09-12 16:48 ` martin rudalics
2012-09-12 17:42 ` Drew Adams
2012-09-12 17:53 ` martin rudalics
2012-09-12 18:02 ` Drew Adams
2012-09-13 3:17 ` Stefan Monnier
2012-09-13 4:05 ` Drew Adams
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=2642D1C71B064D30A09DABF179962841@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=12406@debbugs.gnu.org \
--cc=rudalics@gmx.at \
/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).