Re: run-mode-hooks

Re: run-mode-hooks

[Richard Stallman]

    Yes, but as we talked about a while ago, I think the way to do
    that is to use a `define-major-mode' macro.  That macro would
    look very much like `define-derived-mode'.

I don't think we should insist that people use any particular
construct for all major modes.  It would be useful to write
a define-major-mode macro, but we should not decide to make
all major modes use it now.

So I think this means it is a good idea to change major modes
to use run-mode-hook now.

Emacs design question (was: run-mode-hooks)

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> I don't think we should insist that people use any particular
> construct for all major modes.  It would be useful to write
> a define-major-mode macro, but we should not decide to make
> all major modes use it now.

This example leads me to a question which is more general:

>From time to time I have found that you are opposed to introducing
(mandatory use of) additional abstraction levels.

In this case, you are suggesting that existing major modes continue
to do things "manually", rather than to use the new abstraction.
>From the past, I remember something similar about define-minor-mode
or define-derived-mode: there was a change to convert a mode to one
of them, and you reversed that change.  Obviously, you didn't want
the new abstraction to be used for all old cases.

I think that there is a lesson to be learned, but I fail to grok.

Can you (someone) enlighten me?

PS: Thanks for the lesson "eliminating duplication of code is not
    always desirable" that I learned some months ago when working on
    Tramp and discussing shell-quote-argument.

    Now I understand that developers' time spent on discussion is
    also a valuable resource that needs to be preserved.  When faced
    with the decision to rewrite some small amount of code such that
    there will be no problems at all, versus endless discussions of
    many developers about a small issue, one should just add the
    small piece of code and be done with it.
-- 
~/.signature

Re: Emacs design question (was: run-mode-hooks)

[Richard Stallman]

    >From time to time I have found that you are opposed to introducing
    (mandatory use of) additional abstraction levels.

Yes, I am reluctant to do this, because in my experience that approach
to software design quickly makes simple problems complex.  That is why,
for example, in Emacs we generally have primitive data types only
for jobs that couldn't possibly be done without one (because the C
code has to handle them specially).

I don't make this an absolute rule, because sometimes it is worth
adding a new data type or a new abstraction level.  But I'd rather
be slow to do this than quick to do this.

    In this case, you are suggesting that existing major modes continue
    to do things "manually", rather than to use the new abstraction.
    >From the past, I remember something similar about define-minor-mode
    or define-derived-mode: there was a change to convert a mode to one
    of them, and you reversed that change.

That is a completely different kind of issue. I objected to use of
define-derived-mode for a mode that was not derived.  I think that
contradicts what the name says.

I wouldn't object to defining a new define-major-mode construct and
using it for that mode.  I think it would be good to do this.
I don't want to make use of define-major-mode "mandatory" because
there are plenty of mode definitions that are not in our files, and
we can't change them all to use define-major-mode.

That being true, I don't see a reason to change all the modes in the
Emacs sources either.  However, it would be ok to change the ones
you feel like changing.

define-derived-mode again (was: Emacs design question)

[Stefan Monnier]

> That is a completely different kind of issue. I objected to use of
> define-derived-mode for a mode that was not derived.  I think that
> contradicts what the name says.

Well, other than the fact that fundamental-mode is interactive,
it is basically an alias for kill-all-local-variables, so the
coding-convention that says that a major mode should start by calling
kill-all-local-variables is pretty much the same as saying that
every major mode should derive from fundamental-mode.

Also the documentation of fundamental-mode mode says:

	Other major modes are defined by comparison with this one.

Many systems that offer inheritence take the view that there is
a single "root" and that you necessarily inherit from somewhere.
That's the reason why it doesn't bother me to say that every major
mode is derived from another.


	Stefan

Re: define-derived-mode again (was: Emacs design question)

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@cs.yale.edu> writes:
> Many systems that offer inheritence take the view that there is
> a single "root" and that you necessarily inherit from somewhere.
> That's the reason why it doesn't bother me to say that every major
> mode is derived from another.

How about:

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

After all, major modes are major modes, whether derived or not; really
I'd think this name would be a bit clearer than the current one, and
it's natural enough to use `nil' for PARENT for non-derived modes.

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: define-derived-mode again (was: Emacs design question)

[Richard Stallman]

    Well, other than the fact that fundamental-mode is interactive,
    it is basically an alias for kill-all-local-variables, so the
    coding-convention that says that a major mode should start by calling
    kill-all-local-variables is pretty much the same as saying that
    every major mode should derive from fundamental-mode.

I see your point, but I think it is useful to keep the distinction
between major modes that are independent and those that really
are derived from others.

Re: define-derived-mode again (was: Emacs design question)

[Richard Stallman]

    How about:

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

The two macros should not have the same calling convention.
define-major-mode should not have a parent argument.

Re: define-derived-mode again (was: Emacs design question)

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>       (defalias 'define-major-mode 'define-derived-mode)
> 
> The two macros should not have the same calling convention.
> define-major-mode should not have a parent argument.

Why?  It's certainly the case that some major-modes have `parent' modes,
and some don't; really, the fact that they're major modes seems far more
significant than that particular detail, so I'd think it would be _good_
that they use the same macro, as long as:

 (1) Its name is equally applicable in either case, and emphasizes
     what's important (that they're major modes); `define-derived-mode'
     falls down here because it emphasizes something that's (IMHO) a
     minor detail in the derived case, and arguably _false_ in the
     non-derived case.  `define-major-mode' has neither of these problems.

 (2) Using the same macro for both is not inconvenient for either case;
     personally I think an extra `nil' is not much of an inconvenience...

-Miles
-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Ghandi

Re: define-derived-mode again (was: Emacs design question)

[Stefan Monnier]

> >       (defalias 'define-major-mode 'define-derived-mode)
> > 
> > The two macros should not have the same calling convention.
> > define-major-mode should not have a parent argument.
> 
> Why?  It's certainly the case that some major-modes have `parent' modes,
> and some don't; really, the fact that they're major modes seems far more
> significant than that particular detail, so I'd think it would be _good_
> that they use the same macro, as long as:

As mentioned, in my view of the world, they all have a parent.
But this aside, we can also make the PARENT argument optional
(since it's always a symbol and the next arg (the mode's name) is
always a string).


	Stefan

Re: define-derived-mode again (was: Emacs design question)

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@cs.yale.edu> writes:
> But this aside, we can also make the PARENT argument optional
> (since it's always a symbol and the next arg (the mode's name) is
> always a string).

That's true... or alternatively, how about allowing the mode-name to be
a cons, like:

Non-derived case:

  (define-major-mode NAME "DOC" ...)

Derived case:

  (define-major-mode (NAME PARENT-NAME) "DOC" ...)

-Miles
-- 
I'd rather be consing.

Re: define-derived-mode again (was: Emacs design question)

[Richard Stallman]

    > The two macros should not have the same calling convention.
    > define-major-mode should not have a parent argument.

    Why?

Because there is no reason to specify a parent in define-major-mode.

Re: define-derived-mode again (was: Emacs design question)

[Richard Stallman]

    As mentioned, in my view of the world, they all have a parent.
    But this aside, we can also make the PARENT argument optional
    (since it's always a symbol and the next arg (the mode's name) is
    always a string).

Ok.

Re: define-derived-mode again (was: Emacs design question)

[Richard Stallman]

    Non-derived case:

      (define-major-mode NAME "DOC" ...)

    Derived case:

      (define-major-mode (NAME PARENT-NAME) "DOC" ...)

This is somewhat more elegant, but I think that in practice
it will be much cleaner if the first argument is always
the new mode name, uniformly.