Recent attempts at standardizing major mode definitions.

Recent attempts at standardizing major mode definitions.

[Luc Teirlinck]

Stefan Monnier wrote:

   PS: The elisp manual clearly says in the "major mode conventions"
   node to "Define a command whose name ends in `-mode'" so
   ibuffer-mode should be interactive.  I'd of course argue that it
   should use `define-derived-mode' which would have made it
   interactive as a matter of course without the programmer having to
   think about it.  As long as we don't use such a macro
   systematically, we'll have to live with all those inconsistencies.

It seems to me that in the present 21.3.50 code, define-derived-mode
is already used pretty systematically.  As I pointed out in another
message, this has lead to bugs. 

To avoid confusion: I am not at all opposed to "using such a macro
systematically", but I am very much opposed to using define-derived-mode
in its present form.  One reason is that the present use of this macro
has caused bugs in several modes.  (See my previous message.)  It is
not the only reason.

I believe that any macro that aims to standardize major mode definitions 
should under no condition prevent the writer of a major mode to do
anything that is not only not "forbidden" by the guidelines in the
Elisp manual, but that is even explicitly allowed by these guidelines,
and is very often in the best interest of the user.  Neither should
the macro make this unnecessarily difficult for him or her.

The ELisp manual clearly says that a major mode does not need to have
its own syntax-table or abbrev-table, but may share one with related
modes.  Especially in the case of abbrev-tables, it is in the user's
interest to share local abbrev-tables as much as possible between
closely related modes.  Yet, define-derived-mode makes it
unnecessarily tricky to share abbrev tables or syntax tables without
introducing the second type of bug I described in my previous message.

The Elisp manual also says that hooks of related modes may be ran just
before the mode's own hook OR that they may be ran earlier.  It seems
to me that define-derived-mode tries to enforce the first type of
behavior.

Apart from the bug-related objections and the "enforcement of
unnecessary or even counterproductive rules" objections, I also do not
like the way define-derived-mode amalgamates two barely related
functionalities into one macro.  Of course, one can always "save a
function definition" by combining two different functions into a
single macro that expands into the code of one or the other depending
on the value of some argument.  Whether it makes sense to actually do
so is a different question.

define-derived-mode is currently used for two barely compatible, in
many respects diametrically opposite purposes:

A way to make a very specialized, but common, task easy for people to
do, namely defining a barely different derived mode from a parent
mode.  I believe define-derived-mode serves this purpose well, except
for the fact that, as I pointed out in my previous message, it should
make the derived mode use the parent's abbrev table instead of
introducing bugs and confusion by trying to copy the parent's
abbrev-table.

The second, more recent purpose is as a "standard" way to define any
major mode whatsoever.  This is a completely different task.  I
believe that one should revert to the 21.2.90 behavior and no longer
make the code expand into something different when the parent mode is
fundamental-mode.  Some modes could truly differ so little from
fundamental-mode that they are "truly" derived modes of fundamental
mode.  I believe the current value of "nil" for PARENT should be
eliminated and replaced by a separate macro `define-major-mode', which
would be a true analogue of `define-minor-mode'.  This would then
take over as the "standard" way to define a major mode.

I propose to define a macro that would be called like this:

(define-major-mode mymode name syntax-table abbrev-table mode-class
docstring body)

(A proposed expansion is included below.)

Here, syntax-table and abbrev-table could be another mode's syntax or
abbrev-tables, or nil, in which case the mode gets its own syntax or
abbrev table.  This is one difference with the current code.  Another
is that now the author decides when other mode's hooks are ran.  Of
course, (s)he is perfectly free to choose the current solution in
body, (s)he is just not forced too.  Note that my code still runs
run-mode-hooks instead of run-hooks, so that, if I understand things
correctly, authors using `define-major-mode' would still be supporting
other people's use of delay-mode-hooks, even if they would choose not
to use that machinery themselves.  (I have not yet read through the
details of the source code of the functions involved in the
"delay-mode-hooks run-mode-hooks" machinery and their documentation
strings are imprecise and cryptic.)

There is still one thing I am hesitating about:

The Elisp manual says:

Major modes usually should have their own keymap...

There is a "usually" in this sentence.  So maybe define-major-mode
should also take a keymap argument.  This is a lot less clear than it
is for syntax-tables and abbrev-tables however.

To give a clearer idea of what I have in mind, here is what I envision
the macro (approximately) to expand into.  (I have not yet even tried
to debug this, because at this stage it is just a proposal.)  Note
that it is just an amended version of what define-derived-mode with a
PARENT of nil or fundamental-mode would expand into, but it eliminates
the second type of bug I reported in my previous message and it takes
care of all objections I formulated above.

(progn
  (defvar mymode-map
    (make-sparse-keymap))
  (unless syntax-table
    (defvar mymode-syntax-table
      (make-syntax-table)))
  (unless abbrev-table
    (defvar mymode-abbrev-table
      (progn
      (define-abbrev-table 'mymode-abbrev-table nil)
      mymode-abbrev-table)))
  (if mode-class
      (put 'mymode 'mode-class 'special))
  (put 'mymode 'derived-mode-parent 'nil)
  (defun mymode nil "docstring\n\nThis mode runs the hook
  `mymode-hook', as the final step\nduring
  initialization.\n\n\\{mymode-map}"
    (interactive)
    (kill-all-local-variables)
    (setq major-mode 'mymode)
    (setq mode-name name)
    (use-local-map mymode-map)
    (set-syntax-table (or syntax-table mymode-syntax-table))
    (setq local-abbrev-table (or abbrev-table mymode-abbrev-table))
    body
    (run-mode-hooks 'my-mode-hook)))

Re: Recent attempts at standardizing major mode definitions.

[Stefan Monnier]

> To avoid confusion: I am not at all opposed to "using such a macro
> systematically", but I am very much opposed to using define-derived-mode
> in its present form.  One reason is that the present use of this macro
> has caused bugs in several modes.  (See my previous message.)  It is
> not the only reason.

I haven't seen any actual bug in your previous message apart from
the bogus way mail-mode was made to use the text-mode-abbrev-table.
Thanks for that report, by the way.

> I believe that any macro that aims to standardize major mode definitions 
> should under no condition prevent the writer of a major mode to do
> anything that is not only not "forbidden" by the guidelines in the
> Elisp manual, but that is even explicitly allowed by these guidelines,
> and is very often in the best interest of the user.  Neither should
> the macro make this unnecessarily difficult for him or her.

That's obvious.

> The ELisp manual clearly says that a major mode does not need to have
> its own syntax-table or abbrev-table, but may share one with related
> modes.  Especially in the case of abbrev-tables, it is in the user's
> interest to share local abbrev-tables as much as possible between
> closely related modes.  Yet, define-derived-mode makes it
> unnecessarily tricky to share abbrev tables or syntax tables without
> introducing the second type of bug I described in my previous message.

Syntax-tables *are* shared via inheritance, so I don't see what you
mean by "unnecessarily tricky".
As for abbrev-tables, they are suboptimally shared (via poor man's
inheritance) which is not that bad either.  But we could change the
default indeed.
I think it's crucially important that

	(define-derived-mode foo-mode bar-mode "Foo"
	  "Doc"
	  (modify-syntax-entry ?; "<"))

doesn't change bar-mode-syntax-table, so I'd be opposed to changing
the default for syntax-tables.

> The Elisp manual also says that hooks of related modes may be run just
> before the mode's own hook OR that they may be ran earlier.  It seems
> to me that define-derived-mode tries to enforce the first type of behavior.

It doesn't try to enforce it, it just tries to make it possible
because that's what generally desired.  Do you have a counter-example ?

> define-derived-mode is currently used for two barely compatible, in
> many respects diametrically opposite purposes:

Could you expand a little ?  In what way are they diametrically opposed ?

> A way to make a very specialized, but common, task easy for people to
> do, namely defining a barely different derived mode from a parent
> mode.  I believe define-derived-mode serves this purpose well, except
> for the fact that, as I pointed out in my previous message, it should
> make the derived mode use the parent's abbrev table instead of
> introducing bugs and confusion by trying to copy the parent's
> abbrev-table.

I don't care much for this use, so I kept it "as it was".
Direct sharing of abbrev-table could be done and might indeed be better,
although it would be an imcompatible change.  I'll let others decide.

> The second, more recent purpose is as a "standard" way to define any
> major mode whatsoever.  This is a completely different task.

In what way is it completely different ?

> I believe that one should revert to the 21.2.90 behavior and no longer
> make the code expand into something different when the parent mode is
> fundamental-mode.

Any reason for it ?  I hope you realize that `fundamental-mode'
is an alias for `kill-all-local-variables'.  The special-treatment
of fundamental-mode is an *optimization* (i.e. should not make
*any* difference in terms of behavior).

> Some modes could truly differ so little from fundamental-mode that
> they are "truly" derived modes of fundamental mode.

Sure.  And the current macro will deal with it just fine.
Or do you have evidence to the contrary ?

> I believe the current value of "nil" for PARENT should be
> eliminated and replaced by a separate macro `define-major-mode', which
> would be a true analogue of `define-minor-mode'.  This would then
> take over as the "standard" way to define a major mode.

And what would be the benefit ?
I know Richard hates `define-derived-mode' and wants a `define-major-mode'
instead.  My point is just that the two can be merged and that we can
define `define-major-mode as an alias for `define-derived-mode'
or if you really dislike the "nil" argument, you can just do

  (defmacro define-major-mode (mode name &optional docstring &rest body)
    `(define-derived-mode ,mode nil ,name ,docstring ,@body)

> I propose to define a macro that would be called like this:
> 
> (define-major-mode mymode name syntax-table abbrev-table mode-class
> docstring body)

I believe it's good to follow the convention that the syntax-table for
mode foo is found in foo-mode-syntax-table, so I think it's a good idea
for define-major-mode to use foo-mode-syntax-table as the syntax-table
rather than to take it as an argument.

> The Elisp manual says:
> 
> Major modes usually should have their own keymap...
> 
> There is a "usually" in this sentence.  So maybe define-major-mode
> should also take a keymap argument.  This is a lot less clear than it
> is for syntax-tables and abbrev-tables however.

  (defvar foo-mode-map bar-mode-map)
  (define-derived-mode foo-mode bar-mode "Foo" "Doc")

will make foo-mode use bar-mode-map directly, so define-derived-mode
does not force you to use your own keymap.  Same thing holds for syntax-table
and abbrev-table of course.  And for keymap and syntax-tables this is
rarely (if ever) needed since inheritance provides pretty much the same
sharing advantages while at the same time still allowing mode-specific
changes.


	Stefan

Re: Recent attempts at standardizing major mode definitions.

[Kai Großjohann]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> As for abbrev-tables, they are suboptimally shared (via poor man's
> inheritance) which is not that bad either.  But we could change the
> default indeed.

Is it difficult to implement `proper' inheritance for abbrev tables?

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Recent attempts at standardizing major mode definitions.

[Luc Teirlinck]

Stefan Monnier wrote:

   Could please state clearly what are the bugs ?
   I.e. a set of commands that shows a behavior you didn't expect ?

M-x list-abbrevs
C-x m
M-x list-abbrevs

I described the resulting behavior in my previous message.  I did not
expect that behavior.  Apparently you are claiming I should have
expected it.  I disagree.  I will respond to the more technical issues
you raised when I have more time to look at them.

At present let me just say that the following and related parts of
your two messages look strange to me:

   As for abbrev-tables, they are suboptimally shared (via poor man's
   inheritance) which is not that bad either.

Expansion of an abbrev can depend on such things as the creation or
non-creation of unrelated buffers.  Unless the user really knows your
code extremely well and, in addition to that, is willing to put up
with quite some inconvenience and be extremely attentive and careful,
abbrev expansion is essentially a lottery system.  I am an Emacs user
and as a user, I consider this to be extremely bad, not just "a little
bit" bad.  It seems strange to me that you seem to disagree with this.
(Or am I misunderstanding you?)

Sincerely,

Luc.

Re: Recent attempts at standardizing major mode definitions.

[Stefan Monnier]

>    Could please state clearly what are the bugs ?
>    I.e. a set of commands that shows a behavior you didn't expect ?
> 
> M-x list-abbrevs
> C-x m
> M-x list-abbrevs
> 
> I described the resulting behavior in my previous message.  I did not
> expect that behavior.  Apparently you are claiming I should have
> expected it.  I disagree.  I will respond to the more technical issues
> you raised when I have more time to look at them.

I don't think that the number of abbrev-tables listed at the end
of the above commands is particularly important, so I fail to
see what's the bug.
That C-x m creates a new abbrev-table ?
Well, yes, that's expected if C-x m uses another abbrev table.
Note that with the patch I sent you (and applied to the trunk),
there is no more bogus mail-mode-abbrev-table, so the above example
is poorly chosen.

> At present let me just say that the following and related parts of
> your two messages look strange to me:
> 
>    As for abbrev-tables, they are suboptimally shared (via poor man's
>    inheritance) which is not that bad either.
> 
> Expansion of an abbrev can depend on such things as the creation or
> non-creation of unrelated buffers.

Show us actual command sequences so we can assess how serious a problem
this is.

> Unless the user really knows your
> code extremely well and, in addition to that, is willing to put up
> with quite some inconvenience and be extremely attentive and careful,
> abbrev expansion is essentially a lottery system.  I am an Emacs user
> and as a user, I consider this to be extremely bad, not just "a little
> bit" bad.  It seems strange to me that you seem to disagree with this.
> (Or am I misunderstanding you?)

Show us actual command sequences where the "lottery" behavior
comes into play, please.

I have the following requirements:
- it must be easy for a user to add abbrevs that are available in
  all "related" modes.
- it must be easy for a user to add abbrevs that are only available in
  a particular mode.
- mode authors should be able to provide the above behavior without
  having to think about it (because they generally don't, especially
  since some of them don't even use abbrevs).

Do you agree with these requirements and how do you imagine the system
working ideally so that it provides the above requirements.

I agree that the current lack of real inheritance between abbrevs
makes the above basically impossible.  I think what annoys you
is that there is no information (apart from "in the code") about
the relationship between various abbrev-tables.
Of course, the information *is* available outside of the code,
but IIRC only in the C-h m output, which is just not very helpful
where you're doing M-x list-abbrevs.
So maybe M-x list-abbrevs should be improved to clearly show inheritance
relationships between abbrev-tables ?


	Stefan

Re: Recent attempts at standardizing major mode definitions.

[Richard Stallman]

    The second, more recent purpose is as a "standard" way to define any
    major mode whatsoever.

Stefan started using define-derived-mode for this, but I rejected the
idea.  He had already converted a few modes, and not all of them have
been changed back.

Defining a macro define-major-mode might be a good idea.

      (put 'mymode 'derived-mode-parent 'nil)

There is no need for that--nil is the default.

      (defun mymode nil "docstring\n\nThis mode runs the hook
      `mymode-hook', as the final step\nduring
      initialization.\n\n\\{mymode-map}"

We don't always want to use \\{...} in every major mode doc string.

    Major modes usually should have their own keymap...

    There is a "usually" in this sentence.  So maybe define-major-mode
    should also take a keymap argument.  This is a lot less clear than it
    is for syntax-tables and abbrev-tables however.

Would you like to look at all the major modes and see which ones don't
have keymaps?  It could be that fundamental-mode is the only one.

Re: Recent attempts at standardizing major mode definitions.

[Mario Lang]

Richard Stallman <rms@gnu.org> writes:

>     The second, more recent purpose is as a "standard" way to define any
>     major mode whatsoever.

[...]

> Defining a macro define-major-mode might be a good idea.

While we are at it, I recently noticed that there is
no way to get a list of valid major-modes.

There are alot of tricks one can use, but I didnt find a reliable
method to generate a list of major-modes.

If we convert to some standard macro, what do people
think of adding something like this to it?

(put mode 'major-mode t)



-- 
CYa,
  Mario

Re: Recent attempts at standardizing major mode definitions.

[Luc Teirlinck]

I see that yesterday I forgot to answer the following question:

Stefan Monnier wrote:

   I have the following requirements:
   - it must be easy for a user to add abbrevs that are available in
     all "related" modes.

Definitely, that is essential.

   - it must be easy for a user to add abbrevs that are only available in
     a particular mode.

If the mode is not related to any other mode and is not a read-only
type mode, say dired, help buffer, info and so on, definitely.
Otherwise, I am hesitating as I already mentioned.

   - mode authors should be able to provide the above behavior without
     having to think about it (because they generally don't, especially
     since some of them don't even use abbrevs).

They can not do it completely without thinking.  They have to make a
decision about which abbrev tables to use, regardless of whether we
implement inheritance.  It is possible that say an abbrev table of a
mode is perfectly suitable for another mode even if the syntax-table
of another mode is more suitable as the parent syntax table.  Such
situations can occur.  I would rather have somebody who never uses
abbrevs think about which abbrev-table to use, than, say , have
somebody who never uses font-lock worry about font-lock-defaults.

Re: Recent attempts at standardizing major mode definitions.

[Luc Teirlinck]

Stefan Monnier wrote:

   > define-derived-mode is currently used for two barely compatible, in
   > many respects diametrically opposite purposes:

   Could you expand a little ?  In what way are they diametrically opposed ?

As I already said, one use is to define a major mode starting from a
very closely related major mode.  This is a very specialized
situation.  In such a very specialized situation it is "easy" (or,
sometimes not so easy, as our discussion of inheritance versus using
of the parent abbrev table shows) to make standard decisions for the
author.  This provides convenience for the author and consistency for
the author.

Unless I misunderstood you, which is very well possible, you implied
in your previous message that you do not particularly care about this
particular use (again, I might have misunderstood), but it is the
original intended use and the code for a non-nil non-fundamental-mode
PARENT clearly reflects that, even the code for a nil PARENT still
does. 

The second use is as a standard way to define any major mode
whatsoever. There is a tremendous variety in major modes.  The level
of generality is "diametrically opposite" to the previous situation.
That is a very big difference.  In this situation, you have to make
only those decisions in advance, in the author's place, that you
definitely want all major modes to make.  The author can of course
override any decision the macro makes, as you showed with examples,
but the point is that (s)he should not have to worry about doing that.
Some modes, like dired and other related should not have an
abbrev-table for instance.  (I believe I would have to make some
change in my own proposed code to reflect that).  There is a
tremendous variety in major modes.

Sincerely,

Luc.

Re: Recent attempts at standardizing major mode definitions.

[Luc Teirlinck]

Stefan Monnier wrote:

   > I believe that one should revert to the 21.2.90 behavior and no longer
   > make the code expand into something different when the parent mode is
   > fundamental-mode.

   Any reason for it ?  I hope you realize that `fundamental-mode'
   is an alias for `kill-all-local-variables'.  The special-treatment
   of fundamental-mode is an *optimization* (i.e. should not make
   *any* difference in terms of behavior).

I know that fundamental-mode is just an alias for
`kill-all-local-variables'.  But there are other differences between
the two expansions than the fact that fundamental-mode is not
explicitly called, for instance in the treatment of abbrev tables.

Sincerely,

Luc.

Re: Recent attempts at standardizing major mode definitions.

[Luc Teirlinck]

Stefan Monnier wrote:

   > I believe the current value of "nil" for PARENT should be
   > eliminated and replaced by a separate macro `define-major-mode', which
   > would be a true analogue of `define-minor-mode'.  This would then
   > take over as the "standard" way to define a major mode.

   And what would be the benefit ?
   I know Richard hates `define-derived-mode' and wants a `define-major-mode'
   instead.  My point is just that the two can be merged and that we can
   define `define-major-mode as an alias for `define-derived-mode'
   or if you really dislike the "nil" argument, you can just do

     (defmacro define-major-mode (mode name &optional docstring &rest body)
       `(define-derived-mode ,mode nil ,name ,docstring ,@body)

   > I propose to define a macro that would be called like this:
   > 
   > (define-major-mode mymode name syntax-table abbrev-table mode-class
   > docstring body)

What is the benefit of the current situation?  It uses a macro for a
purpose that is way more general than its original intended purpose
and artificially forces two functionalities into one.  It all seems
very unnatural to me.

Defining a separate define-major-mode in the way you suggest would be
an improvement over the current situation.  However, it still seems
unnatural to define a very general function essentially as a special
case of an extremely specialized function.  It would be far more
logical to do the opposite.

I do not understand why you feel so strongly about this.  Richard
actually seems to agree with you in as far as the desirability of a
standard function is concerned.  So do I.  This seems to be the really
fundamental question.  The rest are technical details.  You extremely
strongly seem to insist that this standard function should be a
special case of define-derived-mode, which seems completely illogical.
Why?  What is the benefit of that?

Sincerely,

Luc.

Re: Recent attempts at standardizing major mode definitions.

[Stefan Monnier]

>    > I believe that one should revert to the 21.2.90 behavior and no longer
>    > make the code expand into something different when the parent mode is
>    > fundamental-mode.
> 
>    Any reason for it ?  I hope you realize that `fundamental-mode'
>    is an alias for `kill-all-local-variables'.  The special-treatment
>    of fundamental-mode is an *optimization* (i.e. should not make
>    *any* difference in terms of behavior).
> 
> I know that fundamental-mode is just an alias for
> `kill-all-local-variables'.  But there are other differences between
> the two expansions than the fact that fundamental-mode is not
> explicitly called, for instance in the treatment of abbrev tables.

If there is a difference, it's a bug, so please report it.


	Stefan

Re: Recent attempts at standardizing major mode definitions.

[Stefan Monnier]

> Some modes, like dired and other related should not have an
> abbrev-table for instance.

I agree that it's silly to have an abbrev table for dired modes.
I suggested a few months back to add a :special keyword argument
for special modes (i.e. modes with a 'mode-class 'special property)
which would turn off the automatic creation of abbrev-table and
syntax-table.
I don't think it's a majo problem to create an abbrev-table for
dired, tho.  If someone is silly enough to try and add abbrevs
to it, he gets what he deserves.

> There is a tremendous variety in major modes.

No there isn't, really.  There's a tremendous of ways that major
modes are poorly setup because authors don't follow the conventions,
yes.  Call it "variety", I call it "bugs".


	Stefan

Re: Recent attempts at standardizing major mode definitions.

[Stefan Monnier]

> I see that yesterday I forgot to answer the following question:
> 
> Stefan Monnier wrote:
> 
>    I have the following requirements:
>    - it must be easy for a user to add abbrevs that are available in
>      all "related" modes.
> 
> Definitely, that is essential.
> 
>    - it must be easy for a user to add abbrevs that are only available in
>      a particular mode.
> 
> If the mode is not related to any other mode and is not a read-only
> type mode, say dired, help buffer, info and so on, definitely.

latex-mode is definitely related to plain-tex-mode which is definitely
related to text-mode and yet I want to have abbrevs specifically for
the Tex and LaTeX languages.
As for read-only buffers, abbrevs are irrelevant there anyway.

> Otherwise, I am hesitating as I already mentioned.
> 
>    - mode authors should be able to provide the above behavior without
>      having to think about it (because they generally don't, especially
>      since some of them don't even use abbrevs).
> 
> They can not do it completely without thinking.  They have to make a
> decision about which abbrev tables to use, regardless of whether we
> implement inheritance.  It is possible that say an abbrev table of a
> mode is perfectly suitable for another mode even if the syntax-table
> of another mode is more suitable as the parent syntax table.  Such
> situations can occur.  I would rather have somebody who never uses
> abbrevs think about which abbrev-table to use, than, say , have
> somebody who never uses font-lock worry about font-lock-defaults.

Many authors just don't think about abbrevs at all, so you end up
with either no abbrev-table or with some default.  I just want the
default to be as close to possible to the most likely "ideal".
A new table that inherits from the parent is a pretty damn good default,
if you ask me.


	Stefan

Re: Recent attempts at standardizing major mode definitions.

[Stefan Monnier]

> What is the benefit of the current situation?  It uses a macro for a
> purpose that is way more general than its original intended purpose
> and artificially forces two functionalities into one.  It all seems
> very unnatural to me.

I don't just want a standard macro.  I want this macro to strongly
encourage a "standard" behavior so that users can expect things to
work consistently, so that macro has to (by default) do more than
the strict necessary, although it (of course) needs to be flexible
enough to allow those defaults to be overridden (which the current
`define-derived-mode' does allow although not always in the most
natural/convenient way).

Many authors forget to setup an abbrev-table.
Many authors forget to run hooks.
Other authors forget to run kill-all-local-variables.
Others don't use a `foo-mode-map' variable.
Yet others don't use a `foo-mode-syntax-table' variable.
Some authors don't notice that their mode should derive from text-mode.
Others do notice but derive the mode in incorrect ways (or at
least in inconsistent ways).
Most authors don't seem to realize that just like there is a text-mode
from which most text-like editing modes derive, there should be a prog-mode
from which most programming modes derive.
...

> Defining a separate define-major-mode in the way you suggest would be
> an improvement over the current situation.  However, it still seems
> unnatural to define a very general function essentially as a special
> case of an extremely specialized function.  It would be far more
> logical to do the opposite.

Sure.  Except that define-derived-mode would pretty much do the same
things as define-derived-mode and since define-derived-mode exists,
it seems a good idea to use it.  Especially since I truly think that
modes should derive much less often from nil than they currently do.
Take a look at the expansion of define-derived-mode when the
PARENT is nil.


	Stefan

Re: Recent attempts at standardizing major mode definitions.

[Luc Teirlinck]

Stefan Monnier wrote:

   If there is a difference, it's a bug, so please report it.

Sorry, I should have thought about that possibility.  I assumed the
difference was deliberate.  I include a transcript of an ielm session.
First we define my-mode as a derived mode of text-mode, then as a
derived mode of fundamental-mode.  text-mode's abbrev table gets
copied, fundamental-mode's not.  I believe that whatever behavior for
abbrevs we decide on, the behavior should be the same for both, if we
are talking about a "true" derived mode of fundamental-mode.

===File ~/derivedstuff======================================
*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (emacs-version)
"GNU Emacs 21.3.50.1 (i686-pc-linux-gnu, X toolkit)\n of 2002-09-01 on swt40.swt.com"
ELISP> (macroexpand `(define-derived-mode my-mode text-mode "Mymode" "docstring" (defvar mymode-var 1)))
(progn
  (defvar my-mode-map
    (make-sparse-keymap))
  (defvar my-mode-syntax-table
    (make-syntax-table))
  (defvar my-mode-abbrev-table
    (progn
      (define-abbrev-table 'my-mode-abbrev-table nil)
      my-mode-abbrev-table))
  (put 'my-mode 'derived-mode-parent 'text-mode)
  (defun my-mode nil "docstring\n\nIn addition to any hooks its parent mode `text-mode' might have run,\nthis mode runs the hook `my-mode-hook', as the final step\nduring initialization.\n\n\\{my-mode-map}"
    (interactive)
    (delay-mode-hooks
     (text-mode)
     (setq major-mode 'my-mode)
     (setq mode-name "Mymode")
     (progn
       (if
	   (get 'text-mode 'mode-class)
	   (put 'my-mode 'mode-class
		(get 'text-mode 'mode-class)))
       (unless
	   (keymap-parent my-mode-map)
	 (set-keymap-parent my-mode-map
			    (current-local-map)))
       (let
	   ((parent
	     (char-table-parent my-mode-syntax-table)))
	 (unless
	     (and parent
		  (not
		   (eq parent
		       (standard-syntax-table))))
	   (set-char-table-parent my-mode-syntax-table
				  (syntax-table))))
       (when local-abbrev-table
	 (mapatoms
	  (lambda
	    (symbol)
	    (or
	     (intern-soft
	      (symbol-name symbol)
	      my-mode-abbrev-table)
	     (define-abbrev my-mode-abbrev-table
	       (symbol-name symbol)
	       (symbol-value symbol)
	       (symbol-function symbol))))
	  local-abbrev-table)))
     (use-local-map my-mode-map)
     (set-syntax-table my-mode-syntax-table)
     (setq local-abbrev-table my-mode-abbrev-table)
     (defvar mymode-var 1))
    (run-mode-hooks 'my-mode-hook)))

ELISP> (macroexpand `(define-derived-mode my-mode fundamental-mode "Mymode" "docstring" (defvar mymode-var 1)))
(progn
  (defvar my-mode-map
    (make-sparse-keymap))
  (defvar my-mode-syntax-table
    (make-syntax-table))
  (defvar my-mode-abbrev-table
    (progn
      (define-abbrev-table 'my-mode-abbrev-table nil)
      my-mode-abbrev-table))
  (put 'my-mode 'derived-mode-parent 'nil)
  (defun my-mode nil "docstring\n\nThis mode runs the hook `my-mode-hook', as the final step\nduring initialization.\n\n\\{my-mode-map}"
    (interactive)
    (delay-mode-hooks
     (kill-all-local-variables)
     (setq major-mode 'my-mode)
     (setq mode-name "Mymode")
     nil
     (use-local-map my-mode-map)
     (set-syntax-table my-mode-syntax-table)
     (setq local-abbrev-table my-mode-abbrev-table)
     (defvar mymode-var 1))
    (run-mode-hooks 'my-mode-hook)))

ELISP> 
============================================================

Re: Recent attempts at standardizing major mode definitions.

[Luc Teirlinck]

Stefan Monnier wrote:

   although it (of course) needs to be flexible enough to allow those
   defaults to be overridden (which the current `define-derived-mode'
   does allow although not always in the most natural/convenient way).

Yes, but the question is, do we allow them to override by choosing a
more general function or do we force them to use "tricks".  The former
is not only much more convenient for the author, it also avoids the
extremely real possibility of those "tricks" introducing bugs and
unintended side effects.  Overriding with a separate function seems
much more natural.  We get two functions: 

1. define-derived-mode, to be used if either the author is not sure
which values to plug in for the arguments of define-major-mode or if
the new mode is a "true" derived mode.

2. A more general function define-major-mode, if the author needs more
flexibility.



   Many authors forget to setup an abbrev-table.

define-major-mode will have an abbrev-table argument.  End of problem.
The author can explicitly choose not to have an abbrev-table, but
(s)he can not do it without thinking.

   Many authors forget to run hooks.

define-major-mode will run the standard mode-hook as the very last
thing it does.

   Other authors forget to run kill-all-local-variables.

define-major-mode will call that function just as define-derived-mode
does.

   Others don't use a `foo-mode-map' variable.

Either this will be set automatically or the author will have to
explicitly ask for this not to be done.

   Yet others don't use a `foo-mode-syntax-table' variable.

Will only work if the author explicitly asks not to use it.

   Some authors don't notice that their mode should derive from text-mode.
   Others do notice but derive the mode in incorrect ways (or at
   least in inconsistent ways).
   Most authors don't seem to realize that just like there is a text-mode
   from which most text-like editing modes derive, there should be a prog-mode
   from which most programming modes derive.

define-derived-mode does not solve that problem.  The author still
has to choose the parent mode and that choice could be stupid.

define-major-mode will have more arguments than define-derived-mode
does and forces the author to worry about all kinds of stuff.  If
(s)he does not need flexibility, (s)he will choose
define-derived-mode.  We could, and maybe should, have the two
documentation strings refer to each other, thus making sure that the
author knows that (s)he has a less complex (more flexible,
respectively) function available.

   Take a look at the expansion of define-derived-mode when the
   PARENT is nil.

I did.  As I pointed out, the piece of code I sent was essentially an
adaptation of that expansion.  It was just a rough draft, however.  It
needs to be changed to take care of Richard's remarks and problems I
myself discovered in the meantime.  Of course, it could also be
changed to take care of any objections you have.  Remember though that
define-major-mode is intended for knowledgeable authors and should
work for a-typical modes.

Sincerely,

Luc.

Re: Recent attempts at standardizing major mode definitions.

[Richard Stallman]

    If we convert to some standard macro, what do people
    think of adding something like this to it?

    (put mode 'major-mode t)

It could be a good idea, but note that it won't work perfectly;
there will continue to be user-written major modes that are implemented
the old way and don't use this macro.

Re: Recent attempts at standardizing major mode definitions.

[Richard Stallman]

    The second use is as a standard way to define any major mode
    whatsoever.

define-derived-mode is NOT the standard way to define all major modes.
Quite the contrary, our standard is not to use define-derived-mode
except for modes that are derived from other nontrivial modes.

Re: Recent attempts at standardizing major mode definitions.

[Stefan Monnier]

> derived mode of fundamental-mode.  text-mode's abbrev table gets
> copied, fundamental-mode's not.  I believe that whatever behavior for

Oh, I see.  I didn't know there was a fundamental-mode-abbrev-table.
How odd!
fundamental-mode has no local keymap, no hook, no nothing (basically)
but it has its own abbrev-table.

Does anybody know why there is such a thing ?


	Stefan

Re: Recent attempts at standardizing major mode definitions.

[Luc Teirlinck]

Sefan Monnier wrote:

   Oh, I see.  I didn't know there was a fundamental-mode-abbrev-table.
   How odd!
   fundamental-mode has no local keymap, no hook, no nothing (basically)
   but it has its own abbrev-table.

   Does anybody know why there is such a thing ?

Yes.  Before Emacs21, there was no fundamental-mode-abbrev-table, but
a fundamental-mode-abbrev-table was listed in the output of M-x
edit-abbrevs.  I pointed out to Gerd that this was inconsistent.
Either that table should be defined or it should not be listed.
Otherwise people might try to use it.  I actually tried exactly that
to construct a test case for Gerd concerning some other abbrev related
bug.  Gerd decided that the correct way to resolve the inconsistency
was to define a fundamental-mode-abbrev-table.  Clearly, you seem to
disagree with that decision.  I personally only use
fundamental-mode-abbrev-table to investigate bugs.  I do obviously not
save these abbrevs to .abbrev_defs.  I clearly could use other local
abbrev-tables to investigate bugs.  Normally, my
fundamental-mode-abbrev-table is empty.  However, since it is defined
now and people could be using it, I believe it would, at the present
stage, be unwise to try to reverse Gerd's decision.

Of course, the argument can be made that any abbrev general enough to
expand in fundamental-mode should actually be defined as a global
abbrev.  However, anybody who, in spite of this, nevertheless finds
some use for fundamental-mode-abbrev-table can use it. Other people
can just ignore it.

Sincerely,

Luc.

Re: Recent attempts at standardizing major mode definitions.

[Luc Teirlinck]

From my previous message:

   Yes.  Before Emacs21, there was no fundamental-mode-abbrev-table,

Actually, if I remember correctly, there was a
fundamental-mode-abbrev-table, even before Emacs21.  However, due to a
bug in the C code, it did not get set to the local abbrev table in
fundamental-mode.  In other words, it was theoretically defined, but
invisible to ordinary users.  Gerd fixed the bug in the C code.

Sincerely,

Luc.

Re: Recent attempts at standardizing major mode definitions.

[Stefan Monnier]

> Yes, but the question is, do we allow them to override by choosing a
> more general function or do we force them to use "tricks".

There are other alternatives than tricks.

> the new mode is a "true" derived mode.

What's a "true" derived mode ?
Is latex-mode a true derived mode of text-mode ?
Should c-mode be a true derived mode of prog-mode ?
Should dired-mode be a true derived mode of list-mode ?

> 2. A more general function define-major-mode, if the author needs more
> flexibility.

Are you saying that if we have

	(defalias 'define-major-mode 'define-derived-mode)

we can't make define-major-mode more flexible ?
I definitely think define-derived-mode should be more flexible
and intend to do exactly that, using keyword arguments.

>    Many authors forget to setup an abbrev-table.
> 
> define-major-mode will have an abbrev-table argument.

Oh so now, you macro will have umpteen arguments ?
Why not use CL-style keyword arguments instead ?
Then your calling-convention will be more friendly and compatible
with the current define-derived-mode calling convention.

>    Others don't use a `foo-mode-map' variable.
> Either this will be set automatically or the author will have to
> explicitly ask for this not to be done.

Sounds like define-derived-mode can (and clumsily does) behave
exactly like that already.  I don't think the clumsiness is a big
problem, since it's extremely rare to have a major mode that
shouldn't have its own keymap.  I actually can't think of any
case right now.

>    Yet others don't use a `foo-mode-syntax-table' variable.
> Will only work if the author explicitly asks not to use it.

Again, define-derived-mode behaves just like what you describe.

>    Some authors don't notice that their mode should derive from text-mode.
>    Others do notice but derive the mode in incorrect ways (or at
>    least in inconsistent ways).
>    Most authors don't seem to realize that just like there is a text-mode
>    from which most text-like editing modes derive, there should be a prog-mode
>    from which most programming modes derive.
> 
> define-derived-mode does not solve that problem.

The problem is that I think we should have more structure and sharing
between modes and that if we fix that, then 99% of the modes will
derive from some other.  That's why I think it's not even worthwhile
to define `define-major-mode' as an alias for `define-derived-mode'.

> define-major-mode will have more arguments than define-derived-mode
> does and forces the author to worry about all kinds of stuff.

Why would you want to impose such a burden on the programmer when
there are perfectly fine defaults available ?

>    Take a look at the expansion of define-derived-mode when the
>    PARENT is nil.
> 
> I did.

And you noticed that it's pretty much exactly the same as what you
suggested, so what's the point of your separate function ?

> define-major-mode is intended for knowledgeable authors and should
> work for a-typical modes.

Can you give me examples of atypical modes ?
I know about special modes such as dired/help/... but AFAIK, the only
"problem" with using define-derived-mode for them is that it uselessly
creates an abbrev-table which you can't use unless you first make the
buffer read-write.


	Stefan

Re: Recent attempts at standardizing major mode definitions.

[David Masterson]

>>>>> Stefan Monnier writes:

> What's a "true" derived mode ?
> Is latex-mode a true derived mode of text-mode ?
> Should c-mode be a true derived mode of prog-mode ?
> Should dired-mode be a true derived mode of list-mode ?

I'm jumping in a little bit here without knowing the whole thread, so
forgive a possibly dumb question.

The object-oriented answer to your first question would be that a
"true" derived mode would be one that uses one or more other modes for
"base" functionality and then adds to, or overrides some of, the base
functionality with new functions.  Done correctly, it could encourage
encapsulation and reuse.

Shouldn't the answer to your other three questions be "yes"?

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Recent attempts at standardizing major mode definitions.

[Luc Teirlinck]

Stefan Monnier wrote:

   Are you saying that if we have

	   (defalias 'define-major-mode 'define-derived-mode)

   we can't make define-major-mode more flexible ?
   I definitely think define-derived-mode should be more flexible
   and intend to do exactly that, using keyword arguments.

I actually do believe that it can be made flexible enough, but from
previous messages it seemed to me you were not willing to go far
enough in that direction.  I describe below what would make it
acceptable as a standard to me.  Only Richard can answer the much more
important question of whether that would make it acceptable to him.
Richard has clearly stated that define-derived-mode in its present
form is unacceptable to him as a standard way to define a major mode.

To me, the important thing is the following:

As long as authors adhere to all standards described in the Elisp
manual, they should be able to easily override any default behavior
you specify, using arguments.  Most of these arguments should probably
be CL style keywords arguments.  Authors should mot be forced to write
extra code to override defaults.

The reasons for that are plenty.  We should not inconvenience major
mode writers who adhere to all standards.  Any extra code is extra
risk for bugs or "nuisance features".  The extra code makes the source
code more difficult to understand and debug.

In other words I do not want the macro-expanded code to look like:

;;author code
(prevent-action2)
(prevent-part1-of-action3)
;;macro-written code
(defun my-mode ()
   ...
   (action1)
   (action2)
   (action3)
;;author code
   (undo-action1)
   (undo-part2-of-action3)
   (alternative-action1)
    ......

Instead I would like it to look like this (all macro-written code):

(defun my-mode ()
  ...
  (if argument1 (action1 argument1) (default-action1))
   .......

or similar.

Of course the arguments could be CL style keyword arguments.

As long as there are situations where the default should be
overwritten, we should not decide that these situation are too
infrequent to worry about.  As long as there is at least one such
situation, there will be others, whether we are able to think about
them or not.

To give you an idea of the flexibility needed, I quote part of the
reaction Richard had to my proposed code.  (The relevant part of my
proposed code was literally taken over from define-derived-mode's
expansion.)

	  (defun mymode nil "docstring\n\nThis mode runs the hook
	  `mymode-hook', as the final step\nduring
	  initialization.\n\n\\{mymode-map}"

    We don't always want to use \\{...} in every major mode doc string.

One could put in a CL style keyword argument that would enable an
author to override this.

    Can you give me examples of atypical modes ?

I do not know which modes Richard is talking about and why \\{...}
would be inappropriate for them, but I would guess such modes would
qualify as a-typical, because for typical modes \\{...} would be
appropriate.

Further suggestions (these are details):

Maybe the docstring should automatically list the abbrev-table and
syntax-table used by the mode.  I believe that would be very useful.

I like Mario Lang's suggestion:

add:

(put mode 'major-mode t)

to the macro expansion.

Richard seemed to like it too, although, as Richard pointed out, as
long as the standard is not universally followed, it will not work
perfectly.

Sincerely,

Luc.

Re: Recent attempts at standardizing major mode definitions.

[Luc Teirlinck]

From my previuos message:

   Instead I would like it to look like this (all macro-written code):

   (defun my-mode ()
     ...
     (if argument1 (action1 argument1) (default-action1))
      .......

   or similar.

"it" referring to the expansion of the macro.  Of course, a better
alternative would be to have the expansion depend on the argument.  I
was forgetting that we are talking about a macro.

Sincerely,

Luc.

Re: Recent attempts at standardizing major mode definitions.

[Luc Teirlinck]

To be more precise, I believe define-major-mode's arguments should
include name (required), docstring (optional), :group, syntax-table
(optional or keyword), abbrev-table (optional or keyword), some
keyword inhibiting automatic inclusion of \\{...} in the docstring,and
maybe :keymap and :mode-class keywords.  The abbrev-table argument
should accept a value requesting no abbrev-table.  This is important
for several modes.  If define-derived-mode were redefined like that,
it seems to me that it would be more logical to rename it
define-major-mode and define define-derived-mode as a special case of
it with an extra argument of parent and several keywords pre-plugged in.

Sincerely,

Luc.

Re: Recent attempts at standardizing major mode definitions.

[Luc Teirlinck]

Maybe using keywords :syntax-table and :abbrev-table makes more sense
than having them as optional arguments.  (Defaults: its own
syntax-table and own abbrev table)

Sincerely,

Luc.