[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: buffer-offer-save, gnus and mh-e
From: |
Bill Wohler |
Subject: |
Re: buffer-offer-save, gnus and mh-e |
Date: |
Mon, 09 Jan 2006 19:12:43 -0800 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
Luc, as I was going through MH-E bug reports, I came across the
following:
https://sourceforge.net/tracker/index.php?func=detail&aid=1184756&group_id=13357&atid=113357
Back in April, 2005, you wrote:
Luc Teirlinck <address@hidden> writes:
> I plan to make buffer-offer-save a permanent local. This already has
> Richard's approval. It means that it will, as a matter of principle,
> no longer be appropriate for major modes to set buffer-offer-save,
> regardless of whether doing so produces any concrete user visible bugs.
>
> Grepping shows that the only affected modes are mail-mode,
> message-mode and mh-folder-mode, which set buffer-offer-save to t.
>
> The solution for that is to set buffer-offer-save to t in
> `compose-mail' and no longer set it in the individual mail modes. I
> checked that this works for mail-mode and message-mode. I could not
> check it for mh-folder-mode, but I guess that it must work, since it
> works through `compose-mail'.
>
> For mail-mode there is no problem. For message-mode and
> mh-folder-mode, I was wondering. I know that the gnus directory is
> automatically synched, but I do not know whether the version of gnus
> included with CVS Emacs is also supposed to work with prior Emacs
> versions or with XEmacs. For mh-e, I have no idea whatsoever how it
> is supposed to be handled.
>
> If conditionals would be required, things might look somewhat strange,
> because setting buffer-offer-save would still be harmless, even in
> Emacs 22. The only problem is that major modes are not supposed to
> touch permanent locals.
After a bit of discussion, you concluded with:
> Bill Wohler wrote:
>
> Just to be sure I'm understanding correctly, you'd like to see the
> following code in mh-e.el:(mh-folder-mode), right?
>
> (if (or mh-xemacs-flag (< emacs-major-version 22))
> (setq buffer-offer-save t))
>
> Please wait a little bit with this. After taking a closer look at the
> code involved, I realized that things are more complex than I thought.
> `compose-mail' is the wrong place to set `buffer-offer-save', since it
> can easily be bypassed. I believe that the various return values of
> (get mail-user-agent 'composefunc) should be handled separately.
>
> I do not know the various mail modes sufficiently to reliable take
> care of this and the backward and XEmacs compatibility issues
> complicate things and could make the involved code needlessly ugly.
>
> So I now believe that I will leave `buffer-offer-save' a non-permanent
> local. (But maybe someone else could volunteer to do it and solve all
> involved problems)
>
> It would be easier if one did not adhere as strictly to the principle
> that major modes never should touch permanent locals. Then everything
> that would be needed would be to add one single line in files.el. But
> Richard told me that there were absolutely no exceptions to that rule.
I see that buffer-offer-save in files.el is still not a permanent
local. Is it going to remain that way for the foreseeable future? In
other words, can I close my bug? ;-)
--
Bill Wohler <address@hidden> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.
- Re: buffer-offer-save, gnus and mh-e,
Bill Wohler <=