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

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

[Dani Moncayo]

Recipe from "emacs -Q":
1. Eval: (setq auto-revert-use-notify nil)
2. Visit some file.
3. M-x auto-revert-mode RET

When I do it, my Emacs fails with this message:
   custom-initialize-reset: Symbol's value as variable is void:
auto-revert-notify-watch-descriptor

and auto-revert-mode is not activated.


In GNU Emacs 24.3.50.1 (i386-mingw-nt5.2.3790)
 of 2013-01-25 on MS-W8-DANI
Bzr revision: 111604 eliz@gnu.org-20130125143821-1ykj7ia1qjojjjnp
Windowing system distributor `Microsoft Corp.', version 5.2.3790
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src
 -Ic:/emacs/libs/libpng-dev_1.4.3-1_win32/include
 -Ic:/emacs/libs/zlib-dev_1.2.5-2_win32/include
 -Ic:/emacs/libs/giflib-4.1.4-1-lib/include
 -Ic:/emacs/libs/jpeg-6b-4-lib/include
 -Ic:/emacs/libs/tiff-3.8.2-1-lib/include
 -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
 -Ic:/emacs/libs/gnutls-3.1.5-w32/include
 -Ic:/emacs/libs/libiconv-1.14-2-mingw32-dev/include'


-- 
Dani Moncayo

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

[Eli Zaretskii]

> Date: Tue, 29 Jan 2013 11:59:43 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> Recipe from "emacs -Q":
> 1. Eval: (setq auto-revert-use-notify nil)
> 2. Visit some file.
> 3. M-x auto-revert-mode RET
> 
> When I do it, my Emacs fails with this message:
>    custom-initialize-reset: Symbol's value as variable is void:
> auto-revert-notify-watch-descriptor
> 
> and auto-revert-mode is not activated.

Cockipt error.  The doc string clearly says

    "If non-nil Auto Revert Mode uses file notification functions.
  This requires Emacs being compiled with file notification
  support (see `auto-revert-notify-enabled').  You should set this
  variable through Custom only."               ^^^^^^^^^^^^^^^^^^^
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That's because this defcustom has a :set function defined for it; if
that function isn't run, the results are unpredictable.

Any reason not to close this bug?

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

[Dani Moncayo]

> Cockipt error.  The doc string clearly says
>
>     "If non-nil Auto Revert Mode uses file notification functions.
>   This requires Emacs being compiled with file notification
>   support (see `auto-revert-notify-enabled').  You should set this
>   variable through Custom only."               ^^^^^^^^^^^^^^^^^^^
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> That's because this defcustom has a :set function defined for it; if
> that function isn't run, the results are unpredictable.
>
> Any reason not to close this bug?

I try to avoid the customize facility as much as I can, because it
doesn't allow to set values based on conditions like the system-type,
for example.  If I do some customization "by hand" in my init file, I
have all the power an flexibility of elisp for doing what I want.
That is not possible using customize.  So currently I use customize
only for face-related settings, and BTW I have to maintain several
custom files (one for GUI sessions, other for the Windows console and
other for the Ubuntu console) because each environment requires a
specific visual customization.

Therefore, I'd like to be able to set `auto-revert-use-notify'
directly in my init file, with `setq', but if that is not possible, I
will have to adapt myself.

-- 
Dani Moncayo

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

[Eli Zaretskii]

> Date: Tue, 29 Jan 2013 12:34:40 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 13583@debbugs.gnu.org
> 
> I try to avoid the customize facility as much as I can, because it
> doesn't allow to set values based on conditions like the system-type,
> for example.

Doesn't custom-set-variables work inside an "if" clause?  If it does,
then what's the problem of using it only on some systems?

> Therefore, I'd like to be able to set `auto-revert-use-notify'
> directly in my init file, with `setq', but if that is not possible, I
> will have to adapt myself.

You can run the :set form of the option, with suitable substitutions
for "variable" and "value", instead of setting the value with setq.
But then you'd need to change that every time the :set form changes in
autorevert.el.

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

[Dani Moncayo]

>> I try to avoid the customize facility as much as I can, because it
>> doesn't allow to set values based on conditions like the system-type,
>> for example.
>
> Doesn't custom-set-variables work inside an "if" clause?  If it does,
> then what's the problem of using it only on some systems?

The problem with that approach is that, if I do some other
customization and save it, the custom facility writes _all_ current
unsaved customization to the custom file, therefore the customization
of `auto-revert-use-notify' would end up in the custom file, which is
not what I want, obviously.

A workaround is to fool the customize facility by marking the relevant
customizations as "saved" just after the call to custom-set-variables,
but that is an ugly hack, IMO.

>> Therefore, I'd like to be able to set `auto-revert-use-notify'
>> directly in my init file, with `setq', but if that is not possible, I
>> will have to adapt myself.
>
> You can run the :set form of the option, with suitable substitutions
> for "variable" and "value", instead of setting the value with setq.
> But then you'd need to change that every time the :set form changes in
> autorevert.el.

So that doesn't seem like a good solution either...

-- 
Dani Moncayo

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

[Eli Zaretskii]

> Date: Tue, 29 Jan 2013 13:18:58 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 13583@debbugs.gnu.org
> 
> >> I try to avoid the customize facility as much as I can, because it
> >> doesn't allow to set values based on conditions like the system-type,
> >> for example.
> >
> > Doesn't custom-set-variables work inside an "if" clause?  If it does,
> > then what's the problem of using it only on some systems?
> 
> The problem with that approach is that, if I do some other
> customization and save it

??? You just said that you "try to avoid the customize facility", so
why in the world would you want to save your customizations??

Instead of saving them, use the custom-set-variables function to do
what you want, when you want.

> the custom facility writes _all_ current unsaved customization to
> the custom file, therefore the customization of
> `auto-revert-use-notify' would end up in the custom file, which is
> not what I want, obviously.

This is a misunderstanding, surely: custom-set-variables does not save
anything.  It arranges for the variable to be customized, as if you
used the Customize user interface.  So I don't understand how "unsaved
customizations" and "custom file" come into play here.  Could you
perhaps give more details about the workflow which brings you to those
issues, including the commands you use?

> A workaround is to fool the customize facility by marking the relevant
> customizations as "saved" just after the call to custom-set-variables,
> but that is an ugly hack, IMO.

Why would you need to save any customizations at all?  If you want to
customize yet another variable, add yet another custom-set-variables
form to your .emacs, that's all.  What am I missing?

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

[Dani Moncayo]

>> The problem with that approach is that, if I do some other
>> customization and save it
>
> ??? You just said that you "try to avoid the customize facility", so
> why in the world would you want to save your customizations??

So far I use it for face customization, exclusively.

> Instead of saving them, use the custom-set-variables function to do
> what you want, when you want.

Good idea.  I'll do it.

>> the custom facility writes _all_ current unsaved customization to
>> the custom file, therefore the customization of
>> `auto-revert-use-notify' would end up in the custom file, which is
>> not what I want, obviously.
>
> This is a misunderstanding, surely: custom-set-variables does not save
> anything.  It arranges for the variable to be customized, as if you
> used the Customize user interface.  So I don't understand how "unsaved
> customizations" and "custom file" come into play here.  Could you
> perhaps give more details about the workflow which brings you to those
> issues, including the commands you use?

In my init file, I store a file name in `custom-file' so that the
stuff that customize manages is kept separate from my stuff, i.e., the
things I've write myself in my init file.

In the custom file, I have exclusively face customizations, which I
can tweak and save whenever I want.

So, if I write a call to customize-set-faces or
customize-set-variables right in my init file, the customizations made
that way end up in a "unsaved" state, so that if I do some face
customization (using customize) and save it, the custom file receives
not only the face customization, but also the other "unsaved" ones,
which I wanted to keep out of the custom file.

>> A workaround is to fool the customize facility by marking the relevant
>> customizations as "saved" just after the call to custom-set-variables,
>> but that is an ugly hack, IMO.
>
> Why would you need to save any customizations at all?  If you want to
> customize yet another variable, add yet another custom-set-variables
> form to your .emacs, that's all.  What am I missing?

Yes, I think that's a good approach.  I'll get rid of my custom file,
and do the appropriate calls to custom-set-xxxx directly from my init
file.

Thank you.  This bug can be closed.

-- 
Dani Moncayo

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

[Dani Moncayo]

>> Why would you need to save any customizations at all?  If you want to
>> customize yet another variable, add yet another custom-set-variables
>> form to your .emacs, that's all.  What am I missing?
>
> Yes, I think that's a good approach.  I'll get rid of my custom file,
> and do the appropriate calls to custom-set-xxxx directly from my init
> file.

But for the record: IIUC, I that approach isn't flawless either,
because doing face customization is pretty hard without the customize
facility, and using customize will imply:
1. Do the customization in a custom buffer.
2. Save the customization (for getting the elisp code).
3. Look for the appropriate sentence in the generated custom file, and
move it to my init file.

That is not very convenient, but fortunately I don't do face
customization every day.

-- 
Dani Moncayo

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

[Drew Adams]

Dani said:

> But for the record: IIUC, I that approach isn't flawless either,
> because doing face customization is pretty hard without the customize
> facility, and using customize will imply:
> 1. Do the customization in a custom buffer.
> 2. Save the customization (for getting the elisp code).
> 3. Look for the appropriate sentence in the generated custom file, and
> move it to my init file.
> 
> That is not very convenient, but fortunately I don't do face
> customization every day.

and

> A workaround is to fool the customize facility by marking the relevant
> customizations as "saved" just after the call to custom-set-variables,
> but that is an ugly hack, IMO.

That workaround is an ugly hack, OK.  But it is no more an ugly hack than the
other workarounds (yes, they are just that) that you all have been discussing,
IMO.

Michael H. is right that (a) the custom* arsenal has the tools one needs but (b)
interactive Customize itself should be expanded to provide general users with
them directly (i.e., no Lisp needed).

I do some of that in my ugly-little-hack library cus-edit+.el [*], but no doubt
someone knowing the custom* code well could do better.  There has been little
interest so far, unfortunately.  One reason is perhaps that the cus* code is
difficult to fathom.

Given the current state of what's available, I still do recommend the ugly
little hack Dani mentioned: telling customize that there has been no change to
the option (i.e., lying).

That's what the custom* code itself does.  That the names of the things involved
make it look like you are claiming that the option has been _saved_, instead of
telling customize to ignore any changes, is only a name problem - for us people.

But yes, there is room for improvement.

[*]
http://www.emacswiki.org/emacs-en/download/cus-edit%2b.el
http://www.emacswiki.org/emacs/CustomizingAndSaving#CustomizePlus

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

[Wolfgang Jenkner]

On Tue, Jan 29 2013, Dani Moncayo wrote:

> That is not very convenient, but fortunately I don't do face
> customization every day.

You could use a theme (in the sense of deftheme) for that.  I have the
impression that most (all?) of them are maintained by directly editing
them and not via the customize interface.  At least, I do this and
otherwise pretend that "customize" doesn't exist (of course, themes are
based on it but they shouldn't ;-)

Wolfgang

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

[Drew Adams]

WJ> I do this and otherwise pretend that "customize" doesn't exist
WJ> (of course, themes are based on it but they shouldn't ;-)

SM> It should be possible to have (setq auto-revert-use-notify 
SM> nil) in your .emacs and not use Custom.
SM> 
SM>   Stefan "who also uses Custom only for face settings"

[Just two examples - other Emacs developers have admitted to much the same.]

While there is perhaps room for improvement also for Lisp users of custom* code,
the sad truth is that interactive Customize, which is what we advertize for
general users, gets left behind in the dust.

But it is there that real improvement is sorely needed.

With so many Emacs developers not even using Customize interactively for their
own use, interactive Customize is essentially abandoned in terms of development.

Yidong and others have fixed some bugs and tweaked cosmetically around some of
the edges, but otherwise the UI code has hardly been touched since its
inception.  Certainly there has been no improvement in the area being discussed
here.

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.

Unfortunately, that way they often miss out on the real power of custom*,
including type-checking and :set forms, because they do not sufficiently
understand what Lisp code to use.  `setq' on its own certainly does not cut the
mustard, but it is common to see users rely on it.

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.

With that, there might be some hope that users would sooner or later get the
Customize improvements they deserve.

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

[Andy Moreton]

On Tue 29 Jan 2013, Drew Adams wrote:

> 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 and the need to use lisp forms in
some custom values eventaully force all users who do more than tinker at
the edges to learn some elisp and avoid Customize altogether.

> Unfortunately, that way they often miss out on the real power of custom*,
> including type-checking and :set forms, because they do not sufficiently
> understand what Lisp code to use.  `setq' on its own certainly does not cut the
> mustard, but it is common to see users rely on it.

The type checking may useful, but it shouldn't be buried in a library
that brings in so much extra cruft with it. Far better to make those
facilities available and useful whether the customize UI is used or not,
and to document this style of usage in the emacs manual (even if this is
only links to the elisp manual).

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.

> 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 :-)

    AndyM

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.

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

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

[Drew Adams]

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

I did - proposed the explicit code changes long ago.
And the code is still available, as I mentioned.

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

[Eli Zaretskii]

> Date: Tue, 29 Jan 2013 15:22:04 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 13583@debbugs.gnu.org
> 
> >> Why would you need to save any customizations at all?  If you want to
> >> customize yet another variable, add yet another custom-set-variables
> >> form to your .emacs, that's all.  What am I missing?
> >
> > Yes, I think that's a good approach.  I'll get rid of my custom file,
> > and do the appropriate calls to custom-set-xxxx directly from my init
> > file.
> 
> But for the record: IIUC, I that approach isn't flawless either,
> because doing face customization is pretty hard without the customize
> facility, and using customize will imply:
> 1. Do the customization in a custom buffer.
> 2. Save the customization (for getting the elisp code).
> 3. Look for the appropriate sentence in the generated custom file, and
> move it to my init file.
> 
> That is not very convenient, but fortunately I don't do face
> customization every day.

Exactly.  If you change customizations very frequently, then they
probably don't belong in your init/custom file anyway.

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

[Eli Zaretskii]

> Date: Tue, 29 Jan 2013 14:42:39 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 13583@debbugs.gnu.org
> 
> In the custom file, I have exclusively face customizations, which I
> can tweak and save whenever I want.

For face customizations, you can use custom-save-faces instead.

> So, if I write a call to customize-set-faces or
> customize-set-variables right in my init file, the customizations made
> that way end up in a "unsaved" state, so that if I do some face
> customization (using customize) and save it, the custom file receives
> not only the face customization, but also the other "unsaved" ones,
> which I wanted to keep out of the custom file.

Then keep all your calls to custom-save-* in one place.  This way,
even if you overwrite them, you can easily restore order by using the
backup of that single file.  (You do back up your init files, right?)

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

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> You can run the :set form of the option, with suitable substitutions
> for "variable" and "value", instead of setting the value with setq.
> But then you'd need to change that every time the :set form changes in
> autorevert.el.

IMHO, no user should need to do something like that.

I have a question: If it may be necessary for users to run this code to
achieve what Dani wants (which is not exotic), why don't we just provide
a callable function that DTRT (and call it in the setter), instead of
forcing people to call this code indirectly via Custom?

The current situation is consistent and not a bug, yes - but it may also
be confusing to non-experts (i.e., the majority of Emacs users).

I often saw people being reluctant about using `custom-set-variables' in
their init file.

I browsed the doc of `custom-set-variables', as well as the
"Customization" chapter in the manual.  I found no places were we say
that some of these functions are suitable for being called from other
files than the custom file, without danger.  But if it is sometimes even
necessary to do so, even if the user doesn't use the Customize
interface, shouldn't we clearly explain this somewhere?


Regards,

Michael.

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

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Tue, 29 Jan 2013 14:44:50 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > You can run the :set form of the option, with suitable substitutions
> > for "variable" and "value", instead of setting the value with setq.
> > But then you'd need to change that every time the :set form changes in
> > autorevert.el.
> 
> IMHO, no user should need to do something like that.

No one does.  Using custom-set-variables is much easier.  I just
wanted to give Dani all the alternatives I knew about.  Nothing wrong
with that, is there?

> I often saw people being reluctant about using `custom-set-variables' in
> their init file.
> 
> I browsed the doc of `custom-set-variables', as well as the
> "Customization" chapter in the manual.  I found no places were we say
> that some of these functions are suitable for being called from other
> files than the custom file, without danger.

I call it from my .emacs, and never had any problems in years.

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

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> > IMHO, no user should need to do something like that.
>
> No one does.  Using custom-set-variables is much easier.  I just
> wanted to give Dani all the alternatives I knew about.  Nothing wrong
> with that, is there?

Ok, no - sorry.

> > I often saw people being reluctant about using `custom-set-variables' in
> > their init file.
> > 
> > I browsed the doc of `custom-set-variables', as well as the
> > "Customization" chapter in the manual.  I found no places were we say
> > that some of these functions are suitable for being called from other
> > files than the custom file, without danger.
>
> I call it from my .emacs, and never had any problems in years.

Good to know - still wonder if we should say explicitly somewhere that
this is possible/supported.


Regards,

Michael.

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

[Stefan Monnier]

> Cockipt error.  The doc string clearly says
>     "If non-nil Auto Revert Mode uses file notification functions.
>   This requires Emacs being compiled with file notification
>   support (see `auto-revert-notify-enabled').  You should set this
>   variable through Custom only."               ^^^^^^^^^^^^^^^^^^^
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> That's because this defcustom has a :set function defined for it; if
> that function isn't run, the results are unpredictable.
> Any reason not to close this bug?

It should be possible to have (setq auto-revert-use-notify nil) in your
.emacs and not use Custom.


        Stefan "who also uses Custom only for face settings"

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

[Michael Albinus]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Cockipt error.  The doc string clearly says
>>     "If non-nil Auto Revert Mode uses file notification functions.
>>   This requires Emacs being compiled with file notification
>>   support (see `auto-revert-notify-enabled').  You should set this
>>   variable through Custom only."               ^^^^^^^^^^^^^^^^^^^
>>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> That's because this defcustom has a :set function defined for it; if
>> that function isn't run, the results are unpredictable.
>> Any reason not to close this bug?
>
> It should be possible to have (setq auto-revert-use-notify nil) in your
> .emacs and not use Custom.

I've added

  :initialize 'custom-initialize-default

to that defcustom. That seems to do the job.

Best regards, Michael.

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

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  13583@debbugs.gnu.org
> Date: Tue, 29 Jan 2013 17:06:10 +0100
> 
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> 
> >> Cockipt error.  The doc string clearly says
> >>     "If non-nil Auto Revert Mode uses file notification functions.
> >>   This requires Emacs being compiled with file notification
> >>   support (see `auto-revert-notify-enabled').  You should set this
> >>   variable through Custom only."               ^^^^^^^^^^^^^^^^^^^
> >>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> That's because this defcustom has a :set function defined for it; if
> >> that function isn't run, the results are unpredictable.
> >> Any reason not to close this bug?
> >
> > It should be possible to have (setq auto-revert-use-notify nil) in your
> > .emacs and not use Custom.
> 
> I've added
> 
>   :initialize 'custom-initialize-default
> 
> to that defcustom. That seems to do the job.

Thanks, but the doc string still says one needs to use Customize.

Anyway, if ":initialize 'custom-initialize-default" is such a
wonderful feature that everyone wants, why isn't it the default, and
why does the user of defcustom need to opt-in it?

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

[Stefan Monnier]

> Anyway, if ":initialize 'custom-initialize-default" is such a
> wonderful feature that everyone wants, why isn't it the default, and
> why does the user of defcustom need to opt-in it?

Sadly, it all depends on the particulars of the case at hand.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Michael Albinus <michael.albinus@gmx.de>, 13583@debbugs.gnu.org
> Date: Tue, 29 Jan 2013 16:39:09 -0500
> 
> > Anyway, if ":initialize 'custom-initialize-default" is such a
> > wonderful feature that everyone wants, why isn't it the default, and
> > why does the user of defcustom need to opt-in it?
> 
> Sadly, it all depends on the particulars of the case at hand.

Could you perhaps elaborate a bit more?

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

[Stefan Monnier]

>> > Anyway, if ":initialize 'custom-initialize-default" is such a
>> > wonderful feature that everyone wants, why isn't it the default, and
>> > why does the user of defcustom need to opt-in it?
>> Sadly, it all depends on the particulars of the case at hand.
> Could you perhaps elaborate a bit more?

Not much, really.  Basically it depends on the typical use case, and on
what happens in the rest of the code (e.g. if the setter is not run,
is the resulting state consistent and to which value does it
correspond).


        Stefan

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

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> Cockipt error.  The doc string clearly says
>> >>     "If non-nil Auto Revert Mode uses file notification functions.
>> >>   This requires Emacs being compiled with file notification
>> >>   support (see `auto-revert-notify-enabled').  You should set this
>> >>   variable through Custom only."               ^^^^^^^^^^^^^^^^^^^
>> >>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >> That's because this defcustom has a :set function defined for it; if
>> >> that function isn't run, the results are unpredictable.
>> >> Any reason not to close this bug?
>> >
>> > It should be possible to have (setq auto-revert-use-notify nil) in your
>> > .emacs and not use Custom.
>> 
>> I've added
>> 
>>   :initialize 'custom-initialize-default
>> 
>> to that defcustom. That seems to do the job.
>
> Thanks, but the doc string still says one needs to use Customize.

The docstring says "You should set this variable through Custom only."
"Should" is not too restrictive, I believe.

Best regards, Michael.

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

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: monnier@IRO.UMontreal.CA,  13583@debbugs.gnu.org
> Date: Wed, 30 Jan 2013 08:28:39 +0100
> 
> >> I've added
> >> 
> >>   :initialize 'custom-initialize-default
> >> 
> >> to that defcustom. That seems to do the job.
> >
> > Thanks, but the doc string still says one needs to use Customize.
> 
> The docstring says "You should set this variable through Custom only."
> "Should" is not too restrictive, I believe.

But "only" is.

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

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Thanks, but the doc string still says one needs to use Customize.
>> 
>> The docstring says "You should set this variable through Custom only."
>> "Should" is not too restrictive, I believe.
>
> But "only" is.

Nitpicking! :-)

I've changed it in the trunk.

Best regards, Michael.

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

[Dani Moncayo]

>> It should be possible to have (setq auto-revert-use-notify nil) in your
>> .emacs and not use Custom.
>
> I've added
>
>   :initialize 'custom-initialize-default
>
> to that defcustom. That seems to do the job.

Seems to work, indeed.  Thank you.

-- 
Dani Moncayo