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

[Andy Moreton]

On Tue 29 Jan 2013, Drew Adams wrote:
>> 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 don't use customize at all. It's hard to find options in the UI and its
harder to configure things via the UI than to do it directly via elisp.

> 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.

This is an essential problem of the customize package. By making it to
hard to write and debug something robust, package authors are more
likely to do the minimum neccesary to "tick the box" and move on.

The very prescence of customize is a strong disicentive for a developer
to come up with something better, due to all fo the comatibiility and
migration headaches that must be overcome for a replacement or evolution
to be acceptable.

>> 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.

Type checking and accessor methods are fundamental primitives that
belong in the interpreter/compiler or an object system library.

The extra stuff for deciding how to present a variavble of a particular
type in UI is a separate set of concerns.

> 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.

The Cygwin folk use SHTDI (somebody has to do it) and PTC (patches
thoughtfully considered), both which are applicable here.

> 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.

Agreed (but see above).

>> 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.

Agreed. These code quality issues are good reasons for delaying
integration of a new feature until the basics are in place.

> 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.

No, I think the problem is that most emacs devs don't use it because
they do not experince the problems that it clains to be a solution for.
Those who have used it have discovered that it causes pain, and resolved
not to repeat the experience.

> 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.

That is the only thing I configure about it: to prevent it damaging my
init file :-)

>> > 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.

That machinery is what puts me off in the first place. Customize wraps
everything up in an embedded language to describe how to transform
settings into lisp. I'd rather avoid the obfuscation and write the lisp
myself to start with.

> 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.

Please consider contributing these improvements to emacs.

> 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.

Agreed, but this should not be at the expense of doing things directly
from code and avoiding the UI.


    AndyM