bug#13583: 24.3.50; Error when activating auto-revert-mode

[Drew Adams]

> > The real shame is that because of its lacks (and its bad 
> > reputation resulting from those lacks and from its
> > less-than-appealing UI) many novice users also
> > skip using Customize interactively.  And they, above all, 
> > should not.
> >
> > Too often they do so from the mistaken notion that Customize
> > is just for sissies and that somehow using a bit of Lisp in
> > their init files makes them more Programmer and less Luser.
> 
> The poor discoverability of options

Agreed, assuming I understand what you mean.

> and the need to use lisp forms in some custom values

Are you referring to Customize UI fields for inputting a value, where the value
can or must be a Lisp sexp?  I'm guessing yes; otherwise, I don't follow you.

> eventaully force all users who do more than tinker at
> the edges to learn some elisp

Anyone who uses _Emacs_ and does more than tinker at the edges will end up
learning some Elisp.  That's not specific to the Customize UI.  (And, in itself,
learning some Elisp is a good thing, not a bad thing.)  But yes, you are right
that learning some Lisp helps.

> and avoid Customize altogether.

Not at all.  There is nothing that "forces all users" who do more than tinker to
"avoid Customize altogether".  That's an extreme (because of "force") version of
precisely the fallacy that I'm trying to point out.

Just because a user knows some Elisp is no reason that s?he should (let alone is
forced to) "avoid Customize altogether".

You are perfectly illustrating the very problem I pointed to: users can
mistakenly think that having recourse to Elisp instead of Customize is somehow
more advanced or somehow necessary to do anything non-trivial.  Nothing could be
further from the truth.

I would add, however, that there are too many users of defcustom who either do
not understand its possibilities or are too lazy to DTRT when it comes to
defining the :type and the possible user inputs/interactions.

Based on core code I've seen, this applies also to Emacs Dev, to some extent.
It is all too easy to just throw together a simple but awful definition - one
that is not as helpful to users as it should be.

I mention this here because it too can give users the impression that Customize
is something only rudimentary and coarse-grained - by which I mean not only the
UI (which is admittedly primitive) but the Customize machinery underlying it.

If the writer of a defcustom has only a rudimentary knowledge of defcustom or
just doesn't care enough, the result is, yes, a poor, rough, rudimentary UI for
that option.  That's not the fault of defcustom or the Customize UI so much as
it is the fault of the programmer who designs that option and its customization
possibilities.

> The type checking may useful, but it shouldn't be buried in a library
> that brings in so much extra cruft with it. 

I agree 100%.  It's an important point.  All the more important because this
feature is available to Emacs Lisp programmers ONLY for option customization.
So they do not and cannot take advantage of it otherwise.  And in many cases
they are, I think, not even very aware of it.

This is so important, IMO, that I've suggested that such type-checking (i.e.,
defcustom :type's) could be useful for non-option variables (defvars) as well.
There is no reason not to be able to take advantage of this feature for other
variables.  Unfortunately, there was little interest: "YAGNI", was about the
only response.

Today, if you want to take advantage of type-checking then you need to make the
variable that benefits from it into a user option.  Emacs Dev should separate
these two orthogonal things: type checking and user customizability.

> Far better to make those facilities available and useful whether
> the customize UI is used or not,

+1!  I could not agree more.

> and to document this style of usage in the emacs manual (even 
> if this is only links to the elisp manual).

+1 again.

> Customize is also strongly anti modular, lumping settings for 
> eveything together, and giving the user no control over per
> platform or per machine settings.
>
> It also neatly ensures that the user cannot add any
> comments to the customised settings when they are saved.

Yes, those are among the things that should be improved.  There is in fact a lot
of room for improvement in the Customize UI and wrt Emacs customizing more
generally.

As I mentioned, one problem is that the custom* (more generally, the widget*)
code is difficult to fathom and poorly documented.  The result is that few Elisp
programmers can or want to hack it.

And that probably goes for Emacs Dev programmers as well.  The author, Per A.,
was not wont to spend much effort communicating with Emacs Dev about the code.
It lacks, above all, easy ways to follow it and discover info about its parts.
Following it in the debugger is, well, "interesting".

Another problem, another reason that few people hack the Customize code, I
think, is the phenomenon I pointed to earlier: they don't bother to use the
Customize UI themselves, so they are not that familiar with it and its problems,
and they too easily tend to think that it is beneath them, somehow lower than
using Lisp.

FWIW, I use both Lisp and the Customize UI for my customizations.

I _want_ Customize to automatically manage most of my option and face
customizations.

But in a separate `custom-file'.  I specifically keep my init file away from
Customize, and I think Emacs Dev should advise most users to do the same thing.
There is little reason to let a program mix automatically generated code in with
your manually edited code.  And vice versa, there is little reason for you to be
editing the same file that contains automatically generated code.

> > The best thing that could happen - for users, IMO, is for 
> > Emacs developers to stop, themselves, using "Custom only for
> > face settings" etc., and thus confront the deficiencies of the
> > UI directly.  Turn your frustration with it into
> > something constructive - for all users.
> 
> No, the best thing would be to remove Customize altogether :-)

Though I disagree, I won't argue with you about that.  I will say that that
attitude is a primary obstacle to our improving customization for Emacs users.
I don't mean your attitude personally, but the fact that the same attitude is so
prevalent.

The reaction of most Emacs developers is just to ignore Customize, which is no
more helpful than removing it would be.

FWIW, I used to feel exactly as you just expressed it: Customize is not worth
it.  Little by little I came to learn more about it, and now I feel strongly
that it is a good thing.

Had I not tried to make my code useful for other users besides myself, I would
never have bothered to learn more about defcustom :type's etc.  I would have
just continued to keep the same attitude toward what Customize is good for:
nothing.

Not that the _UI_ is wonderful - far from it.  It is especially all of the
behind-the-scenes initialization, :set triggering, backing up, and type-checking
that is helpful, if not indispensable for robust preference management.

Trying to take advantage of those features using only Lisp is the problem that
was at the starting point of this thread.  You can do it, but you must be on
your toes and learn a fair amount about the custom* code.  See earlier in the
thread, about different "ugly little hacks" to get custom* to do what you want.

I do some of that myself, and I put some of it into an extension of the
Customize UI code, so that others can benefit without needing to dive into the
custom* code themselves each time.

IMO, that's the kind of thing we need, to start with: fix the UI so it lets you
do the kinds of things that started this thread: e.g., tell Customize to ignore
certain changes and consider them irrelevant to saving.

There is no reason that users should need to use Lisp to do this kind of thing.
It is simple to give them an action in the UI that accomplishes the same thing.

Users are not forced to resort to Lisp and "avoid Customize altogether", but
they do need to use Lisp today to accomplish certain things that Customize
should let them do interactively, directly.  

Those are a minority of the things that one can do with the custom* features,
but it is still important to integrate them into the UI.