From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Emacs design question (was: run-mode-hooks) Date: Sun, 20 Jul 2003 19:07:00 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <200307141341.h6EDfxEd006523@rum.cs.yale.edu> <84wuei7jye.fsf_-_@lucy.is.informatik.uni-duisburg.de> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1058743217 11151 80.91.224.249 (20 Jul 2003 23:20:17 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Jul 2003 23:20:17 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Jul 21 01:20:10 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19eNTO-0002tb-00 for ; Mon, 21 Jul 2003 01:20:10 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19eNjl-0006qu-00 for ; Mon, 21 Jul 2003 01:37:05 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19eNOo-0006Aa-0O for emacs-devel@quimby.gnus.org; Sun, 20 Jul 2003 19:15:26 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19eNO6-0005ad-3t for emacs-devel@gnu.org; Sun, 20 Jul 2003 19:14:42 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19eNH4-0003Kk-1t for emacs-devel@gnu.org; Sun, 20 Jul 2003 19:07:26 -0400 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19eNGe-0003Ak-UE for emacs-devel@gnu.org; Sun, 20 Jul 2003 19:07:00 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.20) id 19eNGe-00055n-Nz; Sun, 20 Jul 2003 19:07:00 -0400 Original-To: kai.grossjohann@gmx.net (=?iso-8859-1?q?Kai_Gro=DFjohann?=) In-reply-to: <84wuei7jye.fsf_-_@lucy.is.informatik.uni-duisburg.de> (kai.grossjohann@gmx.net) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:15655 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:15655 >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.