'e' in the summary buffer leads to lost work

'e' in the summary buffer leads to lost work

[Matt Armstrong]

Recently Gnus clobbered about 15 minutes of edits in a message I was
preparing.  After mail back and forth with Lars, I now understand what
happened.  He suggested I solicit everybody here for ideas on how to
fix it.

What happened: I started editing an article in my drafts group with
'e' (gnus-summary-edit-articles).  The buffer Gnus gave me was the
*Article* buffer.  Then I wanted to look at some other e-mail I got,
so I switched to *Groups*, selected the group, then the article.  I
then realized that Gnus had replaced my (unsaved) work in *Article*
with this second article.

I frequently reference multiple piece of mail while composing a new
message.  I'd like to be able to do this while editing drafts as well.
More importantly, a program that silently deletes edits in any
situation is at least unfriendly if not evil (IMHO).

Possible ways to fix it:

1) Make 'e' in the drafts summary buffer do what 'D e' does.

   Lars didn't like this one because 'D e' implies you're going to send
   the draft, while 'e' doesn't.  I don't like it because it doesn't
   solve the problem for the general case (Gnus can automatically
   delete changes to articles in other groups).

2) Set gnus-single-article-buffer to t.

   I don't like it because it doesn't solve the general case (Gnus can
   still silently delete your 'e' edits if you select a different
   article in the same group).

3) Make 'e' create a new, non-*Article* buffer.

   The intent is to make every article you're editing not THE
   *Article* buffer.  Gnus never automatically deletes *Article Edit*
   buffers (at least without prompting) and lets you view other
   articles in the *Article* buffer.  I like this one since it allows
   me to reference my other mail while editing a message.

Thoughts?


-- 
matta

Re: 'e' in the summary buffer leads to lost work

[Edward J. Sabol]

Excerpts from mail: (23-Feb-98) 'e' in the summary buffer leads to lost work by Matt Armstrong
> 3) Make 'e' create a new, non-*Article* buffer.

I like this solution the best. The buffer name should be based on various
header fields in the e-mail.

Re: 'e' in the summary buffer leads to lost work

[Paul Franklin]

>>>>> Edward J. Sabol writes:

 > Excerpts from mail: (23-Feb-98)
 > 'e' in the summary buffer leads to lost work by Matt Armstrong

 >> 3) Make 'e' create a new, non-*Article* buffer.

 > I like this solution the best. The buffer name should be based on various
 > header fields in the e-mail.

I like it too, though I think it should be named after the group and
article number, as a reminder that this is fundamentally different
than an attempt to send a message out.

--Paul

Re: 'e' in the summary buffer leads to lost work

[jari.aalto]

| 98-02-23 Paul Franklin <paul@cs.washington.edu> list.ding
|  >> 3) Make 'e' create a new, non-*Article* buffer.
| 
|  > I like this solution the best. The buffer name should be based on various
|  > header fields in the e-mail.
| 
| I like it too, though I think it should be named after the group and
| article number, as a reminder that this is fundamentally different
| than an attempt to send a message out.

I vote for group name + article number too.
jari

Re: 'e' in the summary buffer leads to lost work

[Lars Magne Ingebrigtsen]

"Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov> writes:

> I like this solution the best. The buffer name should be based on various
> header fields in the e-mail.

Ok; I've put this on the todo list.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: 'e' in the summary buffer leads to lost work

[Harry Putnam]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:


> "Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov> writes:
> 
> > I like this solution the best. The buffer name should be based on various
> > header fields in the e-mail.
 
A built in key sequence that starts gnus-info-find-node when in the
compose buffers ('F' &'R'), would be handy.  It seems I find lots of
situations when discussing Gnus or Emacs when I want to access the
Gnus info page in one jump.

I didn't see how to bind a command that is already bound in other modes
to something different in the Compose modes.  I'm sure it can be done as
a by the user but having it built in would be nice.



> -- 
> (domestic pets only, the antidote for overdose, milk.)
>   larsi@gnus.org * Lars Magne Ingebrigtsen