defvar -> defcustom

defvar -> defcustom

[Reiner Steib]

Hi,

is there an Emacs function to turn defvars into defcustoms (semi-)
automatically similar to `checkdoc'?  Such a function would be a nice
addition to `checkdoc.el'.

BTW, which :version should be added to variables that have been there
for a long time, but have been made customizable, say for 21.4?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: defvar -> defcustom

[Richard Stallman]

    is there an Emacs function to turn defvars into defcustoms (semi-)
    automatically similar to `checkdoc'?  Such a function would be a nice
    addition to `checkdoc.el'.

How could this be possible?  A program cannot figure out what :type
and :group options to use.

Re: defvar -> defcustom

[Reiner Steib]

On Sun, Oct 10 2004, Richard Stallman wrote:

>     is there an Emacs function to turn defvars into defcustoms (semi-)
>     automatically similar to `checkdoc'?  Such a function would be a nice
>     addition to `checkdoc.el'.
>
> How could this be possible?  A program cannot figure out what :type
> and :group options to use.

Surely a program cannot cover everything and the user has to go
through the changes and fix some stuff manually.  Or there should be a
"Enter recursive Edit" functionality as in `checkdoc'.

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).
The custom :group could be asked once per buffer.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: defvar -> defcustom

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

>     is there an Emacs function to turn defvars into defcustoms (semi-)
>     automatically similar to `checkdoc'?  Such a function would be a nice
>     addition to `checkdoc.el'.
>
> How could this be possible?  A program cannot figure out what :type
> and :group options to use.

M-x customize-variable already does some guessing based on the
variable name, so some sort of minimal guessing might be possible.
Current conventions would also allow to search backwards from the
defvar to the closest preceding defgroup and just assume it.

Not that I even mass-converted defvars to defgroups...

Alex.
-- 
.O.  http://www.emacswiki.org/alex/
..O  Schroeder's fifth law:
OOO  Never accept more work than you can handle in one night of hacking.

Re: defvar -> defcustom

[Luc Teirlinck]

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.

Re: defvar -> defcustom

[Luc Teirlinck]

Reiner Steib wrote:

   BTW, which :version should be added to variables that have been there
   for a long time, but have been made customizable, say for 21.4?

I had the same problem when I converted `query-replace-interactive', a
ten year old variable, to a defcustom.  I decided not to add a 
`:version "21.4"' and sent a message to emacs-devel saying that I had
not done so and asking whether that was OK.  Nobody complained.

Sincerely,

Luc.

Re: defvar -> defcustom

[Richard Stallman]

    M-x customize-variable already does some guessing based on the
    variable name, so some sort of minimal guessing might be possible.
    Current conventions would also allow to search backwards from the
    defvar to the closest preceding defgroup and just assume it.

You can give it a try if you want.  But these heuristics are not
reliable.  For instance, many variables whose names suggest a value
of t or nil in fact allow other values too.  The only way to tell
is to understand the doc string.

Weighing the time that manual editing takes against the importance of
getting the right answer, and considering that this conversion only
needs to be done once in a while, I think doing it manually may be
better.