Better handling of reply configuration

Better handling of reply configuration

[Reid Rivenburgh]

One of the few areas where gnus is awkward is the handling of
frames/windows when replying to mail.  I've looked over the gnus
configuration capabilities, but either it doesn't offer quite enough
or I'm too ignorant to use it correctly (yes, probably the latter).  I
also searched in various places and came up basically empty.

The problem is that when replying, the reply buffer takes over the
frame.  If I want to refer back to the original message (if I haven't
yanked it into the reply) or look at a different message, I have to go
through some buffer switching and resizing contortions.

This can be solved by either:

1. Giving the reply its own frame.  This would work fine, but I've had
   a heck of a time getting the frame to go away (delete or iconify)
   when done and having the original frame be unaffected by the reply
   creation.  It would also be nice for general mail composition, not
   just replying.

2. Set up a configuration in a single frame such that the reply takes
   up only a portion of the frame, leaving the summary and article
   buffers visible (but probably reduced in size).  This ought to
   work, too, but there's a question of what happens to the reply
   buffer if I quit the summary to look in another group.  I tried the
   following, but I didn't know how the buffer-live-p split form
   syntax should look (the example in the manual only uses a single
   form after the if).  I think I'm on the right track....

(gnus-add-configuration
 '(reply
   (horizontal 1.0
	       (vertical 20
			 (if (buffer-live-p gnus-message-buffer)
			     '(list (summary .2)
				    (message 1.0 point))
			   '((summary .8 point)
			     (tree 1.0))))
	       (vertical 1.0
			 (article 1.0)))))

I thought I'd throw this out to the list in case anyone has solved the
problem.  Thanks in advance.

Reid

Re: Better handling of reply configuration

[Kai Großjohann]

Reid Rivenburgh <reid@lanl.gov> writes:

> The problem is that when replying, the reply buffer takes over the
> frame.

Not true for me.  I haven't changed the default settings concerning
windows.

When I hit `R' or `F', the original article buffer disappears and the
reply buffer takes the whole frame.  This is okay, since the original
article is quoted in the reply and can therefore be seen.

When I hit `r' or `f', the frame is split, showing both the original
article and the reply.

Did you change the frame/window configuration?

kai
-- 
~/.signature: No such file or directory

Re: Better handling of reply configuration

[Reid Rivenburgh]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1520 bytes --]

 >> Kai Großjohann writes:

 > Reid Rivenburgh <reid@lanl.gov> writes:
 >> The problem is that when replying, the reply buffer takes over the
 >> frame.

 > Not true for me.  I haven't changed the default settings concerning
 > windows.

 > When I hit `R' or `F', the original article buffer disappears and
 > the reply buffer takes the whole frame.  This is okay, since the
 > original article is quoted in the reply and can therefore be seen.

 > When I hit `r' or `f', the frame is split, showing both the
 > original article and the reply.

 > Did you change the frame/window configuration?

I think you're right, I was confused about that.  (I've been playing
with so many configurations here that I'm getting loopy.)  The
original article displayed with `r' or `f' is a raw copy, correct?
With no highlighting and all headers displayed.  Usually, the headers
fill up the entire window, unfortunately....  It'd be nice if it
automatically scrolled to the end.  (Is there a hook for that?  I
haven't bothered looking, just wondering.)

In any case, the problem still stands that if I want to refer to a
different message in the same or a different group, it's a bit awkward
to navigate.  I think the configuration I was trying to achieve would
help there.  It would also just display the normal article buffer
(along with the summary buffer) rather than the raw copy, which is
better in most cases, I think.

Thanks for straightening me out regarding the above, though.

Reid

Re: Better handling of reply configuration

[Kai Großjohann]

For scrolling, I find the default M-next, M-prior, M-home and M-end
bindings quite useful.

For showing the article buffer rather than the raw article buffer, I
think you're right.

And for referring to a different article, you're also right.

kai
-- 
~/.signature: No such file or directory

Re: Better handling of reply configuration

[David S. Goldberg]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

> One of the few areas where gnus is awkward is the handling of
> frames/windows when replying to mail.  I've looked over the gnus
> configuration capabilities, but either it doesn't offer quite enough
> or I'm too ignorant to use it correctly (yes, probably the latter).  I
> also searched in various places and came up basically empty.

No, you're right.  It is awkward.  This has come up before on the
mailing list but there's no real satisfying solution.  As you've
already worked out with Kai, the defaults (in a single frame) are
pretty reasonable.

> 1. Giving the reply its own frame.  This would work fine, but I've had
>    a heck of a time getting the frame to go away (delete or iconify)
>    when done and having the original frame be unaffected by the reply
>    creation.  It would also be nice for general mail composition, not
>    just replying.

It gets really weird when you want to have your message buffer in a
different frame.  I use the following which works quite well, but I
feel like I shouldn't have had to do so much work to get it that way.

I use a large window dedicated to Gnus.  I put my group, article and
summary configs here for illustration 


[-- Attachment #2: Type: application/emacs-lisp, Size: 478 bytes --]

[-- Attachment #3: Type: text/plain, Size: 319 bytes --]


This is my message config.  The trick is to get the message
composition buffer in a separate frame while leaving the original
frame intact.  There should be a better way.  I started to hack at
something back in early pgnus days but didn't have time to do it
justice.  When ognus gets going, I hope to get back to it.


[-- Attachment #4: Type: application/emacs-lisp, Size: 367 bytes --]

[-- Attachment #5: Type: text/plain, Size: 848 bytes --]


First ignore the name in the frame params.  I use that to get fvwm2 to
give the window a specific icon in my fvwm2 icon manager.  The key is
the if statement.  The message config is used when you do an m in
either the group or summary buffers to generate a new mail.  So if
there's a live summary buffer, I assume I'm in summary mode and I
enforce the summary configuration in the main frame and put the
message buffer in a new one.  If there's no summary, I enforce the
group configuration on the main frame.  Similar for the post
configuration.  For reply, reply-yank, forward and draft I do
essentially the same thing except there's no need to check for summary
mode.  In those cases I force article configuration (except for draft
which is summary) on the main frame and put the message in the new
frame.  Here's reply-yank to illustrate it.


[-- Attachment #6: Type: application/emacs-lisp, Size: 259 bytes --]

[-- Attachment #7: Type: text/plain, Size: 436 bytes --]


I don't remove the message frame after sending.  I write a lot of
email and find that the time spent rebuilding new frames is a
waste.  However, I believe you can use message-sent-hook to either
delete or iconfiy the frame.  Just make sure to select the right
frame for deleting or iconifying :-)

hth,
-- 
Dave Goldberg
Post: The Mitre Corporation\MS B325\202 Burlington Rd.\Bedford, MA 01730
Phone: 781-271-3887
Email: dsg@mitre.org

Re: Better handling of reply configuration

[Reid Rivenburgh]

David,

Thanks for the info and code.  I haven't tried using it yet, but it
sounds very helpful.

 > However, I believe you can use message-sent-hook to either
 > delete or iconfiy the frame.  Just make sure to select the right
 > frame for deleting or iconifying :-)

Believe it or not, I had a hard time doing just that!  I'm not much of
an elisper, and I wasn't sure of the right way to do that....  I was
kind of hoping the right one would be the current frame, and I could
leave out the optional frame argument.

Reid