From: Bill Wohler <wohler@newt.com>
Subject: Re: buffer-offer-save, gnus and mh-e
Date: Mon, 09 Jan 2006 19:12:43 -0800 [thread overview]
Message-ID: <87y81og4ic.fsf@olgas.newt.com> (raw)
In-Reply-To: 200504171500.j3HF0Ha22225@raven.dms.auburn.edu
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.
next prev parent reply other threads:[~2006-01-10 3:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-17 15:00 buffer-offer-save, gnus and mh-e Luc Teirlinck
2005-04-17 17:44 ` Bill Wohler
2005-04-17 18:47 ` Luc Teirlinck
2005-04-17 19:11 ` Luc Teirlinck
2005-04-17 19:22 ` Bill Wohler
2005-04-17 20:25 ` Luc Teirlinck
2005-04-18 4:59 ` Bill Wohler
2005-04-18 21:06 ` Richard Stallman
2005-04-18 10:31 ` Reiner Steib
2006-01-10 3:12 ` Bill Wohler [this message]
2006-01-10 3:16 ` Luc Teirlinck
2006-01-10 3:25 ` Bill Wohler
2006-01-11 0:49 ` Richard M. Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y81og4ic.fsf@olgas.newt.com \
--to=wohler@newt.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).