define-derived-mode

define-derived-mode

[Luc Teirlinck]

`define-minor-mode' and `define-generic-mode' generate defcustoms for
their mode hooks, `define-derived-mode' does not.  I am not really sure
that it is such a great idea to have `define-minor-mode' and
`define-generic-mode' spew out all these automatic defcustoms, but
given that they do that, it seems rather strange and inconsistent that
`define-derived-mode' does not.  I would guess that people more often
want to customize major mode hooks than minor mode hooks.

Sincerely,

Luc.

Re: define-derived-mode

[Luc Teirlinck]

>From my previous message:

   I am not really sure that it is such a great idea to have
   `define-minor-mode' and `define-generic-mode' spew out all these
   automatic defcustoms, but given that they do that, it seems rather
   strange and inconsistent that `define-derived-mode' does not.

If one would make it construct defcustoms, then maybe that should only
happen if the :group keyword is given, so it would not get into the
same default group problems as `define-{minor,generic}-mode'.

Sincerely,

Luc.

Re: define-derived-mode

[Richard Stallman]

    If one would make it construct defcustoms, then maybe that should only
    happen if the :group keyword is given, so it would not get into the
    same default group problems as `define-{minor,generic}-mode'.

I don't follow the logic of this argument.  Whatever group is right
for the move variable, isn't that right for the hook variable too?

However, I am not sure we want defcustoms for *any* mode hooks.  How
often would a user want to customize one with defcustom?  It seems to
me that defcustoms for mode hooks are mostly useless clutter.

What argument is there that they are useful and worth their cost?

Re: define-derived-mode

[Juanma Barranquero]

> However, I am not sure we want defcustoms for *any* mode hooks.  How
> often would a user want to customize one with defcustom?

  C:\...\lisp> grep -E "defcustom.*-mode-hook" *.el
  add-log.el:(defcustom change-log-mode-hook nil
  autorevert.el:(defcustom auto-revert-mode-hook nil
  autorevert.el:(defcustom global-auto-revert-mode-hook nil
  calculator.el:(defcustom calculator-mode-hook nil
  cmuscheme.el:(defcustom inferior-scheme-mode-hook nil
  comint.el:(defcustom comint-mode-hook '(turn-on-font-lock)
  cus-edit.el:(defcustom custom-mode-hook nil
  descr-text.el:(defcustom describe-text-mode-hook nil
  diff-mode.el:(defcustom diff-mode-hook nil
  dired.el:(defcustom dired-mode-hook nil
  ediff-init.el:(defcustom ediff-mode-hook nil
  ehelp.el:(defcustom electric-help-mode-hook nil
  follow.el:(defcustom follow-mode-hook nil
  forms.el:(defcustom forms-mode-hook nil
  help-mode.el:(defcustom help-mode-hook nil
  hexl.el:(defcustom hexl-mode-hook '(hexl-follow-line hexl-activate-ruler)
  ibuffer.el:(defcustom ibuffer-mode-hook nil
  ielm.el:(defcustom ielm-mode-hook nil
  info.el:(defcustom Info-mode-hook
  log-edit.el:(defcustom log-edit-mode-hook (if (boundp
'vc-log-mode-hook) vc-log-mode-hook)
  replace.el:(defcustom occur-mode-hook '(turn-on-font-lock)
  ses.el:(defcustom ses-mode-hook nil
  shell.el:(defcustom shell-mode-hook '()
  speedbar.el:(defcustom speedbar-mode-hook nil
  term.el:(defcustom term-mode-hook '()
  view.el:(defcustom view-mode-hook nil
  wid-browse.el:(defcustom widget-browse-mode-hook nil
  winner.el:(defcustom winner-mode-hook nil

-- 
                    /L/e/k/t/u

Re: define-derived-mode

[Richard Stallman]

    > However, I am not sure we want defcustoms for *any* mode hooks.  How
    > often would a user want to customize one with defcustom?

      C:\...\lisp> grep -E "defcustom.*-mode-hook" *.el
      add-log.el:(defcustom change-log-mode-hook nil
      autorevert.el:(defcustom auto-revert-mode-hook nil

So what?  The question is whether these are useful,
not whether they exist.

We have just been reminded of the reasons why customizing
these hooks is likely not to work right--in addition to the
fact that the motive to do so is probably rare.

We wrote those defcustoms because a feeling developed
that it was the right thing to use defcustom for every 
variable that someone might perhaps want to customize.
But that doesn't mean we have to stick with them.

Re: define-derived-mode

[Luc Teirlinck]

Richard Stallman wrote:

   I don't follow the logic of this argument.  Whatever group is right
   for the move variable, isn't that right for the hook variable too?

I believe that we are misunderstanding each other, but since I changed
my mind on the issue in the meantime, this has become irrelevant.

   However, I am not sure we want defcustoms for *any* mode hooks.  How
   often would a user want to customize one with defcustom?  It seems to
   me that defcustoms for mode hooks are mostly useless clutter.

   What argument is there that they are useful and worth their cost?

When I originally proposed this (I no longer am), I was worrying about
consistency with `define-{minor,generic}-mode'.  I already pointed out
in my original message that I was less than enthused about these two
functions spewing out all these automatic defcustoms.

Customizing mode hooks through Custom is only convenient if an
:options keyword is used.  (Currently, customizing hooks through
Custom is not advisable to begin with because of several bugs we
discussed before.  We plan to fix these in Emacs 23 or 24.)

If I understood correctly, define-generic-mode only started
constructing automatic defcustoms recently, which was an incompatible
change.   In that case, it could easily be reversed, which would make
the two major mode defining functions consistent in this respect.

For define-minor-mode, the situation is more complex.  It already
defined defcustoms in 21.3.  So here, removing them would be an
incompatible change.  It is possible that some users already
customized these hooks through Custom.

Sincerely,

Luc.

Re: define-derived-mode

[Richard Stallman]

    If I understood correctly, define-generic-mode only started
    constructing automatic defcustoms recently, which was an incompatible
    change.   In that case, it could easily be reversed, which would make
    the two major mode defining functions consistent in this respect.

    For define-minor-mode, the situation is more complex.  It already
    defined defcustoms in 21.3.  So here, removing them would be an
    incompatible change.  It is possible that some users already
    customized these hooks through Custom.

Such a change is no big deal.  Let's turn off generation of these
defcustoms.

Re: define-derived-mode

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     If I understood correctly, define-generic-mode only started
>     constructing automatic defcustoms recently, which was an
>     incompatible change.  In that case, it could easily be reversed,
>     which would make the two major mode defining functions
>     consistent in this respect.
>
>     For define-minor-mode, the situation is more complex.  It
>     already defined defcustoms in 21.3.  So here, removing them
>     would be an incompatible change.  It is possible that some users
>     already customized these hooks through Custom.
>
> Such a change is no big deal.  Let's turn off generation of these
> defcustoms.

It must be noted that variables that are already customized with the
customize interface will retain their customized values.  You just
can't recustomize them.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: define-derived-mode

[Lute Kamstra]

Richard Stallman <rms@gnu.org> writes:

>     If I understood correctly, define-generic-mode only started
>     constructing automatic defcustoms recently, which was an incompatible
>     change.   In that case, it could easily be reversed, which would make
>     the two major mode defining functions consistent in this respect.
>
>     For define-minor-mode, the situation is more complex.  It already
>     defined defcustoms in 21.3.  So here, removing them would be an
>     incompatible change.  It is possible that some users already
>     customized these hooks through Custom.
>
> Such a change is no big deal.  Let's turn off generation of these
> defcustoms.

I just did this for define-generic-mode.  I'll do define-minor-mode as
well.

Lute.

Re: define-derived-mode

[Lute Kamstra]

Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:

> Richard Stallman <rms@gnu.org> writes:

[...]

>> Such a change is no big deal.  Let's turn off generation of these
>> defcustoms.
>
> I just did this for define-generic-mode.

> I'll do define-minor-mode as well.

Done.

Lute.

Re: define-derived-mode

[Lute Kamstra]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

[...]

> If I understood correctly, define-generic-mode only started
> constructing automatic defcustoms recently,

True; I made the change.

> which was an incompatible change.

Not compatible with what?

> In that case, it could easily be reversed, which would make the two
> major mode defining functions consistent in this respect.

I primarily wanted to define the mode hook as a variable so that I
could give it docstring.  I chose defcustom over defvar because
define-minor-mode and quite some other major modes did that.  I don't
strongly object to making the defcustom a defvar, but I don't
understand your problems with the use of defcustom:

> Customizing mode hooks through Custom is only convenient if an
> :options keyword is used.  (Currently, customizing hooks through
> Custom is not advisable to begin with because of several bugs we
> discussed before.  We plan to fix these in Emacs 23 or 24.)

I don't recall the bugs you refer to; could you give me the subject(s)
of the relevant thread(s)?

Lute.

Re: define-derived-mode

[Luc Teirlinck]

Lute Kamstra wrote:

   > which was an incompatible change.

   Not compatible with what?

With pre-existing defvars or defcustoms for these hooks.  (Unless you
checked for _all_ uses of `define-generic-mode' that there are none.
But how did you get a list of _all_ outside packages that use it?)

In the case of `define-minor-mode' two concrete examples of variables
with competing defcustoms are auto-revert-mode-hook and
global-auto-revert-mode-hook.  In this particular case, not too much
harm is done, but it is not exactly very clean.

   I primarily wanted to define the mode hook as a variable so that I
   could give it docstring.  I chose defcustom over defvar because
   define-minor-mode and quite some other major modes did that.  I don't
   strongly object to making the defcustom a defvar, but I don't
   understand your problems with the use of defcustom:

I have a problem with _both_ defvar and defcustom.  Hooks do not need
a defvar, most hooks do not have them.  The only reason for a defvar
is to add a docstring.  You use the defvar to give the hook the
docstring: "Hook run when entering Mymode mode.".  This "generic"
docstring contains no info that is not already contained in the hook's
name and it could overwrite _real_ info contained in a handwritten
defvar or defcustom.

If you want to make people aware of the mode hook, it would seem
better to put an additional sentence in the default mode doc:

"Mymode mode.
This a generic mode defined with `define-generic-mode'.
As all such modes, it runs `foo-mode-hook' as the very last thing it does."

   I don't recall the bugs you refer to; could you give me the subject(s)
   of the relevant thread(s)?

It is scattered over several threads.  Threads about Custom tend to be
superlong and unfocused. `find-file-hook as illustration of Custom problems'
is one of the threads, but several other threads about Custom were
going on at the same time and they all intertwined.

There are several problems, related to the fact that hooks have to be
customized using add-hook and remove-hook and not using setq.  But
Custom does use setq.  Here is an example of the type of problems that
occur.  (By no means the only one.)  The user customizes foo-hook
using Custom.  Then in the next Emacs version, a very essential
function badly-needed-fun is added to foo-hook.  The user's
custom-set-variables form overrides the adding of badly-needed-fun to
foo-hook.

These kind of problems are supposed to get fixed in 23 or 24, but it
is too tricky to still get it done for 22. 

Sincerely,

Luc.

Re: define-derived-mode

[Lute Kamstra]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Lute Kamstra wrote:
>
>    > which was an incompatible change.
>
>    Not compatible with what?
>
> With pre-existing defvars or defcustoms for these hooks.  (Unless you
> checked for _all_ uses of `define-generic-mode' that there are none.
> But how did you get a list of _all_ outside packages that use it?)

define-generic-mode is an all-in-one solution for defining a major
mode.  You call it, and every aspect of the major mode should be set
up.  I think it's very unlikely that anyone who uses
define-generic-mode will add a defvar for the mode hook.  (This
certainly isn't the case in Emacs' sources.)

> In the case of `define-minor-mode' two concrete examples of variables
> with competing defcustoms are auto-revert-mode-hook and
> global-auto-revert-mode-hook.  In this particular case, not too much
> harm is done, but it is not exactly very clean.
>
>    I primarily wanted to define the mode hook as a variable so that I
>    could give it docstring.  I chose defcustom over defvar because
>    define-minor-mode and quite some other major modes did that.  I don't
>    strongly object to making the defcustom a defvar, but I don't
>    understand your problems with the use of defcustom:
>
> I have a problem with _both_ defvar and defcustom.  Hooks do not need
> a defvar, most hooks do not have them.  The only reason for a defvar
> is to add a docstring.  You use the defvar to give the hook the
> docstring: "Hook run when entering Mymode mode.".  This "generic"
> docstring contains no info that is not already contained in the hook's
> name and it could overwrite _real_ info contained in a handwritten
> defvar or defcustom.
>
> If you want to make people aware of the mode hook, it would seem
> better to put an additional sentence in the default mode doc:
>
> "Mymode mode.
> This a generic mode defined with `define-generic-mode'.
> As all such modes, it runs `foo-mode-hook' as the very last thing it does."

Ok, that sounds reasonable.  I'll implement that.

>    I don't recall the bugs you refer to; could you give me the subject(s)
>    of the relevant thread(s)?
>
> It is scattered over several threads.  Threads about Custom tend to be
> superlong and unfocused. `find-file-hook as illustration of Custom problems'
> is one of the threads, but several other threads about Custom were
> going on at the same time and they all intertwined.
>
> There are several problems, related to the fact that hooks have to be
> customized using add-hook and remove-hook and not using setq.  But
> Custom does use setq.  Here is an example of the type of problems that
> occur.  (By no means the only one.)  The user customizes foo-hook
> using Custom.  Then in the next Emacs version, a very essential
> function badly-needed-fun is added to foo-hook.  The user's
> custom-set-variables form overrides the adding of badly-needed-fun to
> foo-hook.
>
> These kind of problems are supposed to get fixed in 23 or 24, but it
> is too tricky to still get it done for 22. 

Thanks for clarifying,

  Lute.

Re: define-derived-mode

[Luc Teirlinck]

>From my previous message:

   I am not really sure that it is such a great idea to have
   `define-minor-mode' and `define-generic-mode' spew out all these
   automatic defcustoms, but given that they do that, it seems rather
   strange and inconsistent that `define-derived-mode' does not.

On second thought, I now believe that the above is a bad idea.  It is
an incompatible change.  People may already have hand defined
defcustoms for these modes and making define-derived-mode construct
them automatically would lead to competing defcustoms, which would be
very bad.

Sincerely,

Luc.