mailabbrev.el, mailalias.el and related package.

[Luc Teirlinck]

A while ago, I wrote a bug report concerning three bugs in
mailabbrev.el.  Gerd Moellmann then told me that he was very busy with
Emacs21 and asked me if I could not take care of these three bugs
myself.  I agreed.  Trying to take care of these three bugs however, I
found many more serious bugs and concluded that the very system used
in mailabbrev.el was flawed.  I thought that to eliminate the many
bugs without introducing others, the system had to be replaced with a
more solid system and Gerd agreed.  Since my changes were supposed to
be incorporated in Emacs21, and since it was Gerd who asked me to take
care of these problems, I communicated directly with Gerd about this.
The trouble is that since the project was more involved than I
originally thought, it did not get ready for Emacs21.  I contacted
Gerd again recently and learned that he was not at the FSF anymore.  I
do not know who else (if anybody) from the Emacs maintainers knows what
I have been doing.

I had to stop working on the project for a while because I had other
things to do, and it might take a month or maybe two before I can
restart working on it, after which it should not take me too long to
finish, since it is nearly ready.

However, since other people are starting to complain about some of the
bugs I fixed (see below), I believe I should let you know right now
that I took care of these and plenty of related bugs, which I reported
to Gerd.

The new system relies totally on the mail-personal-alias-file (usually
.mailrc) and sourced files.  It keeps relying internally on abbrev
tables, but these would not be listed in abbrev-table-name-list and
hence be essentially invisible to users who would not manipulate them
directly.

Instead, the new system provides for interactive functions to write
alias definitions directly into .mailrc in the correct syntax,
regardless of whether they are actually written in .mailrc syntax or
in mail header syntax.  Such functions include saving the current list
of addresses in a mail header into an alias as well as saving all
addresses inside a region of any Emacs buffer into an alias.  A user
would never even have to look at his .mailrc file if he or she did not
want to, because the functions also allow to delete or edit aliases
interactively.  The user can of course also edit .mailrc or sourced
files directly and support for this is provided by other functions.

The new system also eliminates some bugs in mailalias and sendmail.

The new mailabbrev package is a lot closer to the default (in RMAIL)
mailalias package than the original mailabbrev package.  It uses the
sendmail syntax-table and the sendmail fill-style.  Like sendmail, it
uses the text-mode-abbrev-table.  (This implements the suggestion by
RMS mentioned in the attached copy of a bug report.)  The original
mailabbrev package switched unpredictably between several
syntax-tables, several filling styles and worst of all, three distinct
abbrev tables.

Unlike the original mailabbrev package, the new package can do
everything the mailalias package does (as well as everything the old
mailabbrev package does) using abbrev-tables instead of alists.  Apart
from that it actually uses large sections of mailalias.el.  Old
mailabbrev functions are replaced or complemented by mailalias
functions rewritten to use abbrev tables rather than alists.  Some
other functions in mailabbrev.el are replaced by sendmail functions.

Therefore, I have one question to ask:

QUESTION:

Would the Emacs maintainers in principle be willing to consider the
possibility of replacing the current dual mailalias-mailabbrev system
with one single (very customizable) system.  This system could do
everything that either of the two systems can.  The mailalias
functions would still do exactly what they do now (up to some bug
fixes) but with different internals.  I believe that for large lists
of aliases obarrays are faster than alists anyway.  Functions are
provided to write all mailabbrevs or mailaliases defined under the
mailalias or the old mailabbrev system directly into .mailrc, without
duplication.  So there would be very little transition pain for users
of either system.

It goes without saying that answering "yes" to the above question does
not commit you to to actually implement any such system in Emacs if
you do not like the final result.  (This is evident.)  Also, even if
you answer yes, I myself would only be totally convinced about the
desirability of doing so after having a concrete package to play
with.  So even if you answer yes, it is not certain I would actually
do it.  All I want to know is whether you are in principle open to the
possibility.

If not, the problems in mailabbrev can be taken care of without giving
up on the current dual system.  However, it does require one to be
very careful about the interaction between the two possible systems
and other mail related packages often have to guess which system the
user is using.  I looked in the Emacs source code at the ways people
tried to determine the actual system used and none of the methods used
seemed entirely reliable.  Longer term, it would seem a lot more solid
to have a unified system.  Things could be done in two steps too.

I include a copy of a previously posted bug report about bugs that my
package takes care of.  I contacted the poster of that bug report.  He
is willing to help test my package, when totally ready, using GNUS.  I
myself have mainly tested it extensively in RMAIL, where in my
experience it works perfectly.

COPY OF RELATED BUG REPORT:

From: address@hidden (Matt Armstrong)
Subject: mailabbrev clobbers local-abbrev-table, syntax table
Newsgroups: gnu.emacs.bug
Date: Wed, 30 Jan 2002 11:20:41 -0700
Mail-Copies-To: never
x-uunet-gateway: mr1.ash.ops.us.uu.net from bug-gnu-emacs to gnu.emacs.bug; 
Wed, 30 Jan 2002 18:20:48 GMT
Message-ID: <address@hidden>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: by AMaViS snapshot-20010714
Approved: address@hidden
Path: 
aunews.duc.auburn.edu!news-ext.gatech.edu!bloom-beacon.mit.edu!news-out.cwix.com!newsfeed.cwix.com!feed2.news.rcn.net!rcn!dca6-feed2.news.digex.net!intermedia!newsfeed1.cidera.com!Cidera!portc01.blue.aol.com!uunet!dca.uu.net!ash.uu.net!spool0901.news.uu.net!wendy-fate.uu.net!bug-gnu-emacs
Sender: address@hidden
Lines: 101
Xref: aunews.duc.auburn.edu gnu.emacs.bug:32020

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the address@hidden mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.1.1 (i386-debian-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2001-12-06 on raven, modified by Debian
configured using `configure  i386-debian-linux-gnu --prefix=/usr 
--sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib 
--infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --with-x=yes 
--with-x-toolkit=athena --without-gif'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

This is a courtesy copy of a problem I found while looking into abbrev
issues for Gnus' message mode.  It is part of a thread that took place
on address@hidden and address@hidden

Richard Stallman <address@hidden> writes:

> Mailabbrevs is something different; those abbrevs use a special
> abbrev table.
>
> Message mode ought to use text-mode-abbrev-table for its ordinary
> abbrev table.  It should set local-abbrev-table to
> text-mode-abbrev-table.

I attempted to implement this change, but mailabbrev clobbers the
value of local-abbrev-table (and the message mode syntax table).

It turns out that mailabbrev does not restore the previous values of
the syntax-table and local-abbrev-table after it is done.  Instead, it
restores the mail-* versions of those variables.  Since there is no
mail-mode-abbrev-table variable, it *always* sets local-abbrev-table
to nil.  It also always sets the syntax table back to
mail-mode-syntax-table, which is not desirable for message mode.

The offending function is sendmail-pre-abbrev-expand-hook in
mailabbrev.el.

    (defun sendmail-pre-abbrev-expand-hook ()

    [...]

         (if (or (not mail-abbrevs-only)
                 (eq this-command 'expand-abbrev))
             (progn
               ;; We're not in a mail header where mail aliases should
               ;; be expanded, then use the normal mail-mode abbrev table
               ;; (if any) and the normal mail-mode syntax table.

               (setq local-abbrev-table (and (boundp 'mail-mode-abbrev-table)
                                             mail-mode-abbrev-table))
               (set-syntax-table mail-mode-syntax-table))

    [...]

Maybe sendmail-pre-abbrev-expand-hook needs to always restore
local-abbrev-table and the syntax table to whatever they were before
it was called?



Recent input:
a b l e ) . M-q C-n C-n C-n C-n C-n C-n C-p M-b M-b 
M-b M-d f o r M-q C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-l M-q M-f M-f M-f M-f M-f M-f M-f <right> C-n C-a 
M-f M-f M-f <right> M-q M-f M-f M-f M-f M-f M-f M-f 
M-f M-f M-f M-f M-f M-f M-f M-f M-f M-f M-f M-f C-x 
C-s <switch-frame> C-x 1 M-x b u <tab> <backspace> 
<backspace> C-g <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <menu-bar> <help-menu> <re
port-emacs-bug>

Recent messages:
Mark set
Wrote /home/matt/.emacs-keyolution/emacs-keyolution1145.data
Auto-saving...done
Wrote /home/matt/g/News/drafts/drafts/20
Auto-saving...done
Wrote /home/matt/.emacs-keyolution/emacs-keyolution1146.data
Wrote /home/matt/g/News/drafts/drafts/20
Making completion list...
call-interactively: Quit
Loading emacsbug...done

-- 
matt