From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: Recent attempts at standardizing major mode definitions. Date: Mon, 02 Sep 2002 19:14:05 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <200209022314.g82NE5r08654@rum.cs.yale.edu> References: <200209020240.VAA26083@eel.dms.auburn.edu> <200209021651.g82Gpe007333@rum.cs.yale.edu> <200209022039.PAA26566@eel.dms.auburn.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1031008456 5648 127.0.0.1 (2 Sep 2002 23:14:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 2 Sep 2002 23:14:16 +0000 (UTC) Cc: 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 17m0Od-0001Sz-00 for ; Tue, 03 Sep 2002 01:14:15 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17m0x4-00041l-00 for ; Tue, 03 Sep 2002 01:49:50 +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 17m0QA-0000dI-00; Mon, 02 Sep 2002 19:15:50 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17m0OX-0000BK-00 for emacs-devel@gnu.org; Mon, 02 Sep 2002 19:14:09 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17m0OV-0000Al-00 for emacs-devel@gnu.org; Mon, 02 Sep 2002 19:14:09 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17m0OV-0000Ac-00 for emacs-devel@gnu.org; Mon, 02 Sep 2002 19:14:07 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g82NE5r08654; Mon, 2 Sep 2002 19:14:05 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Luc Teirlinck 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:7347 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7347 > Could please state clearly what are the bugs ? > I.e. a set of commands that shows a behavior you didn't expect ? > > M-x list-abbrevs > C-x m > M-x list-abbrevs > > I described the resulting behavior in my previous message. I did not > expect that behavior. Apparently you are claiming I should have > expected it. I disagree. I will respond to the more technical issues > you raised when I have more time to look at them. I don't think that the number of abbrev-tables listed at the end of the above commands is particularly important, so I fail to see what's the bug. That C-x m creates a new abbrev-table ? Well, yes, that's expected if C-x m uses another abbrev table. Note that with the patch I sent you (and applied to the trunk), there is no more bogus mail-mode-abbrev-table, so the above example is poorly chosen. > At present let me just say that the following and related parts of > your two messages look strange to me: > > As for abbrev-tables, they are suboptimally shared (via poor man's > inheritance) which is not that bad either. > > Expansion of an abbrev can depend on such things as the creation or > non-creation of unrelated buffers. Show us actual command sequences so we can assess how serious a problem this is. > Unless the user really knows your > code extremely well and, in addition to that, is willing to put up > with quite some inconvenience and be extremely attentive and careful, > abbrev expansion is essentially a lottery system. I am an Emacs user > and as a user, I consider this to be extremely bad, not just "a little > bit" bad. It seems strange to me that you seem to disagree with this. > (Or am I misunderstanding you?) Show us actual command sequences where the "lottery" behavior comes into play, please. I have the following requirements: - it must be easy for a user to add abbrevs that are available in all "related" modes. - it must be easy for a user to add abbrevs that are only available in a particular mode. - mode authors should be able to provide the above behavior without having to think about it (because they generally don't, especially since some of them don't even use abbrevs). Do you agree with these requirements and how do you imagine the system working ideally so that it provides the above requirements. I agree that the current lack of real inheritance between abbrevs makes the above basically impossible. I think what annoys you is that there is no information (apart from "in the code") about the relationship between various abbrev-tables. Of course, the information *is* available outside of the code, but IIRC only in the C-h m output, which is just not very helpful where you're doing M-x list-abbrevs. So maybe M-x list-abbrevs should be improved to clearly show inheritance relationships between abbrev-tables ? Stefan