emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bugs caused by recent use of define-derived-mode


From: Luc Teirlinck
Subject: Bugs caused by recent use of define-derived-mode
Date: Sun, 1 Sep 2002 21:37:26 -0500 (CDT)

There are two types of bugs related to define-derived-mode and its
recent increased use, including uses for purposes it was not
originally intended for.  The two types of bugs have similar symptoms,
but different causes.  Both can easily be fixed, but the best way to
fix the second one depends on some more general questions.  (Actually
there are three kinds of bugs, but fixing the first automatically
fixes the third.)

To investigate these types of bug, I believe one has to start by
temporarily "hiding" one's .abbrev_defs from emacs, for instance by
temporarily renaming it.  Then do emacs-21.3.50 -q.  (The bugs do not
occur in 21.2.90 or earlier versions.)  They are caused by recent new
uses of define-derived-mode in emacs21.3.50.

Do M-x list-abbrevs.

What is paragraph-indent-text-mode-abbrev-table doing in this list?
It is not there in 21.2.90.  How could the expansion of an abbrev
possibly depend on the details of paragraph indentation?  This is an
example of the first type of bugs.

Do C-x m.

M-x list-abbrevs.

Now a new abbrev-table has appeared, mail-mode-abbrev-table.  There is
no such abbrev-table.  Mail-mode uses the text-mode-abbrev-table.  Yet
M-x list-abbrevs or, worse, M-x edit-abbrevs give the user the
erroneous impression that there is a mail-mode-abbrev-table and that
if (s)he wants abbrevs to expand in mail-messages, that is the one
(s)he must use.  This is an example of the second type of bugs. 

There is no way for the user to find out that the senseless
paragraph-indent-text-mode-abbrev-table is "real" and the
mail-mode-abbrev-table (which actually would make at least slightly
more sense, though not enough) is a "fake", other than to read the
source code or to start experimenting.  The user also has no way of
knowing that abbrevs defined in the regular text-mode-abbrev-table may
or may not expand in paragraph-indent-text-mode, depending on whether
some other buffer using paragraph-indent-text-mode was created in the
meantime or not.  (This dependency is clearly in itself yet another,
third bug.)

The second type of bugs could potentially also create similar problems
for syntax-tables, because, with respect to this kind of bug, the code
for syntax-tables is broken in exactly the same way as the one for
abbrevs.  (See a later message.)  The first and third bugs are
abbrev-specific.

The first (as well as the third) type of bug is inherent in
define-derived-mode itself.  It just has recently become more
prevalent, due to the increased use of define-derived-mode.  It is the
easiest to fix.  Two modes that are very close should, in the vast
majority of cases, share the same abbrev table.  The user should not
have to wind up managing 1001 local abbrev tables, most of which are
nearly identical.  Mail mode is about as far removed from text mode as
any truly derived mode is going to be and it, correctly, uses the
same abbrev table as text mode.

Instead of trying to copy the parent mode's abbrev-table (and
producing bugs in the process) define-derived-mode should simply make
the derived mode use the parent's abbrev-table.  This is trivial to
do, it actually simplifies the current code.  It also automatically
gets rid of the third bug.

The remaining, second type of bug is not really a bug in
define-derived-mode itself.  Here the bug is in the (in my opinion)
inappropriate way define-derived-mode has been used recently.  This
type of bug can easily be fixed and similar bugs waiting to happen (or
to be discovered), related to syntax-tables can easily be avoided, but
the best way to do so depends on the larger question of how rigorously
one wants to standardize major modes and what the best way to do so is.
One completely trivial fix would be to simply return to the 21.2.90
situation.  However, there are other fixes which would not completely
give up on recent attempts at standardizing major mode definitions.  
I will expand on this in a subsequent message.

Sincerely,

Luc.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]