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.