emacs-devel
[Top][All Lists]
Advanced

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

default-frame-alist considered annoying


From: Miles Bader
Subject: default-frame-alist considered annoying
Date: Mon, 20 Nov 2000 11:06:48 +0900 (JST)

There are a number of frame options that can only be customized via
default-frame-alist (e.g., `cursor-type', `internal-border-width').

However, customizing default-frame-alist often has unintuitive behavior,
because the value you get when you create the customization buffer
includes *all* current frame parameters, including those that are set
via other methods (for instance, `menu-bar-lines').

If you then save the customized value of default-frame-alist, the saved
value will interact in odd ways with those set-via-other-means options.

For instance:

  I have customized `menu-bar-mode', not to some constant value, but to
  evaluate `window-system', so that I get menu-bars only under X.

  This works great, but then I customize default-frame-alist in order to
  set my default frame cursor-type; after that, when I start a new
  emacs on a tty, I get menu-bars, despite my clever setting of
  menu-bar-mode.

  The reason is that the setting of the `menu-bar-lines' frame parameter
  in my saved setting of default-frame-alist is overriding the setting
  of menu-bar-mode (in fact it's more odd than this, because anything
  that looks at the variable `menu-bar-mode' to see if there are menus
  will get confused).

Some possible solutions to this problem:

 1) The user can manually delete problematical frame-parameters every
    time he customizes default-frame-alist.  However, this only works for
    people that know what's going on behind the scenes, and so is not
    really a good option (it also causes various problems when creating
    new frames in the emacs that was used to do the customization,
    because default-frame-alist will now be out of sync with other
    parameters).

 3) Have another variable that gets customized, and which is
    automagically added to default-frame-alist (so when it gets
    customized, it doesn't inherit the current settings, except perhaps
    as done explicitly).  [this solution reflects a more general
    shortcoming of customize, that it has no general mechanism for
    `incremental' customizations]

 2) Make sure *every* frame parameter has a corresponding simple
    variable, and only allow these simple variables to be customized,
    not default-frame-alist itself.  This is fairly straight-forward,
    since it's known to work reasonably well for those frame-parameters
    that currently *do* have their own variables.

Comments?

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche



reply via email to

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