[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: In defense of Customize [was: Trying to right-align my window on sta
From: |
Christoph Wedler |
Subject: |
Re: In defense of Customize [was: Trying to right-align my window on startup] |
Date: |
Tue, 28 Jan 2014 16:17:01 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt) |
Drew Adams <drew.adams@oracle.com> writes:
[...sequence of citation does not match sequence in cited article...]
> I hardly think that Per Abrahamsen is a wimp, wrt Lisp or Emacs,
> at least. http://www.emacswiki.org/PerAbrahamsen
Just to put the rest of this posting into context: neither do I.
Everybody who has written LaTeX documents knows that Per has done an
excellent job with AucTeX - just one example...
>> > > But (IMHO) too many people ignore Customize, often because
>> > > they've gotten the impression somehow that it is for non-Lispers
>> > > or wimps.
>> >
>> > I just hate its UI.
I do not hate Customize, but I think that Customize does not solve the
main problems many users had and have with customizing Emacs. The UI is
just a minor point.
So which were the issues most users had with customizing Emacs before
the advent of custom.el:
1. Exploring customization options.
There were too many customization option to grasp (I'm not against
having many options!), and one could not easily grasp the
interdependence between different options.
2. Doing the customization.
Users had no problems using a `setq' in combination with an boolean,
integer, string value, or a enum-like use of symbols, or a simple
list consisting of these types. `global-set-key' was also almost
ok.
They had (and have - that is the point!) a problem with having to
define a function/form which contains the necessary customizations
and having to add this to some hook, provide it to eval-after-load,
or ...
3. Re-using customization (parts) of other Emacs users (or own on other
machine)
Many users re-used parts of the ~/.emacs files of others. The
problem was that these settings were a mixture of personal setting
(e.g. user-full-name), local / system-dependent settings
(grep-find-command), questions of taste (face colors), etc and
tended to grow old.
Which issues does custom.el solve?
1. Number of options: well, nothing has changed. People are still
overwhelmed by the sheer number of options. People are also puzzled
if changing some option does not have any effect, because it depends
on other options to be set to a specific value...
Yes, custom helps a bit with exploring these options, but actually
mainly on the intra-package level (which Lispers could do for
themselves by looking at the defvar in the el file).
If I'm interested in the possibilities for auto-completing some
symbol/word, I still have to know them: abbrev-mode, dabbrev-expand,
complete-tag (but no corresponding imenu-...), and in a wider sense:
ido, ... To be fair: this is diffucult.
2. Positive: face customizations became easier.
Otherwise: nothing has changed much. Yes, there is some type
checking on the values now. But to be honest, I do not see the
point that people do not have to use Lisp to set the value of some
option to some Lisp function or even sexpr.
Setting some values in specific mode (or mode groups) is not
possible. Defining key and menu bindings: nothing, let alone for
something like the mode-line, ...
3. Positive: custom-themes could be a step in the right direction
Negative: sharing customization settings is now actually more
difficult, because auto-generated custom files lack comments which
explain why default values have been changed, and because they are
ordered alphabetically and not topic-wise. Settings which work on
different machines are harder to do.
In short: custom.el made things a bit easier which were easy before and
does little to help with the others (and unfortunately these two are not
synonyms for "many users want to change it" and "should be left to
advanced users")
- `gc-cons-threshold' is customizable (which non-Lisper should change
that?), but
- defining a keybinding for C programming requires to define a function
which has to be added to some hook...
So instead of spending time on some UI, things would IMHO improve by the
following (doing the UI later)
- Define top-level forms for customizations which many people want to
do - something like
(cus-set 'indent-tabs-mode t)
(cus-set 'indent-tabs-mode nil :mode prog-mode)
(cus-define-key "some binding" command :mode c-mode)
Currently, many (mostly minor-mode) packages define their own way of
offering something like that (see
e.g. font-lock-maximum-decoration). Otherwise, people have to add
some function to some hook.
- To handle issue 1: make less options customizable: make package
authors define 5 good customization options, do not propose to make
their 30 variables (user options) customizable. These customization
option just contain "easy" values: integer, string value, or a
enum-like use of symbols, or a simple list consisting of these types.
Most of these options could actually influence the values of some
variables - something like custom-sub-themes (defined in the package)
or something like c-style. Advanced users could easily define their
own custom-sub-themes / styles - "custom" and stand Elisp co-exist
nicely.
Regards,
Christoph
- Re: In defense of Customize [was: Trying to right-align my window on startup], (continued)
- Re: Trying to right-align my window on startup, Emanuel Berg, 2014/01/14
- Re: Trying to right-align my window on startup, Marcin Borkowski, 2014/01/14
- Message not available
- Re: Trying to right-align my window on startup, Rusi, 2014/01/14
- Message not available
- Re: Trying to right-align my window on startup, Emanuel Berg, 2014/01/14
- Message not available
- Re: Trying to right-align my window on startup, Rusi, 2014/01/14
- Message not available
- Re: In defense of Customize [was: Trying to right-align my window on startup], Rusi, 2014/01/17
- Re: In defense of Customize [was: Trying to right-align my window on startup], Emanuel Berg, 2014/01/17
- Re: In defense of Customize [was: Trying to right-align my window on startup], Rusi, 2014/01/18
- Message not available
- Re: In defense of Customize [was: Trying to right-align my window on startup],
Christoph Wedler <=
- Re: In defense of Customize [was: Trying to right-align my window on startup], Emanuel Berg, 2014/01/28
- Re: In defense of Customize [was: Trying to right-align my window on startup], Phillip Lord, 2014/01/29
- Re: In defense of Customize [was: Trying to right-align my window on startup], Stefan Monnier, 2014/01/29
- Re: In defense of Customize [was: Trying to right-align my window on startup], Phillip Lord, 2014/01/29
- Re: In defense of Customize [was: Trying to right-align my window on startup], Stefan Monnier, 2014/01/29
- Re: In defense of Customize [was: Trying to right-align my window on startup], Phillip Lord, 2014/01/30
- Message not available
- Re: In defense of Customize [was: Trying to right-align my window on startup], Emanuel Berg, 2014/01/29
- Re: In defense of Customize [was: Trying to right-align my window on startup], Phillip Lord, 2014/01/29
- Message not available
- Re: In defense of Customize [was: Trying to right-align my window on startup], Emanuel Berg, 2014/01/29
- RE: In defense of Customize [was: Trying to right-align my window on startup], Drew Adams, 2014/01/28