Re: Bugs caused by recent use of define-derived-mode

[Luc Teirlinck]

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.