Re: buffer-offer-save, gnus and mh-e

[Bill Wohler <wohler@newt.com>]

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 <teirllm@dms.auburn.edu> 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 <wohler@newt.com>  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.