mailabbrev.el, mailalias.el and related package.

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: matt@lickey.com (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: <87zo2vem4m.fsf@squeaker.lickey.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: by AMaViS snapshot-20010714
Approved: bug-gnu-emacs-request@mail.gnu.org
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: bug-gnu-emacs-request@mail.gnu.org
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 bug-gnu-emacs@gnu.org 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 emacs-devel@gnu.org and ding@gnus.org.

Richard Stallman <rms@gnu.org> 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

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

mailabbrev.el, mailalias.el and related package.

[Luc Teirlinck]

I believe I might have given an incorrect impression in my previous
message on one particular point.  We are talking about a rewrite of
mailabbrev.el, not a replacement with an entirely new package.  Most
of mailabbrev.el is kept, although there is a fundamental change in
the underlying mechanism and mailabbrev.el is moved sufficiently in
the direction of mailalias-sendmail to make a unified system very much
possible.  Due to the increased importance of .mailrc in the new
system, there is an entirely new file with functions to write
interactively into .mailrc, as well as to help edit .mailrc.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

mailabbrev.el, mailalias.el and related package

[Luc Teirlinck]

I am a little bit concerned about the way I (mis)formulated certain
things in my original message.  Expressions such as, for instance,
"these and plenty of related bugs" may give the (mistaken) impression
that the mailabbrev code is just totally littered with bugs, which
would be unfair to the author.  I apologize if this is the impression
I created.  While it is true that there actually are plenty of bugs
related to mailabbrev, they all originate from a limited number of
problems with the mailabbrev code.  These problems nearly all concern
the interaction between mailabbrev and sendmail-mailalias (that
interaction is tricky, that is exactly why I would prefer one unified
system), as well as interactions between mailabbrev and other parts of
Emacs.  I am not familiar with the exact history of mailabbrev.el, but
if it were actually not originally written for Emacs, but would
instead be an adaptation of a package written originally for XEmacs,
then this would explain a lot of things that otherwise seem strange to
me.  Except for the bugs, which are nearly all interaction problems
with the rest of Emacs, the original mailabbrev.el is actually is a
very useful package.  I believe however that it can only be made to
interact well with the rest of Emacs by making some fundamental
changes of the type I made.  As mentioned before, in spite of these
changes, my rewrite preserves a lot of the original mailabbrev code.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: mailabbrev.el, mailalias.el and related package.

[Richard Stallman]

    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.

Yes.  That sounds like a good cleanup.

    I include a copy of a previously posted bug report about bugs that my
    package takes care of.

Can you tell me which of the recent bugs (if any) your package
does NOT fix?  And can you fix them?

How about this--can you fix this too?

Sender: ke@gnu.franken.de
To: rms@gnu.org
Cc: emacs-devel@gnu.org
Subject: Re: expanding mail aliases too aggressive (.mailrc)
In-Reply-To: <200202121523.g1CFN7507211@aztec.santafe.edu> (Richard
 Stallman's message of "Tue, 12 Feb 2002 08:23:07 -0700 (MST)")
From: Karl Eichwalder <ke@gnu.franken.de>
Reply-To: Karl Eichwalder <keichwa@gmx.net>
Date: Wed, 13 Feb 2002 00:46:56 +0100

Richard Stallman <rms@gnu.org> writes:

> Does this fix the problem?

[...]

> ***************
> *** 464,469 ****
> --- 469,475 ----
>   			      (if (equal value _)
>   				  (set-char-table-range tab key w))))
>   		  tab)
> + 		 (modify-syntax-entry ?@ "w" tab)
>   		 (setq mail-abbrev-syntax-table tab)))
>   
>   	     ;; If the character just typed was non-alpha-symbol-syntax,
>

Yes, this fixes the reported problem, but it isn't general enough.

Completing mail abbrevs must only happen for strings after

    ^[tT]o:[:blank:]?
or
    ,[:blank:]

Wondering when my .mailrc entries were transferred to
(define-abbrev-table 'mail-abbrevs '(...)) in  ~/.abbrev_defs; was this
a one time action or does Emacs maintain this list?

Whenever Emacs decides to modify user files in tell the user about it
(through a message dialog the user is considered to confirm) and add a
comment.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: mailabbrev.el, mailalias.el and related package.

[Luc Teirlinck]

Richard Stallman wrote:

      Can you tell me which of the recent bugs (if any) your package
      does NOT fix?  And can you fix them?

Unfortunately, until recently I did not know about the fact that bug
reports did not only get posted on gnu.emacs.bug, but also on the
emacs-devel@gnu.org mailing list.  I just subscribed this evening.
Gerd did not ask me to watch either this site or gnu.emacs.bug.  (He
did tell me to contact this site when I contacted him more recently.)
Hence, I did not even watch the site I did know about too carefully.  I
just assumed Gerd would contact me if anybody reported problems on the
things I was working on.  I did not know that Gerd was no longer at
the FSF.

As mentioned, my package does fix the problems in the report I
included in my original message.

I will mail you a report on the bug report you forwarded me shortly.

In as far as the one other one I noticed while wading through the
February archives:

       I am thinking that it is wasteful to load sendmail.el
       if the user is using message.el instead.

This is exactly the main thing I still need to worry about.  My package
is essentially ready in as far as RMAIL is concerned, which is the
mailer I use, but I still need to worry how it affects message mode.
My package presently loads sendmail, but that could change.
I will have to take a look at message.el.  I have not yet done so.

Was your message below the final word on the subject?

(require 'mailabbrev) 

Richard Stallman rms@gnu.org 
Sat, 9 Feb 2002 22:18:35 -0700 (MST) 

It would be wasteful to load a substantial file just to use 5 lines of
code.  Does this patch fix it?

*** mailabbrev.el.~1.63.~       Sat Feb  9 04:45:14 2002
--- mailabbrev.el       Sat Feb  9 05:24:37 2002
***************
*** 418,424 ****
         (looking-at mail-abbrev-mode-regexp))
       ;;
       ;; ...and are we in the headers?
!      (< (point) (mail-header-end)))))
  
  (defvar mail-mode-abbrev-table) ; quiet the compiler
  
--- 418,429 ----
         (looking-at mail-abbrev-mode-regexp))
       ;;
       ;; ...and are we in the headers?
!      (< (point)
!       (save-restriction
!         (widen)
!         (save-excursion
!           (rfc822-goto-eoh)
!           (point)))))))
  
  (defvar mail-mode-abbrev-table) ; quiet the compiler

I do not, at present, know about any other bug reports posted about
mailabbrev.el on this site.  I could try to wade some more through the
archives.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: mailabbrev.el, mailalias.el and related package.

[Luc Teirlinck]

I do not know whether I should actually post this to this thread or
to  "expanding mail aliases too aggressive (.mailrc)".  Also, maybe
additional people should get a CC?

Concerning the effect of my package on the two problems reported in 
"expanding mail aliases too aggressive (.mailrc)":

        In .mailrc I used to have this entry:

            alias gnu <gnu@gnu.org>

        Now, when I type

            To: emacs-devel@gnu.-!-

        it gets expanded to

            To: emacs-devel@<gnu@gnu.org>

I may be misunderstanding the above, but I can not only not reproduce
this in Emacs20.7 built with my package, I can also not reproduce it
in Emacs21.1.90 without any of my package included in it.

        Wondering when my .mailrc entries were transferred to
        (define-abbrev-table 'mail-abbrevs '(...)) in  ~/.abbrev_defs;
        was
        this
        a one time action or does Emacs maintain this list?

        Whenever Emacs decides to modify user files in tell the user
        about it
        (through a message dialog the user is considered to confirm)
        and add a
        comment.

The current mailabbrev.el needs to write mailabbrevs in
~/.abbrevs_defs, because that is the only way it can save them.  Of
course aliases defined in .mailrc are already stored there, but
mailabbrev needs to worry about aliases defined in other ways.  My
package would change that totally, because it would have all aliases
defined in .mailrc.  It would still use abbrevs internally, but these
would be essentially invisible to users.

Conflicts between the two types of aliases were a source of bugs.




_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: mailabbrev.el, mailalias.el and related package.

[Karl Eichwalder]

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

>         Now, when I type
>
>             To: emacs-devel@gnu.-!-
>
>         it gets expanded to
>
>             To: emacs-devel@<gnu@gnu.org>
>
> I may be misunderstanding the above, but I can not only not reproduce
> this in Emacs20.7 built with my package, I can also not reproduce it
> in Emacs21.1.90 without any of my package included in it.

Thanks for looking into this problem; please, try:

    gnu@gnu.gnu-!-

and enter a dot ('.') -- it still expands for me.

maybe, it was temporarily only.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: mailabbrev.el, mailalias.el and related package.

[Luc Teirlinck]

Dear Karl,

If I understand this right:

You type:

gnu@gnu.gnu.

No expansion after the first dot, but expansion after the second.
Still does not happen for me.  I see you are using 21.2.50.

To me the two most likely explanations are:

1. I still am misunderstanding you.

2. This bug is due to changes made in mailabbrev.el between version
   21.1.90, which I am using, and 21.2.50.

Luc Teirlinck.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: mailabbrev.el, mailalias.el and related package.

[Karl Eichwalder]

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

> No expansion after the first dot,

Yes, Richard already fixed it.

> but expansion after the second.  Still does not happen for me.  I see
> you are using 21.2.50.

Then let's assume it is a local configuration error by my side; I'll
test it when time permits.  I encountered the bug only because
accidentally bbdb stopped working (changes with mail-header-end were
the cause) and as a fall back the mailabbrev mechanism jumped in.

I'm using/testing 21.2.50 exclusively (21.1.xx without encoding
unification is too cumbersome for me).

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: mailabbrev.el, mailalias.el and related package.

[Luc Teirlinck]

Dear Karl,

The problem is not a local configuration error on your side.
This was not a problem in the original mailabbrev, but a new problem
occurring in changes instituted in mailabbrev.el after Emacs21.1.90,
changes made to take care of other problems that did occur in the old
mailabbrev. 

When before applying Richard's change, something like:

gnu@gnu. made gnu expand there were two problems involved:

"@" had the wrong syntax and "." had the wrong syntax.  (Richard actually
alluded to that second problem in his reply to you.)

Since @ was not considered a word constituent, the second gnu is a
valid mailabbrev.  However, . should nevertheless not expand mailabbrevs.

Now you apply Richard's patch, making @ a word constituent and type:

gnu@gnu 

at this stage the "word" before point is gnu@gnu, which is not a valid
mailabbrev any more.

But then you go on and type:

gnu@gnu.gnu.

You did not make "." a word constituent, so the word before point is
again gnu.  Since you did not fix anything for . ,it still expands
that mailabbrev.

You seem to suggest that the problem sometimes happens and sometimes
not.  That would make perfect sense, because it all seems to depend on
the syntax table you start out with.  (It actually should not depend
on that.)

When I have time to look deeper into it, I will double check this and
look at the technical details involved.

In any case my new package takes care of the problems that the changes
were intended to take care of without introducing this new problem.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: mailabbrev.el, mailalias.el and related package.

[Luc Teirlinck]

This concerns the overly aggressive expansion of mailabbrevs.

I believe the following completely explains why the bug we have been
discussing occurs in Emacs21.2.50, but not in 21.1.90 or earlier
versions.

In the present message, I just will try to point out what I believe is
going wrong.  I will send a follow-up message on what could be done
from here.  

I believe the following change in the mailabbrev code is responsible:

Copy of a message of Richard Stallman:

	Richard Stallman rms@gnu.org 
	Sat, 2 Feb 2002 21:41:58 -0700 (MST) 

	This is very strange.  mailabbrev.el does assume the existence
	of mail-mode-abbrev-table, as you say.  But the code in
	sendmail.el seems not to have used mail-mode-abbrev-table
	until a few months ago.  Perhaps this was an unreported bug.
	I had better investigate further.

	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?

	I agree.  The reason this was not done was an undoc feature I didn't
	know about: setting up a different, convenient syntax table for
	address headers.  The feature could be useful but the implementation
	was unreliable, so I eliminated it.

I assume you are talking about mail-mode-header-syntax-table.

The documentation string for that syntax table is extremely
misleading.  It suggests that the purpose of this table is to provide
for more appropriate behavior of forward-sexp and forward-word and the
like.  As you correctly point out in your remarks above, the
implementation was unreliable.  Maybe it might be possible to make it
reliable.  My package does not attempt that.  I believed it looked
like quite a bit of work, as well as a possible source of potentially
nasty bugs.  (Maybe it is not.)  Anyway, you seem to have concluded
that it was not worth the trouble.  I came to the same conclusion.

However, regardless of what the documentation string says, even if this
forward-sexp and forward-word stuff would have been implemented
correctly, this would have been a very secondary use for that syntax
table.  The main reason for that syntax table is its use in abbrev
expansion.  In as far as I see, there is nothing wrong with the syntax
table itself.  Instead, there is something wrong with the way it is
used at places were it should not be and there is something wrong with its
misleading documentation string.

I still use it, as well as mail-abbrev-syntax-table in my new package,
because they are essential for appropriate mailabbrev expansion.  My
package is (I hope) however a lot more careful about when they get
used.  I just changed the documentation string of
mail-mode-header-syntax-table to say that this syntax table is used for
mailabbrev expansion purposes.


       Does this version solve the problem?

I will not recopy the entire proposed (and apparently implemented in
Emacs21.2.50) version, just the function where I suspect trouble.
I added personal remarks in three key places:


(defun sendmail-pre-abbrev-expand-hook ()
  (and (and mail-abbrevs (not (eq mail-abbrevs t)))
       (if (mail-abbrev-in-expansion-header-p)

           ;; We are in a To: (or CC:, or whatever) header, and
           ;; should use word-abbrevs to expand mail aliases.
           (let ((local-abbrev-table mail-abbrevs)
                 (old-syntax-table (syntax-table)))

             ;; Before anything else, resolve aliases if they need it.
             (and mail-abbrev-aliases-need-to-be-resolved
                  (mail-resolve-all-aliases))

             ;; Now proceed with the abbrev section.
             ;;   -  We already installed mail-abbrevs as the abbrev
table.
             ;;   -  Then install the mail-abbrev-syntax-table, which
             ;;      temporarily marks all of the
             ;;      non-alphanumeric-atom-characters (the "_"
             ;;      syntax ones) as being normal word-syntax.  We do
this
             ;;      because the C code for expand-abbrev only works
on words,
             ;;      and we want these characters to be considered
words for
             ;;      the purpose of abbrev expansion.
             ;;   -  Then we call expand-abbrev again, recursively, to
do
             ;;      the abbrev expansion with the above syntax table.
             ;;   -  Restore the previous syntax table.
             ;;   -  Then we do a trick which tells the expand-abbrev
frame
             ;;      which invoked us to not continue (and thus not
             ;;      expand twice.) This means that any abbrev
expansion
             ;;      will happen as a result of this function's call
to
             ;;      expand-abbrev, and not as a result of the call to
             ;;      expand-abbrev which invoked *us*.

Personal Remark:

It "@" and "." had syntax "_" here, they would be set to "w" in the
mail-abbrev-syntax-table defined below, which is what should be
happening.  But they have syntax "." (see below) and it stays ".".

             (make-local-variable 'mail-abbrev-syntax-table)
             (unless mail-abbrev-syntax-table
               (let ((tab (copy-syntax-table old-syntax-table))
                     (_ (aref (standard-syntax-table) ?_))
                     (w (aref (standard-syntax-table) ?w)))
                 (map-char-table
                  (function (lambda (key value)
                              (if (equal value _)
                                  (set-char-table-range tab key w))))
                  tab)
                 (setq mail-abbrev-syntax-table tab)))

             ;; If the character just typed was
                non-alpha-symbol-syntax,
             ;; then don't expand the abbrev now (that is, don't
                expand
             ;; when the user types -.)  Check the character's syntax
                in
             ;; the usual syntax table.

Personal Remarks:

I guess "usual syntax table" means the mail mode or message mode
syntax tables.  The trouble with these is that several characters have
punctuation syntax in these tables that really should have symbol
constituent syntax in the following code.  Relevant for the concrete
examples we have been discussing are "@" and ".".  They are not the
only ones.  A complete (or at least, so I believe) list is provided in
the definition of mail-mode-header-syntax-table.  That is why that
syntax table is needed.  Forget about the stuff in the documentation
string.  In my version, I deleted that.

If "." had syntax "_", the next two lines of code would prevent it
from expanding abbrevs.  But it has syntax ".".  Hence it does expand
abbrevs.

             (or (and (integerp last-command-char)
                      (eq (char-syntax last-command-char) ?_))
                 (let ((pre-abbrev-expand-hook nil)) ; That's us;
                      don't loop.
                   ;; Use this table so that abbrevs can have hyphens
                      in them.
Personal Remarks:

The next line of code is were "@" and "." and friends are supposed to
get set to "w".  As explained above, this does not happen.
		      
		      (set-syntax-table mail-abbrev-syntax-table)

                   (unwind-protect
                       (expand-abbrev)
                     ;; Now set it back to what it was before.
                     (set-syntax-table old-syntax-table))))
             (setq abbrev-start-location (point-max) ; This is the
                      trick.
                   abbrev-start-location-buffer (current-buffer)))

         (if (or (not mail-abbrevs-only)
                 (eq this-command 'expand-abbrev))
             ;; 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.
             nil
           ;; This is not a mail abbrev, and we should not expand it.
           ;; This kludge stops expand-abbrev from doing anything.
           (setq abbrev-start-location (point-max)
                 abbrev-start-location-buffer (current-buffer))))
       ))


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: mailabbrev.el, mailalias.el and related package.

[Luc Teirlinck]

Richard Stallman asked:

         Can you tell me which of the recent bugs (if any) your
         package does NOT fix?  And can you fix them?

I can now answer this more definitively:

My package totally takes care of all bugs posted on this site in
January and February on the mailabbrev issue.  (Unless I would have
missed one.)

Not a bug, but a possible inefficiency remains.  It currently has to
load sendmail.  Absolutely no problem for users of RMAIL, but
inefficient for users of message-mode.  I believe that problem will
not be too difficult to take care of once I get a chance to take a
look at message.el.

Although I clearly can not guarantee anything, I would guess that
delivering a completed and ready package may take from three to six
months.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: mailabbrev.el, mailalias.el and related package.

[Richard Stallman]

    Was your message below the final word on the subject?

Yes.

I appreciate your making an effort to work on this.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: mailabbrev.el, mailalias.el and related package.

[Richard Stallman]

	    Now, when I type

		To: emacs-devel@gnu.-!-

	    it gets expanded to

		To: emacs-devel@<gnu@gnu.org>

I reproduced the failure, and fixed it by changing the syntax
of @.  However, a subsequent message pointed out that other more
obscure problem cases remain.  I think the place to fix them is in
the pre-abbrev-expand-hook function.  It can check the context carefully,
I think, and prevent expansion in inappropriate circumstances.

    The current mailabbrev.el needs to write mailabbrevs in
    ~/.abbrevs_defs, because that is the only way it can save them.  Of
    course aliases defined in .mailrc are already stored there, but
    mailabbrev needs to worry about aliases defined in other ways.

That is a bug, which I fixed recently by labeling abbrevs read
from .mailrc as "system abbrevs" (a new feature).

      My
    package would change that totally, because it would have all aliases
    defined in .mailrc.  It would still use abbrevs internally, but these
    would be essentially invisible to users.

That is good.  mailabbrev should never store these in .abbrev_defs.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: mailabbrev.el, mailalias.el and related package.

[Luc Teirlinck]

I may have to correct, or at least amend, certain comments I made
about mail-mode-header-syntax-table in a previous message concerning
the aggressive mailabbrev expansion problem.

The analysis of the problem with aggressive mailabbrev expansion was,
I believe, correct.  However my interpretation of the importance of
mail-mode-header-syntax-table in the mailabbrev expansion process may
not have been.  What definitely is important is the step performed
there in the definition of mail-abbrev-syntax-table.

First of all, what I erroneously referred to as "the documentation
string" were actually the comments.

Secondly, it probably is possible to perform mailabbrev expansion
correctly using only mail-abbrev-syntax-table, by invoking the lines:

             (or (and (integerp last-command-char)
                      (eq (char-syntax last-command-char) ?_))

AFTER establishing the correct mail-abbrev-syntax-table and replacing
the ?_ in this code by ?w

That should be carefully checked, however.  

The intent of mail-mode-header-syntax-table as a separate syntax-table
may indeed only have been the forward-sexp stuff.  That is not the
only intent of the syntactic changes performed there, however.

To determine whether I keep or eliminate mail-mode-header-syntax-table
in my new package, I will have to check whether I need it elsewhere.

In essence, in my previous message, I confused the syntax table itself
with the actual syntactic steps performed there.

On another topic, in a previous message I sent to you, I
unintentionally deleted the CC field.  When I noticed this, I sent a
separate copy to emacs-devel@gnu.org.  I am sorry if this caused any
problems or confusion.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel