all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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

  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.