[Top][All Lists]

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

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

From: Luc Teirlinck
Subject: Re: Bugs caused by recent use of define-derived-mode
Date: Sun, 8 Sep 2002 19:14:11 -0500 (CDT)

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

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.



reply via email to

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