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

[Kai.Grossjohann@CS.Uni-Dortmund.DE (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)