From: Richard Stallman <rms@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Emacs design question (was: run-mode-hooks)
Date: Sun, 20 Jul 2003 19:07:00 -0400 [thread overview]
Message-ID: <E19eNGe-00055n-Nz@fencepost.gnu.org> (raw)
In-Reply-To: <84wuei7jye.fsf_-_@lucy.is.informatik.uni-duisburg.de> (kai.grossjohann@gmx.net)
>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.
next prev parent reply other threads:[~2003-07-20 23:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E19eNGe-00055n-Nz@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).