Re: defvar -> defcustom

[Luc Teirlinck <teirllm@dms.auburn.edu>]

I can not see why we should provide a function to make it convenient
for people to do something they should not be doing: blindly replace
defvar's by defcustom's.  If people are going to try to do that, plenty
of inappropriate defvar's are going to wind up in Custom buffers,
cluttering them and confusing the user.  Moreover, the resulting
defcustom's are likely to be very far from the quality and reliability
of most present defcustom's.

Reiner Steib wrote:

   It cannot figure out the :type for all defvars, but I think 80% could
   be guessed heuristically (e.g. if value is t or nil, take 'boolean).

Do not count on that one.  Plenty of defvar's allow t and/or nil as
defaults or special cases, whereas the "main" type is something else,
often an integer or float, but potentially anything.

The relatively best thing is to do if you are not 100% sure about the
type is to specify _no_ type.  That will give it type 'sexp, which may
not be ideal, but at least is guaranteed not to mess up anything
serious.  I personally always specify `:type 'sexp' explicitly, even
though it is the default anyway, just to show that I _did_ look at it.
So if you did not look at it, it might be better to specify _no_ type,
to avoid giving the impression that you did look at it.

Alex Schroeder wrote:

    Current conventions would also allow to search backwards from the
    defvar to the closest preceding defgroup and just assume it.

That is unfortunately correct.  However it is dangerous to rely on
this convention blindly.  You _definitely_ do not want to rely on it
in files like, say, simple.el, which has defgroup's all over the place
and where anybody can add a new defgroup any day. 

More importantly, it is not just the :type or :group.  People have
come to rely on the fact that Custom does things for them
automatically, that defvar does not do.  Unless you are willing to
make the use of Custom much more unpredictable, you will need to worry
about whether you need one or more :set-after's, :load's, :require's
and so on.  You will need to worry about whether there is a need for a
:set function and if yes, whether the default value of :initialize,
namely `custom-initialize-reset', is really appropriate for that :set
function (it quite often is not).

Missing :set-after's or :require's may mean that when the user saves
his customizations in .emacs, then these customizations will
unpredictably sometimes be respected and sometimes not.  That seems
serious. So these are actually bigger problems than :type (which is
the least important problem, _as long as_ you do _not_ try to guess)
or :group.

Sincerely,

Luc.