Re: Recent attempts at standardizing major mode definitions.

[Stefan Monnier]

>    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