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

[Luc Teirlinck]

Miles Bader wrote:

   Luc Teirlinck <address@hidden> writes:
   > We should make a decision on this relatively quickly, as discussing
   > the technical details of other things such as a standard function to
   > define major modes is difficult if we do not know where we want to go
   > in terms of abbrev tables.

   It hardly seems like an urgent situation.  The _only_ complaint I've
   ever heard about the `abbrev table situation' is yours, and even you
   seem more bothered by the untidyness of it all rather than practically
   inconvenienced.

What I meant with the "relatively quickly" in this sentence is that we
are currently discussing other things such as standard command to
define major modes.  One consequence of the current template for such
a command, in its present form, is the introduction of inheritance
(true or simulated) for local abbrevs.  This would constitute a very
much user visible change.  It is difficult to keep discussing
technical aspects of such a command if we do not know where we want to
go with abbrevs.  The other aspects of such a command are mostly
"author visible". The abbrev ones are "user visible".

I am more concerned with clarifying my statements that the bugs need
to be fixed "reasonably soon" or "relatively urgently".  What I meant
is not that Emacs21.3.50 is unusable until they get fixed and that
they need to get fixed by next week or so.  That indeed would be a
very silly overstatement.  Sorry if I created the impression of saying
that.  What I meant was that in Emacs 21.2.90 and I presume in Emacs
21.3, these bugs are essentially absent because define-derived mode is
barely used there.  By "relatively urgently" I meant before the
release of Emacs 21.4 or whichever other release in which users would
first come extensively into contact with the new local abbrev
behavior.

The fact that the only complaint you heard about the bugs or the new
abbrev situation is mine is a very good thing.  You could not possibly
have heard tons of complaints about this, because current officially
released Emacs versions do not expose users to these bugs.  I believe
it is the purpose of Emacs21.3.50 to catch such bugs before users get
confronted with them in official releases.  What I meant with
"relatively urgent" is, again, that it is important to fix them before
they can get introduced in an official release.

Maybe I should also clarify that, contrarily to an earlier statement I
made, the fact that a lot of work would be involved is not my only
objection against inheritance or copying of abbrevs.  That work seems
to be a lot less than I originally feared.  A more fundamental
objection is the "1001 local abbrev tables" objections.  I believe
there currently already are too many local abbrev tables.  Copying or
inheritance is going to multiply their numbers.  The output of M-x
edit-abbrevs is already littered with tons of abbrev tables right now.
It could be getting a lot worse.

Sincerely,

Luc.