[Top][All Lists]
[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
- default-frame-alist considered annoying,
Miles Bader <=