all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Re: run-mode-hooks
       [not found] ` <200307141341.h6EDfxEd006523@rum.cs.yale.edu>
@ 2003-07-16 10:31   ` Richard Stallman
  2003-07-16 12:08     ` Emacs design question (was: run-mode-hooks) Kai Großjohann
  0 siblings, 1 reply; 13+ messages in thread
From: Richard Stallman @ 2003-07-16 10:31 UTC (permalink / raw)
  Cc: emacs-devel

    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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Emacs design question (was: run-mode-hooks)
  2003-07-16 10:31   ` run-mode-hooks Richard Stallman
@ 2003-07-16 12:08     ` Kai Großjohann
  2003-07-20 23:07       ` Richard Stallman
  0 siblings, 1 reply; 13+ messages in thread
From: Kai Großjohann @ 2003-07-16 12:08 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Emacs design question (was: run-mode-hooks)
  2003-07-16 12:08     ` Emacs design question (was: run-mode-hooks) Kai Großjohann
@ 2003-07-20 23:07       ` Richard Stallman
  2003-07-21 14:51         ` define-derived-mode again (was: Emacs design question) Stefan Monnier
  0 siblings, 1 reply; 13+ messages in thread
From: Richard Stallman @ 2003-07-20 23:07 UTC (permalink / raw)
  Cc: emacs-devel

    >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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* define-derived-mode again (was: Emacs design question)
  2003-07-20 23:07       ` Richard Stallman
@ 2003-07-21 14:51         ` Stefan Monnier
  2003-07-22  5:06           ` Miles Bader
  2003-07-22 15:12           ` Richard Stallman
  0 siblings, 2 replies; 13+ messages in thread
From: Stefan Monnier @ 2003-07-21 14:51 UTC (permalink / raw)
  Cc: Kai Großjohann, emacs-devel

> 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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: define-derived-mode again (was: Emacs design question)
  2003-07-21 14:51         ` define-derived-mode again (was: Emacs design question) Stefan Monnier
@ 2003-07-22  5:06           ` Miles Bader
  2003-07-23  7:13             ` Richard Stallman
  2003-07-22 15:12           ` Richard Stallman
  1 sibling, 1 reply; 13+ messages in thread
From: Miles Bader @ 2003-07-22  5:06 UTC (permalink / raw)
  Cc: Kai Großjohann, Richard Stallman, emacs-devel

"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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: define-derived-mode again (was: Emacs design question)
  2003-07-21 14:51         ` define-derived-mode again (was: Emacs design question) Stefan Monnier
  2003-07-22  5:06           ` Miles Bader
@ 2003-07-22 15:12           ` Richard Stallman
  1 sibling, 0 replies; 13+ messages in thread
From: Richard Stallman @ 2003-07-22 15:12 UTC (permalink / raw)
  Cc: kai.grossjohann, emacs-devel

    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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: define-derived-mode again (was: Emacs design question)
  2003-07-22  5:06           ` Miles Bader
@ 2003-07-23  7:13             ` Richard Stallman
  2003-07-23  7:36               ` Miles Bader
  0 siblings, 1 reply; 13+ messages in thread
From: Richard Stallman @ 2003-07-23  7:13 UTC (permalink / raw)
  Cc: kai.grossjohann, monnier+gnu/emacs, emacs-devel

    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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: define-derived-mode again (was: Emacs design question)
  2003-07-23  7:13             ` Richard Stallman
@ 2003-07-23  7:36               ` Miles Bader
  2003-07-23 13:27                 ` Stefan Monnier
  2003-07-24 19:58                 ` Richard Stallman
  0 siblings, 2 replies; 13+ messages in thread
From: Miles Bader @ 2003-07-23  7:36 UTC (permalink / raw)
  Cc: kai.grossjohann, monnier+gnu/emacs, emacs-devel

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: define-derived-mode again (was: Emacs design question)
  2003-07-23  7:36               ` Miles Bader
@ 2003-07-23 13:27                 ` Stefan Monnier
  2003-07-24  2:31                   ` Miles Bader
  2003-07-24 19:59                   ` Richard Stallman
  2003-07-24 19:58                 ` Richard Stallman
  1 sibling, 2 replies; 13+ messages in thread
From: Stefan Monnier @ 2003-07-23 13:27 UTC (permalink / raw)
  Cc: kai.grossjohann, emacs-devel, rms, monnier+gnu/emacs

> >       (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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: define-derived-mode again (was: Emacs design question)
  2003-07-23 13:27                 ` Stefan Monnier
@ 2003-07-24  2:31                   ` Miles Bader
  2003-07-25  8:00                     ` Richard Stallman
  2003-07-24 19:59                   ` Richard Stallman
  1 sibling, 1 reply; 13+ messages in thread
From: Miles Bader @ 2003-07-24  2:31 UTC (permalink / raw)
  Cc: kai.grossjohann, rms, emacs-devel

"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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: define-derived-mode again (was: Emacs design question)
  2003-07-23  7:36               ` Miles Bader
  2003-07-23 13:27                 ` Stefan Monnier
@ 2003-07-24 19:58                 ` Richard Stallman
  1 sibling, 0 replies; 13+ messages in thread
From: Richard Stallman @ 2003-07-24 19:58 UTC (permalink / raw)
  Cc: kai.grossjohann, monnier+gnu/emacs, emacs-devel

    > 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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: define-derived-mode again (was: Emacs design question)
  2003-07-23 13:27                 ` Stefan Monnier
  2003-07-24  2:31                   ` Miles Bader
@ 2003-07-24 19:59                   ` Richard Stallman
  1 sibling, 0 replies; 13+ messages in thread
From: Richard Stallman @ 2003-07-24 19:59 UTC (permalink / raw)
  Cc: miles, kai.grossjohann, monnier+gnu/emacs, emacs-devel

    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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: define-derived-mode again (was: Emacs design question)
  2003-07-24  2:31                   ` Miles Bader
@ 2003-07-25  8:00                     ` Richard Stallman
  0 siblings, 0 replies; 13+ messages in thread
From: Richard Stallman @ 2003-07-25  8:00 UTC (permalink / raw)
  Cc: kai.grossjohann, monnier+gnu/emacs, emacs-devel

    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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2003-07-25  8:00 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <E19c0Fd-0004sD-DC@fencepost.gnu.org>
     [not found] ` <200307141341.h6EDfxEd006523@rum.cs.yale.edu>
2003-07-16 10:31   ` run-mode-hooks Richard Stallman
2003-07-16 12:08     ` Emacs design question (was: run-mode-hooks) Kai Großjohann
2003-07-20 23:07       ` Richard Stallman
2003-07-21 14:51         ` define-derived-mode again (was: Emacs design question) Stefan Monnier
2003-07-22  5:06           ` Miles Bader
2003-07-23  7:13             ` Richard Stallman
2003-07-23  7:36               ` Miles Bader
2003-07-23 13:27                 ` Stefan Monnier
2003-07-24  2:31                   ` Miles Bader
2003-07-25  8:00                     ` Richard Stallman
2003-07-24 19:59                   ` Richard Stallman
2003-07-24 19:58                 ` Richard Stallman
2003-07-22 15:12           ` Richard Stallman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.