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

[Luc Teirlinck <teirllm@dms.auburn.edu>]

Miles Bader wrote:

   However, is all the mechanism you suggested necessary?
   Can't users just create their own local abbrev table in the mode hook (which
   define-derived-mode will make sure the command supports!)?

   If it's simple to do that, then we really needn't do anything at all...

If the only problem is that a user wants a mail-mode-abbrev-table that
is completely separate from the text-mode-abbrev-table, then that can
be customized very easily in .emacs right now.  If that is the only
problem then no changes whatsoever are required.

The problem occurs when a user wants to have both mail-mode abbrevs
and text-mode abbrevs expand in mail-mode.

I believe you have not been closely following the entire thread.  To
give a quick summary of the issues involved:

As it stands right now, define-derived-mode makes a new abbrev-table
and then tries to make that new abbrev table "inherit" from the parent
abbrev-table using a copying mechanism.  This mechanism has various
flaws, including outright bugs, that are difficult to fix.

My first proposal was to quite simply fix these problems by making the
derived mode use the parent abbrev table and get rid of copying
altogether.  This can be done using very minor changes (actually
simplifications) in define-derived-mode.  No further work needed.  End
of problem.

However, Stefan argued that the copying system addressed a real need
of people who were dissatisfied with text-mode-abbrev-table as
mail-mode's abbrev-table.  I have not seen the postings, so I do not
know what the people in question wanted, that is, if they would have
been satisfied with a completely separate mail-mode abbrev table.

Anyway, Stefan and Kai argued that "inheritance" for abbrev tables was
a useful feature.  I personally had several objections against it.
Richard voiced some additional objections.  Working with multiple
local abbrev tables is in my opinion the only "solid" way to implement
something with a functionality similar to "inheritance".  The system I
proposed gets rid of my own objections.  I believe it also addresses
the objections Richard raised.

There is one problem left.  Whichever solution we pick, somebody will
have to implement it.  That person will have to be careful not to
introduce bugs.  If bugs are introduced, somebody will need to fix
them.  The person or persons doing all that work could be doing other
things instead.

So, indeed the very first question is: 

Is there a real need to implement some form of "inheritance" for
abbrevs.

If there is a real need to keep the current abbrev behavior of
define-derived-mode, in any form, then the answer to the above
question would be yes.  If sufficiently many users felt a need for it,
the answer would be yes too.

The feature I propose is actually more general and flexible than
inheritance, but I believe it is also more easy to implement in a way
that is bug-free and does not introduce a variety of unintended and
very much user visible negative side effects.

Sincerely,

Luc.