From mboxrd@z Thu Jan 1 00:00:00 1970 Path: quimby.gnus.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: mailabbrev.el, mailalias.el and related package. Date: Wed, 13 Feb 2002 22:40:41 -0600 (CST) Message-ID: <200202140440.WAA20427@eel.dms.auburn.edu> NNTP-Posting-Host: quimby2.netfonds.no X-Trace: quimby2.netfonds.no 1013662435 15813 195.204.10.66 (14 Feb 2002 04:53:55 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 14 Feb 2002 04:53:55 GMT Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby2.netfonds.no with esmtp (Exim 3.12 #1 (Debian)) id 16bDu5-00046x-00 for ; Thu, 14 Feb 2002 05:53:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16bDii-0005aA-00; Wed, 13 Feb 2002 23:42:08 -0500 Original-Received: from manatee.dms.auburn.edu ([131.204.53.104]) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16bDh3-0005Vd-00 for ; Wed, 13 Feb 2002 23:40:25 -0500 Original-Received: from eel.dms.auburn.edu (eel.dms.auburn.edu [131.204.53.108]) by manatee.dms.auburn.edu (8.9.1a/8.9.1) with ESMTP id WAA19156 for ; Wed, 13 Feb 2002 22:40:23 -0600 (CST) Original-Received: (from teirllm@localhost) by eel.dms.auburn.edu (8.9.3+Sun/8.9.3) id WAA20427; Wed, 13 Feb 2002 22:40:41 -0600 (CST) X-Authentication-Warning: eel.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: emacs-devel@gnu.org Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: quimby.gnus.org gmane.emacs.devel:1110 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1110 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 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 C-n C-a M-f M-f M-f 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 C-x 1 M-x b u C-g 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