From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
Cc: monnier+gnu/emacs@rum.cs.yale.edu, emacs-devel@gnu.org
Subject: Re: Recent attempts at standardizing major mode definitions.
Date: Mon, 02 Sep 2002 19:14:05 -0400 [thread overview]
Message-ID: <200209022314.g82NE5r08654@rum.cs.yale.edu> (raw)
In-Reply-To: 200209022039.PAA26566@eel.dms.auburn.edu
> 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
next prev parent reply other threads:[~2002-09-02 23:14 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-02 2:40 Recent attempts at standardizing major mode definitions Luc Teirlinck
2002-09-02 16:51 ` Stefan Monnier
2002-09-02 17:49 ` Kai Großjohann
2002-09-02 20:39 ` Luc Teirlinck
2002-09-02 23:14 ` Stefan Monnier [this message]
2002-09-04 0:59 ` Luc Teirlinck
2002-09-04 15:27 ` Stefan Monnier
2002-09-04 1:24 ` Luc Teirlinck
2002-09-04 15:25 ` Stefan Monnier
2002-09-05 2:46 ` Richard Stallman
2002-09-04 1:35 ` Luc Teirlinck
2002-09-04 15:24 ` Stefan Monnier
2002-09-04 21:52 ` Luc Teirlinck
2002-09-05 15:54 ` Stefan Monnier
2002-09-05 16:52 ` Luc Teirlinck
2002-09-05 17:15 ` Luc Teirlinck
2002-09-04 2:06 ` Luc Teirlinck
2002-09-04 15:40 ` Stefan Monnier
2002-09-04 22:36 ` Luc Teirlinck
2002-09-06 18:03 ` Stefan Monnier
2002-09-06 18:48 ` David Masterson
2002-09-06 22:53 ` Luc Teirlinck
2002-09-07 0:05 ` Luc Teirlinck
2002-09-07 2:47 ` Luc Teirlinck
2002-09-07 3:06 ` Luc Teirlinck
2002-09-03 13:26 ` Richard Stallman
2002-09-03 13:56 ` Mario Lang
2002-09-05 2:45 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200209022314.g82NE5r08654@rum.cs.yale.edu \
--to=monnier+gnu/emacs@rum.cs.yale.edu \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.