Bugs caused by recent use of define-derived-mode

Bugs caused by recent use of define-derived-mode

[Luc Teirlinck]

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.

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

[Stefan Monnier]

> 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?

Could please state clearly what are the bugs ?
I.e. a set of commands that shows a behavior you didn't expect ?

> It is not there in 21.2.90.

So what ?

> 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.

The only problem with it is that if you change text-mod-abbrev-table, it
will not be immediately propagated to paragraph-indent-text-mode-abbrev-table
because we don't have inheritance of abbrev-tables, so define-derived-mode
only simulates it by copying the abbrev-table of the parent.

> 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

That's a bug in mail-mode, then.  See appended patch.

> 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.

There is no fake abbrev-table.  It's just a bug.

> 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.)

That is a more serious problem, as mentioned earlier:
abbrev-tables should be able to inherit from each other.

> 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.

Not at all.  Syntax-tables provide real inheritance (just like keymaps)
and thus do not suffer from the same problems.  Of course, there might
still be problems, but then I'd welcome a real bug-report.

> 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.

I'm not sure it's correct.  There has already been people on gnu.emacs.help
asking why they can't define abbrevs that are specific to their mail buffers.

> 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.

We could do that indeed.  I don't have a preference either way, as long
as it's easy for the code-author to choose whether to create a new
abbrev-table or to use the parent's (it's pretty easy right now (see patch)
but it is biased towards creating new abbrev-tables).


	Stefan


--- sendmail.el.~1.256.~	Tue May 21 19:43:31 2002
+++ sendmail.el	Mon Sep  2 12:22:47 2002
@@ -473,6 +473,7 @@
   :type 'hook
   :options '(footnote-mode))
 
+(defvar mail-mode-abbrev-table text-mode-abbrev-table)
 ;;;###autoload
 (define-derived-mode mail-mode text-mode "Mail"
   "Major mode for editing mail to be sent.
@@ -489,7 +490,6 @@
 \\[mail-sent-via]  mail-sent-via (add a Sent-via field for each To or CC).
 Turning on Mail mode runs the normal hooks `text-mode-hook' and
 `mail-mode-hook' (in that order)."
-  (setq local-abbrev-table text-mode-abbrev-table)
   (make-local-variable 'mail-reply-action)
   (make-local-variable 'mail-send-actions)
   (setq buffer-offer-save t)

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

[Luc Teirlinck]

There are two questions raised by my previous bug report.  I only
address one here:

Is inheritance of abbrev tables desirable or needed?  Inheritance of
abbrev tables would essentially be equivalent to the introduction of
"recursively super-local abbrevs".  I doubt I would use such a feature
myself.  Of course everybody may have his or her own ways to use
local abbrevs and maybe other people could find it useful.  

As long as inheritance of abbrevs would be defined in a bug-free way
that does not inconvenience anybody who does not want to use it, it
would of course be perfectly OK to do that.  Note however, that this
would require additional changes, for instance in the way 
M-x list-abbrevs lists abbrevs (otherwise, it would get hopelessly
cluttered by countlessly repeated abbrev definitions).

To me, it seems like a lot of work with very little benefit, but, of
course, other people can disagree with me on that.

The fact is though that currently we do not have inheritance of
abbrevs.  I believe that the current "poor man's inheritance" is an
unacceptable alternative.  It makes a lottery out of abbrev expansion.

If we decide NOT to go for true inheritance, or at least not in the
very immediate future, then it seems clear to me that closely related
modes should use the same abbrev-table.  As long as there is no true
inheritance I consider the existence of a
paragraph-indent-text-mode-abbrev-table an "annoying feature" (to
avoid the b-word).

Stefan's patch takes indeed care of the mail-mode-abbrev-table bug  (I
can safely use the b-word here, since Stefan actually agreed it was a
bug.)  There actually was a related "nuisance feature" for
syntax-tables, but since Stefan's patch can be used for that one too,
I do not see any reason to expand on this. 

One last remark:

Stefan Monnier wrote:

   I'm not sure it's correct.  There has already been people on
   gnu.emacs.help asking why they can't define abbrevs that are
   specific to their mail buffers.

Are you sure they were asking that because they really wanted that
feature or because they were confused by the fact that mailabbrev.el
mistakenly claimed that there was a mail-mode-abbrev-table?

Sincerely,

Luc.

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

[Stefan Monnier]

> Is inheritance of abbrev tables desirable or needed?  Inheritance of
> abbrev tables would essentially be equivalent to the introduction of
> "recursively super-local abbrevs".  I doubt I would use such a feature
> myself.  Of course everybody may have his or her own ways to use
> local abbrevs and maybe other people could find it useful.

Either people are annoyed "why does this mode use another abbrev-table
than that mode" or they're complaining that "I can't define an abbrev
in this mode without it being also defined in that mode".

Inheritance is the way to reconcile the two.

> The fact is though that currently we do not have inheritance of
> abbrevs.  I believe that the current "poor man's inheritance" is an
> unacceptable alternative.  It makes a lottery out of abbrev expansion.

Again, please show us examples.

> modes should use the same abbrev-table.  As long as there is no true
> inheritance I consider the existence of a
> paragraph-indent-text-mode-abbrev-table an "annoying feature" (to
> avoid the b-word).

I'd call it a misfeature even with true inheritance, actually.

> bug.)  There actually was a related "nuisance feature" for
> syntax-tables, but since Stefan's patch can be used for that one too,
> I do not see any reason to expand on this.

I'd love for you to expand on it.  So you're saying that the default
behavior of `define-derived-mode' w.r.t syntax-tables introduces problem
but that using

	(defvar foo-mode-syntax-table bar-mode-syntax-table)
	(define-derived-mode foo-mode bar-mode "foo" "doc")

works around the problem ?  Could you describe the problem ?

> Stefan Monnier wrote:
> 
>    I'm not sure it's correct.  There has already been people on
>    gnu.emacs.help asking why they can't define abbrevs that are
>    specific to their mail buffers.
> 
> Are you sure they were asking that because they really wanted that
> feature or because they were confused by the fact that mailabbrev.el
> mistakenly claimed that there was a mail-mode-abbrev-table?

There was no mail-mode-abbrev-table at all at that point.


	Stefan

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

[Luc Teirlinck]

Stefan Monnier wrote:

   There was no mail-mode-abbrev-table at all at that point.

Of course not, but the point is that mailabbrev.el claimed there was
one.  That is exactly what I believed confused users.

I will expand on more technical points later.

Sincerely,

Luc.

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

[Stefan Monnier]

>    There was no mail-mode-abbrev-table at all at that point.
> Of course not, but the point is that mailabbrev.el claimed there was
> one.  That is exactly what I believed confused users.

No, there *really* wasn't one (that was before Emacs-21.1, it's
those complaints that lead me to use define-derived-mode so as
to provide (as a side-effect) a separate abbrev-table.  This was
improperly undone later by adding the (setq l-a-t t-m-a-t)).

Before my latest patch, there definitely was a mail-mode-abbrev-table.
It just wasn't used, but it was definitely there.


	Stefan

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

[Luc Teirlinck]

Dear Stefan,

This is starting to look like an Abbott and Costello sketch.  It
really is not that important, but if we have trouble understanding
each other over something so trivial, what will happen if we start
discussing more complicated stuff?

   No, there *really* wasn't one (that was before Emacs-21.1,

Does "there *really* was not one" mean that those users were using
versions of Emacs in which the documentation for mailabbrev.el was NOT
claiming (again, claiming, incorrectly claiming) that there was a
mail-mode-abbrev-table, even though there was not one in reality.

If I do not understand your next answer, I will just give up and start
looking at the more technical stuff, hoping for less confusion there.

Sincerely,

Luc.

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

[Stefan Monnier]

> >   No, there *really* wasn't one (that was before Emacs-21.1,
> Does "there *really* was not one" mean that those users were using

They wanted to set up abbrevs in mail-mode and wanted them not to appear
in text-mode.  The rest is irrelevant.


	Stefan

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

[Luc Teirlinck]

   > The fact is though that currently we do not have inheritance of
   > abbrevs.  I believe that the current "poor man's inheritance" is an
   > unacceptable alternative.  It makes a lottery out of abbrev expansion.

   Again, please show us examples.

C-x b text
M-x text-mode
Type:
William
C-x a l bob
Type:
Robert
C-x a l bob
Redefine?
y
C-x b pidtext
M-x paragraph-indent-text-mode
Type:
bob
C-x '
Expansion: Robert.
Wonderful.

Start the exercise over, say with a new emacs.

C-x b text
M-x text-mode
Type:
William
C-x a l bob
C-x b pidtext1
M-x paragraph-indent-text-mode
C-x k
(Back in buffer text)
Type:
Robert
C-x a l bob
Redefine?
y
C-x b pidtext2
M-x paragraph-indent-text-mode
Type:
bob
C-x '
Expansion: William
Less wonderful

There are several variations on this.  The "real" example of this is,
of course, in a long editing session where you do not remember which
files or buffers you visited when and in which mode.  Then it becomes
a lottery.

I could tell you what causes this bug, but I believe you will have no
difficulty figuring that out yourself.  The really difficult thing is
to fix this bug, without introducing others to replace it.  I believe
this is essentially equivalent with defining true inheritance.

Sincerely,

Luc.

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

[Luc Teirlinck]

   > bug.)  There actually was a related "nuisance feature" for
   > syntax-tables, but since Stefan's patch can be used for that one too,
   > I do not see any reason to expand on this.

   I'd love for you to expand on it.  So you're saying that the default
   behavior of `define-derived-mode' w.r.t syntax-tables introduces problem
   but that using

	   (defvar foo-mode-syntax-table bar-mode-syntax-table)
	   (define-derived-mode foo-mode bar-mode "foo" "doc")

   works around the problem ?  Could you describe the problem ?

Maybe we disagree again on whether it actually is a problem or not.  I
believe it is, even though the absence of an analogue of M-x list-abbrevs
for syntax-tables makes it less serious than the analogous problem for
abbrev-tables.  Just to clear up in advance the main thing that seems
to be confusing you: it has absolutely nothing to do with inheritance.

From the "unpatched" mailabbrev:

(define-derived-mode mail-mode text-mode "Mail"
  "Long Docstring"
  (setq local-abbrev-table text-mode-abbrev-table)

What is the problem here?
Your macro defined a mail-mode-abbrev-table.
The first line of the body makes this mail-mode-abbrev-table into
never to be collected garbage.  The existence of this garbage variable
may confuse the user, who might not realize that it is garbage.
The fact that M-x list-abbrevs lists the garbage variable makes it
easier for the user to get confused, but there are other ways the user
could discover about this variable and get confused.

If I would replace 

(setq local-abbrev-table text-mode-abbrev-table)

with

(set-syntax-table text-mode-syntax-table)

then I would equally well reduce the mail-mode-syntax-table, already
defined at this stage by the macro, into never to be collected
garbage.  There are ways for the user to come into contact with this
variable and get confused by it, although I must admit that the
absence of a M-x list-abbrevs analogue for syntax-tables makes this
less likely.

(defvar mail-mode-syntax-table text-mode-syntax-table)

would make take away the uncollectible garbage status of
mail-mode-syntax-table as well as any danger of misleading the user.

Sincerely,

Luc.

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

[Stefan Monnier]

> If I would replace 
> (setq local-abbrev-table text-mode-abbrev-table)
> with
> (set-syntax-table text-mode-syntax-table)

Oh, that's what you were referring to.  Yes the above would be a bug,
just as it was in mail-mode.


	Stefan

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

[Stefan Monnier]

>    > The fact is though that currently we do not have inheritance of
>    > abbrevs.  I believe that the current "poor man's inheritance" is an
>    > unacceptable alternative.  It makes a lottery out of abbrev expansion.
>    Again, please show us examples.

[..example cut out..]

So it indeed involves editing an abbrev-table.  Thanks.

> I could tell you what causes this bug, but I believe you will have no
> difficulty figuring that out yourself.  The really difficult thing is
> to fix this bug, without introducing others to replace it.  I believe
> this is essentially equivalent with defining true inheritance.

Yes, those problems can be fixed by implementing true inheritance.


	Stefan

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

[Richard Stallman]

One idea for how to fix the abbrev-table bugs is to modify
define-derived-mode to accept some optional keywords as arguments
before the body.  :same-abbrev-table could mean to use the parent's
abbrev table unmodified, and :same-syntax-table would do likewise for
the syntax table.

This change would be upward compatible for existing calls to
define-derived-mode that work correctly.

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

[Kai Großjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> As long as inheritance of abbrevs would be defined in a bug-free way
> that does not inconvenience anybody who does not want to use it, it
> would of course be perfectly OK to do that.  Note however, that this
> would require additional changes, for instance in the way 
> M-x list-abbrevs lists abbrevs (otherwise, it would get hopelessly
> cluttered by countlessly repeated abbrev definitions).

Let A and B be abbrev tables such that B inherits from A.  Let a be
an abbrev defined in A (expanding to aaa), let b be an abbrev defined
in B (expanding to bbb).

Then it seems obvious that the desired behavior for M-x list-abbrevs
RET is to list abbrev a under table A and abbrev b under table B, and
that abbrev a should not be listed under table B (nor should abbrev b
be listed under table A).

It also seems useful for M-x list-abbrevs RET to make clear that B
inherits from A so that people who are looking for B abbrevs will know
to also look in the A table.  (Maybe with a hyperlink-like button that
jumps to the right spot.  But other user interfaces are possible.  If
no table inherits from more than one table, then the inheritance
hierarchy is a tree and a tree widget can be used for displaying
them.)

If there is an abbrev x in table A expanding to xxx, and x is also
defined in table B but expanding to something else, yyy, say, then it
seems that list-abbrevs should list x twice, with different
expansions, under the two tables.

I was under the assumption that all of these obvious things are clear
to Stefan, as well, and that, unless explicitly mentioned, he was
proposing to implement the desired behavior.  (I'd have expected
words like "kludge" or "workaround" in case he was speaking about
something that does not implement the desired behavior.)

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

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

[Stefan Monnier]

> One idea for how to fix the abbrev-table bugs is to modify
> define-derived-mode to accept some optional keywords as arguments
> before the body.  :same-abbrev-table could mean to use the parent's
> abbrev table unmodified, and :same-syntax-table would do likewise for
> the syntax table.

That's something we need indeed.  I for one would need/want a :group
argument as well.


	Stefan

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

[Stefan Monnier]

> I was under the assumption that all of these obvious things are clear
> to Stefan, as well, and that, unless explicitly mentioned, he was
> proposing to implement the desired behavior.  (I'd have expected

Yes, except that I'm not offering to implement it ;-)


	Stefan

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

[Luc Teirlinck]

Stefan Monnier wrote:

   > I was under the assumption that all of these obvious things are clear
   > to Stefan, as well, and that, unless explicitly mentioned, he was
   > proposing to implement the desired behavior.  (I'd have expected

   Yes, except that I'm not offering to implement it ;-)


	   Stefan

I have only one single problem with abbrev inheritance and it is right
above.  There is work to be done.  It would have to be done reasonably
quickly, because the current copying system is badly broken.  I am
actually even more worried about all the "obvious things" than about the
basic problem itself.  Whenever one thinks one has taken care of all
"obvious things" one notices another one that should have been obvious
but that one forgot about anyway.  And then yet another...

Stefan is not volunteering.  I definitely am not either.

Sincerely,

Luc.

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

[Luc Teirlinck]

Actually, I thought a little bit about inheritance or
inheritance-mimicking and maybe the main abbrev part of the problem
might be easier than I thought.  The solution I have in mind would
perfectly mimic true inheritance, regardless of whether the internal
implementation could be called "true inheritance".  It would use
pre-abbrev-expand-hook to check whether updating the abbrev-table is
necessary and update it if it is.  It is very similar to what
mailabbrev.el does, but actually simpler.  I am still not sure that
inheritance is really that desirable, but if it is decided that it is,
then I might be willing to implement the main abbrev part of the
problem as long as somebody else would rewrite list-abbrevs and take
care of similar "obvious details".  I have currently no time to do so.

Sincerely,

Luc.

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

[Luc Teirlinck]

Actually, there might be a more efficient way that would also make
adapting other related functions less awkward.  It corresponds to true
inheritance in that abbrev expansion would be called several times in
the different "active" abbrev tables until expansion occurs.  A more
local abbrev table gets used first and hence overrides more global
ones.  No copying between abbrev tables would take place.  There still
would remain work to be done in adapting related functions.  The most
efficient way to implement this seems to be directly in the C code.  I
do know C, but I am not terribly familiar with Emacs' C code and hence
could be of no help here.  A similar behavior could be implemented in
Lisp using pre-abbrev-expand-hook, but I believe that would definitely
be less efficient.

Essentially, the above behavior is true inheritance, my previous
proposal is a bug fix mimicking true inheritance perfectly, but with
the drawback of the same abbrev definition occurring in multiple
abbrev tables.  (This drawback is present in the current situation
too.)

Sincerely,

Luc.

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

[Luc Teirlinck]

A summary and some amendments to my previous messages on abbrevs:

I actually might have overestimated the work involved in implementing
true inheritance.  True inheritance seems easier to implement than the
"bug fix" approach.  The bugs involved in copying are really bad and
need to be fixed reasonably soon, if we decide to retain any form of
copying or inheritance.  So there seem to be two choices:

1.  Get rid of copying altogether.

2.  Implement true inheritance.  

In case 2, implementing true inheritance and getting rid of the bugs
involved in copying is relatively urgent, since these bugs are really
bad.  I could implement true inheritance in Lisp, but it might be more
efficient to implement it in C.  Even though I know C, I am not
familiar enough with the Emacs C code to implement it.  Some form of
inheritance seems actually already to be implemented in C, since local
abbrev tables in a certain sense "inherit" from the global one, so
generalizing this might not be too bad.  True inheritance seems to
require less work than a mere bug fix, because the necessary changes
to prepare-abbrev-list-buffer are very minor in that case.  In the
case of a mere bug fix, they seem rather cumbersome to me.  The
changes to prepare-abbrev-list-buffer seem necessary to enable the
user to use M-x edit-abbrevs without having to do a lot of "research".

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.

Sincerely,

Luc.

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

[Miles Bader]

Luc Teirlinck <teirllm@dms.auburn.edu> 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.

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

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

[Luc Teirlinck]

Miles Bader wrote:

   Luc Teirlinck <teirllm@dms.auburn.edu> 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.

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

[Richard Stallman]

    abbrev-tables should be able to inherit from each other.

It is hard to make inheritance for abbrev-tables a coherent feature.
The problem is that it isn't obvious what is the right thing to do
when users define new abbrevs.  If a user defines a new abbrev while
in Paragraph-Indent Text mode, should it go in the Text mode abbrev
table or the Paragraph-Indent Text mode abbrev table?  Neither one is
clearly always right.

I think the best solution is not to have a different abbrev table for
Paragraph-Indent Text mode.

This issue does not arise for syntax tables because users rarely alter
them.

Could you please install that mail-mode patch?

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

[Stefan Monnier]

>     abbrev-tables should be able to inherit from each other.
> 
> It is hard to make inheritance for abbrev-tables a coherent feature.
> The problem is that it isn't obvious what is the right thing to do
> when users define new abbrevs.  If a user defines a new abbrev while
> in Paragraph-Indent Text mode, should it go in the Text mode abbrev
> table or the Paragraph-Indent Text mode abbrev table?  Neither one is
> clearly always right.
> 
> I think the best solution is not to have a different abbrev table for
> Paragraph-Indent Text mode.

The two modes now use the same abbrev-table.

> This issue does not arise for syntax tables because users rarely alter
> them.
> 
> Could you please install that mail-mode patch?

It is installed.


	Stefan

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

[Richard Stallman]

    > One idea for how to fix the abbrev-table bugs is to modify
    > define-derived-mode to accept some optional keywords as arguments
    > before the body.  :same-abbrev-table could mean to use the parent's
    > abbrev table unmodified, and :same-syntax-table would do likewise for
    > the syntax table.

    That's something we need indeed.  I for one would need/want a :group
    argument as well.

Would you like to implement them?  (What would :group do?)

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

[Richard Stallman]

      A more
    local abbrev table gets used first and hence overrides more global
    ones.  No copying between abbrev tables would take place.  

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.

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.

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

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> 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.

Suggestion: by default, the commands use the "most local" abbrev
table.  There is a command that changes the abbrev table for C-x a l
and C-x a i l to use.  (Is there any other command except
add-mode-abbrev and inverse-add-mode-abbrev that should be affected
by the command?)

Another similar case are tags where we have the command
visit-tags-table.  A difference to tags is that M-. will ask the user
for a tags table to use, whereas I proposed C-x a l to use a default
value, without asking the user.  Maybe it is a good idea to ask the
user, instead.  But that would change the prompting behavior of C-x
a l.  Given that many users probably don't want to think about which
abbrev table to use, making C-x a l ask more questions is probably
not a good idea.

Another case is ispell where we have ispell-change-dictionary.  Here,
it works like I propose for abbrevs: M-$ uses a default dictionary
without asking the user.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

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

[Miles Bader]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> > 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.
> 
> Suggestion: by default, the commands use the "most local" abbrev
> table.  There is a command that changes the abbrev table for C-x a l
> and C-x a i l to use.

I think that would work, as long as modes only created their own
abbrev-table when the mode is clearly `unique enough' (compared to the
mode it's derived from) that most users would want to put abbrevs in the
derived-mode's table.  [with a :keyword command to define-derived-mode
to control whether a new abbrev table is made or not, this should be
simple for mode-authors]

E.g., probably `mail-mode' should have its own abbrev table, but
`paragraph-indent-text-mode' should not.

I suppose the question is, what should be the default behavior of
define-derived-mode -- to use the parents, or inherit?

-Miles
-- 
80% of success is just showing up.  --Woody Allen

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

[Luc Teirlinck]

Miles Bader wrote:

   E.g., probably `mail-mode' should have its own abbrev table,

I am not convinced about this.  I am also not convinced by the default
for C-x a (i) l you and Kai are proposing.

Most of a mail message is just text. You have mail addresses, but
these are handled separately anyway, as mail abbrevs.  Maybe the
people that complained about not being able to define mail-specific
abbrevs were complaining about not being able to define mailabbrevs
with a C-x a l style command.  Currently you can not do that, but I am
working on a unified mailalias-mailabbrev system.  With that system
you will be able to define mailabbrevs with a C-x a l style command
not only from mail buffers, but from other buffers too, such as RMAIL
buffers.

For instance, I have a text-mode abbrev sl expanding into 

Sincerely,

Luc.

I use this very frequently in mail-mode, but barely ever (although not
never) in text-mode.  This abbrev was definitely defined to be used
specifically in mail messages, but why would I need to "hide" it from
text-mode?  If I had any need to do that, I would not be able to use
the name sl in mail-mode either, for exactly the same reason I could
not use it in text-mode.  For instance, if my first name were, say,
Oswald, I could not use "so" as an abbrev name because "so" would
expand all the time in regular text.  But nearly all of the typing in
a mail-message is regular text.  So I could not use it in mail-mode
either, anyway.  If unwanted expansion in text-mode is a problem,
unwanted expansion in mail-mode is a problem.  Even if mail-mode had a
separate abbrev-table from text-mode, it would seem that I would like
the vast majority the local abbrevs I defined in mail-mode to expand
in text-mode too and hence the text-mode-abbrev-table would actually
be a more logical default for C-x a l than the mail-mode abbrev-table.

Hence I have a hard time seeing why mail-mode should have its own
abbrev table.  I also have a hard time seeing why the most local
abbrev table would be such an obvious default for C-x a (i) l.

Sincerely,

Luc.

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

[Miles Bader]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> Currently you can not do that, but I am
> working on a unified mailalias-mailabbrev system.

Make sure it doesn't screw up on puncuation characters like the current
one does (hmmm, I ought to report that as a bug...).

E.g.:

Currently, if I have a mail-alias `gnu', and type `miles@gnu.' in the
To: header, it will (incorrectly, and annoyingly) expand the `gnu' as
soon as I type the `.'.

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

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

[Luc Teirlinck]

Miles Bader wrote:


   Luc Teirlinck <teirllm@dms.auburn.edu> writes:
   > Currently you can not do that, but I am
   > working on a unified mailalias-mailabbrev system.

   Make sure it doesn't screw up on puncuation characters like the current
   one does (hmmm, I ought to report that as a bug...).

   E.g.:

   Currently, if I have a mail-alias `gnu', and type `miles@gnu.' in the
   To: header, it will (incorrectly, and annoyingly) expand the `gnu' as
   soon as I type the `.'.

That does definitely not happen in my package.  My package
will automatically fix this bug.

Sincerely,

Luc.

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

[Miles Bader]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> Even if mail-mode had a separate abbrev-table from text-mode, it would
> seem that I would like the vast majority the local abbrevs I defined
> in mail-mode to expand in text-mode too and hence the
> text-mode-abbrev-table would actually be a more logical default for
> C-x a l than the mail-mode abbrev-table.

Perhaps that's true for you (though your example actually seems to
contradict your conclusion!), but I suspect it's not for most people.
Mail messages are a fairly specialized subset of text in general.

In the end, it comes down to `your mileage may vary'; different people
will have different preferences, but we've got to pick one or the other
for the default.

-Miles
-- 
I'd rather be consing.

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

[Kai Großjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Hence I have a hard time seeing why mail-mode should have its own
> abbrev table.

This requires some thinking, I agree.

> I also have a hard time seeing why the most local abbrev table would
> be such an obvious default for C-x a (i) l.

I think that's the current behavior, isn't it?  At any point, there
are just two tables, the global and the local one, and C-x a l adds
to the latter.  Also, the local table corresponds to what will be the
"most local" table in the future.

So being backwards-compatible is a safe bet for a first approximation,
and then we can still think about what's a good default.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

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

[Richard Stallman]

    Suggestion: by default, the commands use the "most local" abbrev
    table.

That is a natural way to address such an issue, but I have a feeling
it is not right here.  The reason is, I think most of the time people
will want the same abbrevs in all the related modes.  There may be a
few people who wanted abbrevs just for Mail mode, but most people are
happy with sharing one abbrev table between Mail mode and Text mode.

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

[Stefan Monnier]

>     > One idea for how to fix the abbrev-table bugs is to modify
>     > define-derived-mode to accept some optional keywords as arguments
>     > before the body.  :same-abbrev-table could mean to use the parent's
>     > abbrev table unmodified, and :same-syntax-table would do likewise for
>     > the syntax table.
> 
>     That's something we need indeed.  I for one would need/want a :group
>     argument as well.
> 
> Would you like to implement them?

Sure.  Will try to find some time soonish.

> (What would :group do?)

Declare that this mode's behavior is related to the cutsom group
GROUP, so you can have a "customize major mode" entry in your
global menu-bar, for example (I have such a thing in my .emacs
and it uses various heuristics to find the group.  But the heuristics
only work 80% of the time).
Or you can add a `customize this major mode' button to `C-h m's output.


	Stefan

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

[Richard Stallman]

    I think that would work, as long as modes only created their own
    abbrev-table when the mode is clearly `unique enough' (compared to the
    mode it's derived from) that most users would want to put abbrevs in the
    derived-mode's table.

I think that is almost never.  Some people would like to have a
separate abbrev table for Mail mode, and it would be ok to have one if
that were painless for everyone else, but I think most users would
rather share abbrevs between Mail mode and Text mode.

And in such cases, two separate abbrev tables with no inheritance
would be fine.

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

[Richard Stallman]

    > I also have a hard time seeing why the most local abbrev table would
    > be such an obvious default for C-x a (i) l.

    I think that's the current behavior, isn't it?

There is no "current behavior" for this question.  The question never
arises at present.  There is only one local abbrev table for a major
mode, and C-x a l uses that one.

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

[Richard Stallman]

One possible idea for conveniently selecting one of the various
local abbrev tables is to specify both the abbrev table and
the abbrev text with the same minibuffer.

The minibuffer would start out with text that specifies the abbrev
table.  You can type text for the abbrev, leaving the abbrev table
name unchanged.  Or you can type M-p to pick a different abbrev table,
and then type text for the abbrev.

The advantage is that this doesn't add an inconvenient extra
minibuffer invocation.

However, it still imposes the burden of choosing which abbrev table.
It is not clear that the benefit is worth this burden.  I think that
having the possibility of separate abbrevs for Mail mode is only a
slight benefit.

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

[Luc Teirlinck]

Richard Stallman writes:

   One possible idea for conveniently selecting one of the various
   local abbrev tables is to specify both the abbrev table and
   the abbrev text with the same minibuffer.

   The minibuffer would start out with text that specifies the abbrev
   table.  You can type text for the abbrev, leaving the abbrev table
   name unchanged.  Or you can type M-p to pick a different abbrev table,
   and then type text for the abbrev.

If we decide to implement several levels of localness, then, to me,
this seems like the best solution.

   However, it still imposes the burden of choosing which abbrev table.
   It is not clear that the benefit is worth this burden.  I think that
   having the possibility of separate abbrevs for Mail mode is only a
   slight benefit.

I agree with this too.  I believe that the vast majority of users are
perfectly happy with the current situation.  They should not be
inconvenienced.  However, a maybe non-negligible minority of users
seems to perceive a need for more than one local abbrev table per
buffer.

One solution would be to implement the possibility of more than one 
local abbrev table as a customization feature for sophisticated
users.  (It seems obvious to me that anybody who sees a need for the
feature qualifies as a "sophisticated user".)  The Emacs manual could
have an extra section in the chapter on abbrevs titled something like:
"Advanced Features: Multiple Local Abbrev Tables" or similar.  It
would be clear that readers could ignore this section, unless they
felt a need for advanced flexibility. 

By default, buffers would have only one local abbrev table.  No major
mode would put in more than one local abbrev table unless the user
explicitly asks so by customization.  The default behavior of
define-derived-mode would be to use the unmodified parent abbrev
table.  (The current copying system used by define-derived-mode is
flawed.  It poses exactly the same problems as the more solid system
we are currently discussing.  It has bugs that are difficult to fix
and it is not even clear in which direction they should be fixed.  It
does not co-exist well with M-x list-abbrevs and M-x edit-abbrevs.)

However, the variable local-abbrev-table would be complemented with a
variable local-abbrev-table-list. `expand-abbrev' would check whether
this variable is non-nil and, if so, use it instead of
local-abbrev-table.  (This could be implemented in C, or in Lisp,
using pre-abbrev-expand-hook.)  By default, mail-mode would use
text-mode-abbrev-table.  But users could define a
mail-mode-abbrev-table in their .emacs and set mail-mode's
local-abbrev-table-list to (mail-mode-abbrev-table
text-mode-abbrev-table).  The Emacs manual could explain how to do
this, without assuming any Lisp knowledge.

We could also define a variable add-mode-abbrev-list that would
control the behavior of C-x a (i) l, if local-abbrev-table-list is
non-nil.  M-n and M-p would cycle through this list if it contained at
least two elements.  If it is nil, it uses local-abbrev-table-list.
If it has only one element, no question needs to be asked and there is
no reason to inconvenience the user.  Miles and Kai could set this
variable to (mail-mode-abbrev-table) for mail-mode and get the exact
behavior they suggested.  If I actually wind up using a
mail-mode-abbrev-table at all, I myself would set add-mode-abbrev-list
to (text-mode-abbrev-table mail-mode-abbrev-table), that is, the
reverse of local-abbrev-table-list, because most of the local abbrevs
I would want to define in mail-mode would be text-mode abbrevs.

Sincerely,

Luc.

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

[Luc Teirlinck]

From my previous message:

   However, the variable local-abbrev-table would be complemented with a
   variable local-abbrev-table-list.

If we would decide to go for a solution of the type I described, then
maybe the documentation string for this variable could contain a
statement that it is meant to be a user feature and is not meant for
use by major modes.  I believe that if we would decide to implement
multiple local abbrev tables, then it is important that nobody who
does not care about the functionality winds up having to struggle with
its complexities anyway.

Sincerely,

Luc.

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

[Luc Teirlinck]

From my previous message:

   However, the variable local-abbrev-table would be complemented with a
   variable local-abbrev-table-list. `expand-abbrev' would check whether
   this variable is non-nil and, if so, use it instead of
   local-abbrev-table.  (This could be implemented in C, or in Lisp,
   using pre-abbrev-expand-hook.)

Actually, implementing this in Lisp using pre-abbrev-expand-hook might
be tricky, since one would have to make completely sure that other
functions wanting to change or override abbrev-expansion get a chance
to run before the function implementing this variable. One can put it
at the end of pre-abbrev-expand-hook using the APPEND argument of
add-hook, but one then better hope that something else is not
going to override this.  I do not know how easy or difficult the
implementation in C is.  I know C, but am not very familiar with
Emacs' C internals.

Some other problems may need to be looked into.

Anyway, the first question to decide is: 

Is it is actually worth trying to implement multiple local abbrev
tables, as a customization feature, or not?

Sincerely,

Luc.

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

[Miles Bader]

On Sun, Sep 08, 2002 at 07:14:11PM -0500, Luc Teirlinck wrote:
> I agree with this too.  I believe that the vast majority of users are
> perfectly happy with the current situation.  They should not be
> inconvenienced.  However, a maybe non-negligible minority of users
> seems to perceive a need for more than one local abbrev table per
> buffer.

Perhaps that's true; it certainly makes things simpler!

> One solution would be to implement the possibility of more than one 
> local abbrev table as a customization feature for sophisticated
> users.
[complicated description omitted]

I agree; to me this seems like a good enough way to solve the problem.

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...

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

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

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> 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...

That's one (non-interactive) approach.

What about the following approach?

Suppose emacs doesn't have any mode-specific abbrev tables by default, but
just a "fundamental-abbrev-table" for every mode and buffer to use.

Then we could provide a new user command, e.g.
`abbrev-define-mode-specific-abbrev-table', (also available via
customize?)  which creates a mode-specific abbrev table for the
mode(s) of the current buffer [prompt for which of the active modes to
use, suggesting the major mode as the default], and then prompt for
which of the existing abbrev tables to use as the "parent" abbrev
table [or none].

Then we leave it completely up to the user which abbrev tables he needs
and how to tie them together...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Luc Teirlinck]

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.

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

[Richard Stallman]

Your plan is a good design, but I don't think the need for the feature
is sufficient to justify the effort to do this.

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

[Richard Stallman]

It seems to me that we should change define-derived-mode to either create
a new empty abbrev table or use the parent's abbrev table.  Then we should
make each call do the right one.

    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!)?

Yes, they can--so we need not add any features to cater to the
minority who would like a separate abbrev table in Mail mode.

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

[Luc Teirlinck]

Richard Stallman wrote:

   It seems to me that we should change define-derived-mode to either create
   a new empty abbrev table or use the parent's abbrev table.  Then we should
   make each call do the right one.

I completely agree.  This change removes one of the main motivations
for my proposed feature, namely dealing with the bugs and user
inconveniences caused by the copying mechanism of define-derived-mode.
Eliminating the copying mechanism will eliminate all bugs and
inconveniences without any work, other than a minor change (actually a
simplification) to define-derived-mode.

I agree that, after this change, there is no longer sufficient
motivation for my proposed feature to justify the work involved.

Sincerely,

Luc.

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

[Richard Stallman]

    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.

If a user manually creates a separate abbrev table for Mail mode, I
think he will find it easy to understand the results of initializing
it as a copy of the Text mode abbrev table.  As a form of
"inheritance", it is inadequate, but if thought of as "copying", the
user will think it works fine.

So I think we should provide a function copy-abbrev-table which the
user could call to make a copy of text-mode-abbrev-table for use in
Mail mode.

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

[Luc Teirlinck]

Richard Stallman wrote:

   If a user manually creates a separate abbrev table for Mail mode, I
   think he will find it easy to understand the results of initializing
   it as a copy of the Text mode abbrev table.  As a form of
   "inheritance", it is inadequate, but if thought of as "copying", the
   user will think it works fine.

   So I think we should provide a function copy-abbrev-table which the
   user could call to make a copy of text-mode-abbrev-table for use in
   Mail mode.

Once the table is defined, the user could also "initialize" by killing
and yanking using M-x edit-abbrevs.  However, the function you suggest
would be more convenient.

If I understand you correctly, this would be strictly for
initialization.

There might actually be a way to relatively easily provide for
automatic updating similar to the present system, but in a bug-free
and unambiguous way.  It seems to require a lot less work than any other
solution we have been discussing.  I believe I might be able to
implement it myself, if desired, although I might first have to check
whether I am not underestimating certain difficulties.  I could not
promise anything before actually having done it.

The price to pay would be a moderate amount of added code and the need
to explain to non Lisp programmers how to set everything up in their
.emacs.  The code could either be added to abbrev.el or go into
a separate small new file. 

One way to achieve bug-free updating might conceivably be to use a new
variable, say inheriting-abbrev-table-list, whose value is a list of
abbrev tables, and two new commands: modified versions of
add-mode-abbrev and inverse-add-mode-abbrev.  The user could then
rebind C-x a l and C-x a i l to those new commands in the modes
involved (in our example, text-mode).

The behavior would be the following.

The user could, say, define a separate mail-mode-abbrev-table,
plain-tex-mode-abbrev-table and latex-mode-abbrev-table and set
inheriting-abbrev-table-list locally in text-mode to a list of these
three tables.  Then (s)he rebinds C-x a (i) l in text-mode to the new
modified variants.  The effect is that any abbrev defined using C-x a
(i) l in text-mode gets automatically inherited by these three
abbrev-tables, except when the abbrev already has an expansion in some
of these tables.  Then the commands ask the user whether (s)he wants
to redefine the abbrev, printing the mode involved.

The user could also keep the usual C-x a (i) l bindings and bind the
new commands to other key sequences of his or her choice.  That way
(s)he can decide on a case by case basis whether or not the abbrev
should be inherited by related modes.

Abbrevs defined using M-x edit-abbrevs would remain the user's
responsibility.  (S)he is already editing that buffer anyway, so it is
relatively easy to kill and yank.

Sincerely,

Luc.

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

[Richard Stallman]

    There might actually be a way to relatively easily provide for
    automatic updating similar to the present system, but in a bug-free
    and unambiguous way.

I think let's not bother with the complexity this adds to the interface.