From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Recent attempts at standardizing major mode definitions. Date: Tue, 3 Sep 2002 20:24:35 -0500 (CDT) Sender: emacs-devel-admin@gnu.org Message-ID: <200209040124.UAA28338@eel.dms.auburn.edu> References: <200209020240.VAA26083@eel.dms.auburn.edu> <200209021651.g82Gpe007333@rum.cs.yale.edu> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1031102654 13462 127.0.0.1 (4 Sep 2002 01:24:14 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 4 Sep 2002 01:24:14 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17mOtx-0003V0-00 for ; Wed, 04 Sep 2002 03:24:13 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17mPSv-0007dv-00 for ; Wed, 04 Sep 2002 04:00:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17mOvW-0002NL-00; Tue, 03 Sep 2002 21:25:50 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17mOuL-00029P-00 for emacs-devel@gnu.org; Tue, 03 Sep 2002 21:24:37 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17mOuJ-00025C-00 for emacs-devel@gnu.org; Tue, 03 Sep 2002 21:24:36 -0400 Original-Received: from manatee.dms.auburn.edu ([131.204.53.104]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17mOuI-000258-00 for emacs-devel@gnu.org; Tue, 03 Sep 2002 21:24:34 -0400 Original-Received: from eel.dms.auburn.edu (eel.dms.auburn.edu [131.204.53.108]) by manatee.dms.auburn.edu (8.9.1a/8.9.1) with ESMTP id UAA03314; Tue, 3 Sep 2002 20:24:33 -0500 (CDT) Original-Received: (from teirllm@localhost) by eel.dms.auburn.edu (8.9.3+Sun/8.9.3) id UAA28338; Tue, 3 Sep 2002 20:24:35 -0500 (CDT) X-Authentication-Warning: eel.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: monnier+gnu/emacs@rum.cs.yale.edu In-Reply-To: <200209021651.g82Gpe007333@rum.cs.yale.edu> (monnier+gnu/emacs@rum.cs.yale.edu) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:7418 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7418 Stefan Monnier wrote: > define-derived-mode is currently used for two barely compatible, in > many respects diametrically opposite purposes: Could you expand a little ? In what way are they diametrically opposed ? As I already said, one use is to define a major mode starting from a very closely related major mode. This is a very specialized situation. In such a very specialized situation it is "easy" (or, sometimes not so easy, as our discussion of inheritance versus using of the parent abbrev table shows) to make standard decisions for the author. This provides convenience for the author and consistency for the author. Unless I misunderstood you, which is very well possible, you implied in your previous message that you do not particularly care about this particular use (again, I might have misunderstood), but it is the original intended use and the code for a non-nil non-fundamental-mode PARENT clearly reflects that, even the code for a nil PARENT still does. The second use is as a standard way to define any major mode whatsoever. There is a tremendous variety in major modes. The level of generality is "diametrically opposite" to the previous situation. That is a very big difference. In this situation, you have to make only those decisions in advance, in the author's place, that you definitely want all major modes to make. The author can of course override any decision the macro makes, as you showed with examples, but the point is that (s)he should not have to worry about doing that. Some modes, like dired and other related should not have an abbrev-table for instance. (I believe I would have to make some change in my own proposed code to reflect that). There is a tremendous variety in major modes. Sincerely, Luc.