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 21:06:03 -0500 (CDT) Sender: emacs-devel-admin@gnu.org Message-ID: <200209040206.VAA28356@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 1031105207 17502 127.0.0.1 (4 Sep 2002 02:06:47 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 4 Sep 2002 02:06:47 +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 17mPZ8-0004YA-00 for ; Wed, 04 Sep 2002 04:06:46 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17mQ86-00008j-00 for ; Wed, 04 Sep 2002 04:42:55 +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 17mPae-0000e8-00; Tue, 03 Sep 2002 22:08:20 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17mPYU-0000Gc-00 for emacs-devel@gnu.org; Tue, 03 Sep 2002 22:06:06 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17mPYR-0000GJ-00 for emacs-devel@gnu.org; Tue, 03 Sep 2002 22:06:05 -0400 Original-Received: from manatee.dms.auburn.edu ([131.204.53.104]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17mPYR-0000GC-00 for emacs-devel@gnu.org; Tue, 03 Sep 2002 22:06:03 -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 VAA03360; Tue, 3 Sep 2002 21:06:02 -0500 (CDT) Original-Received: (from teirllm@localhost) by eel.dms.auburn.edu (8.9.3+Sun/8.9.3) id VAA28356; Tue, 3 Sep 2002 21:06:03 -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:7422 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7422 Stefan Monnier wrote: > I believe the current value of "nil" for PARENT should be > eliminated and replaced by a separate macro `define-major-mode', which > would be a true analogue of `define-minor-mode'. This would then > take over as the "standard" way to define a major mode. And what would be the benefit ? I know Richard hates `define-derived-mode' and wants a `define-major-mode' instead. My point is just that the two can be merged and that we can define `define-major-mode as an alias for `define-derived-mode' or if you really dislike the "nil" argument, you can just do (defmacro define-major-mode (mode name &optional docstring &rest body) `(define-derived-mode ,mode nil ,name ,docstring ,@body) > I propose to define a macro that would be called like this: > > (define-major-mode mymode name syntax-table abbrev-table mode-class > docstring body) What is the benefit of the current situation? It uses a macro for a purpose that is way more general than its original intended purpose and artificially forces two functionalities into one. It all seems very unnatural to me. Defining a separate define-major-mode in the way you suggest would be an improvement over the current situation. However, it still seems unnatural to define a very general function essentially as a special case of an extremely specialized function. It would be far more logical to do the opposite. I do not understand why you feel so strongly about this. Richard actually seems to agree with you in as far as the desirability of a standard function is concerned. So do I. This seems to be the really fundamental question. The rest are technical details. You extremely strongly seem to insist that this standard function should be a special case of define-derived-mode, which seems completely illogical. Why? What is the benefit of that? Sincerely, Luc.