buffer-offer-save, gnus and mh-e

buffer-offer-save, gnus and mh-e

[Luc Teirlinck]

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.

Sincerely,

Luc.

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

[Bill Wohler]

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

> I plan to make buffer-offer-save a permanent local.

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

> 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'.

Luc,

I'm a little confused by this since mh-folder-mode extends
fundamental-mode.

>                           For mh-e, I have no idea whatsoever how it
> is supposed to be handled.

We support Emacs 20.7, 21, and if CVS Emacs is to be 22, then we support
that too. We also support XEmacs 21. See
http://mh-e.sourceforge.net/prereq/, although I notice I need to update
this information with the content of
https://sourceforge.net/project/shownotes.php?release_id=263080.

> 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.

At least when we no longer support a particular version of Emacs that
the conditional covers, then we can remove the conditional.

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))

Also, is the setting of buffer-offer-save to nil in
mh-utils.el:(mh-find-path) still appropriate?

I'll make the change above and check it into CVS Emacs soon. I'll let
you know if I have additional questions or run into problems.

-- 
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.

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

[Luc Teirlinck]

Bill Wohler wrote:

   I'm a little confused by this since mh-folder-mode extends
   fundamental-mode.

I believe that I indeed got confused.  I am not very familiar with
mh-e.  I use mail-mode myself.  The normal mode for mail buffers in
mh-e appears to be mh-letter-mode.  That one does not appear to set
buffer-offer-save, unlike mail-mode and message-mode.  After my
proposed change it would, when invoked via compose-mail.  I could
avoid that by checking mail-user-agent in compose-mail.  But should
mail buffers not set buffer-offer-save to t, because otherwise the
user might loose work if inadvertently exiting Emacs?
`mh-compose-and-send-mail' could do it right after calling
mh-letter-mode.  (I now saw that mh-e can be invoked in a way that
bypasses compose-mail).

I now believe that mh-make-folder should set buffer-offer-save to t
right after calling mh-folder-mode.

   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))

Unfortunately, to play it completely save, that might still be
necessary (even if mh-make-folder already would set buffer-offer-save
to t) because if the user switches modes in the buffer, then in prior
Emacs versions and XEmacs, the local variable buffer-offer-save will
be killed.

   Also, is the setting of buffer-offer-save to nil in
   mh-utils.el:(mh-find-path) still appropriate?

Yes.  mh-find-path is not a major mode (or so I believe).  I believe
all that one does is avoid asking the user to save a temporary buffer
(mh-temp-buffer) created by mh-find-path.  Correct?

Sincerely,

Luc.

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

[Luc Teirlinck]

>From my previous message:

   But should mail buffers not set buffer-offer-save to t, because
   otherwise the user might loose work if inadvertently exiting Emacs?

Or mybe mh-e already prevents that in a different way (other than just
autosaving, which may not have saved the very latest version)?

Sincerely,

Luc.

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

[Bill Wohler]

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

> From my previous message:
> 
>    But should mail buffers not set buffer-offer-save to t, because
>    otherwise the user might loose work if inadvertently exiting Emacs?
> 
> Or mybe mh-e already prevents that in a different way (other than just
> autosaving, which may not have saved the very latest version)?

I'll check.

-- 
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.

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

[Luc Teirlinck]

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.

Sincerely,

Luc.

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

[Bill Wohler]

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

> 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.  

Acknowledged.

FYI, if you or anyone else require changes to MH-E and you want to be
sure that I get the message, please try to remember to cc me (as you
did), or ensure that MH-E is in the Subject header field since I do
track the various Emacs lists for MH-E items.

Thanks!

-- 
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.

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

[Richard Stallman]

    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.

If we want to change this variable, we can change it.  We can make
some provisions for compatibility where that is useful, but
compatibility should not hold us back.

However, the issue of the various ways to get into message-mode
might be a real obstacle.

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

[Reiner Steib]

On Sun, Apr 17 2005, Luc Teirlinck wrote:

> 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'.

As you already wrote in a later message, this probably won't work for
Gnus because `compose-mail' is not the only entry point to
`message-mode'.

> 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.

The Gnus version in CVS Emacs corresponds to the stable branch (v5-10)
of Gnus which is supposed to work with Emacs 20.7 and up and XEmacs
21.1 and up.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

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

[Bill Wohler]

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.

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

[Luc Teirlinck]

Bill Wohler wrote:

   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?

It seems that way.

Sincerely,

Luc.

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

[Bill Wohler]

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

> Bill Wohler wrote:
> 
>    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?
> 
> It seems that way.

Thanks. I'll go ahead and close MH-E issue #1184756 (for now ;-).

-- 
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.

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

[Richard M. Stallman]

       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?

    It seems that way.

Let's change it after the release.