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: Bugs caused by recent use of define-derived-mode Date: Wed, 4 Sep 2002 23:37:15 -0500 (CDT) Sender: emacs-devel-admin@gnu.org Message-ID: <200209050437.XAA01465@eel.dms.auburn.edu> References: <200209020237.VAA26080@eel.dms.auburn.edu> <200209021629.g82GTY707192@rum.cs.yale.edu> <200209022302.SAA26633@eel.dms.auburn.edu> <200209031506.g83F6Yh12528@rum.cs.yale.edu> <200209031536.KAA27166@eel.dms.auburn.edu> <200209032123.QAA28184@eel.dms.auburn.edu> <200209040001.TAA28292@eel.dms.auburn.edu> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1031200636 452 127.0.0.1 (5 Sep 2002 04:37:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 5 Sep 2002 04:37:16 +0000 (UTC) Cc: monnier+gnu/emacs@rum.cs.yale.edu, Kai.Grossjohann@CS.Uni-Dortmund.DE, monnier+gnu/emacs@rum.cs.yale.edu, 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 17moOG-000079-00 for ; Thu, 05 Sep 2002 06:37:12 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17moxm-0004DQ-00 for ; Thu, 05 Sep 2002 07:13:54 +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 17moPr-0006P7-00; Thu, 05 Sep 2002 00:38:51 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17moOQ-0006NG-00 for emacs-devel@gnu.org; Thu, 05 Sep 2002 00:37:22 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17moON-0006N4-00 for emacs-devel@gnu.org; Thu, 05 Sep 2002 00:37:21 -0400 Original-Received: from manatee.dms.auburn.edu ([131.204.53.104]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17moOL-0006Md-00; Thu, 05 Sep 2002 00:37:17 -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 XAA07980; Wed, 4 Sep 2002 23:37:14 -0500 (CDT) Original-Received: (from teirllm@localhost) by eel.dms.auburn.edu (8.9.3+Sun/8.9.3) id XAA01465; Wed, 4 Sep 2002 23:37:15 -0500 (CDT) X-Authentication-Warning: eel.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: rms@gnu.org In-Reply-To: (message from Richard Stallman on Wed, 04 Sep 2002 22:46:48 -0400) 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:7512 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7512 Richard Stallman wrote: This is an improvement over inheritance, but we still face the question of how the user should control which table to use for a newly defined abbrev. That is the crucial question. None of these ideas is acceptable if it doesn't come with a clean and convenient solution to that question. If I understand you correctly, we are talking about which abbrev-table C-x a l and C-x a i l should use. I see no obvious answer. It is an argument against inheritance of abbrevs. Here is the best solution I currently can think of. It definitely adds some complexity. I see no way to avoid that. With the extra complexity comes extra flexibility. I do not know whether or not the extra flexibility is worth the extra complexity. C-x a (i) l The first thing the user is asked before the name (expansion, respectively) of the abbrev, is which abbrev table to use. The most local abbrev table appears in the minibuffer as a default. The user can type M-p to get successively less local abbrev-tables. M-n goes into the "more local" direction. The user can also just type in a completely unrelated abbrev-table and define an abbrev in that one. For instance, the user could define a text-mode local abbrev inside some comment in a programming language. Essentially, the meaning of C-x a (i) l would be changed from "define a local abbrev in the current mode" to define a local abbrev in an abbrev-table to be specified, with all obvious candidates easily accessible. Again, this adds some complexity, but I believe we have absolutely no way of guessing which abbrev-table the user wants without asking him. So I do not know how we possibly could avoid asking an extra question. Of course, the positive point is that the extra complexity only occurs during the definition of abbrevs, not during their expansions. Unless the user uses abbrevs in a very inefficient way, expansion will occur much more often than definition. Sincerely, Luc.