gnus-configure-buffer

gnus-configure-buffer

[Anders Melchiorsen]

I have tried and tried. I am unable to understand the manual on
Windows Configuration, though. I can get it to change looks somewhat
but I cannot make I do what I want it to do.

What I would like was for any message-mode buffer to pop up in its own 
frame. When I exit editing the message the frame should close. In
essence, this would mimic how for example Netscape handles the
composing of a message.

The point is that I want to be able to still use Gnus without putting
the message too far away (then I will forget that I am writing it).

How would I do it? Should I instead set some hooks up to make-frame
and delete-frame when I enter/leave message-mode? How would I do that, 
then?

Thanks a lot.

-- 
Regards, Anders
(address is valid)

Re: gnus-configure-buffer

[Hrvoje Niksic]

Anders Melchiorsen <and@kampsax.dtu.dk> writes:

> I have tried and tried. I am unable to understand the manual on
> Windows Configuration, though.

It's very tough to understand; however, once the light dawns on you,
the window configuration stuff is extremely powerful.  Here is what I
use to get a Tree display along with the Summary:

(gnus-add-configuration '(article
			    (vertical 1.0
				      (horizontal 0.25
						  (summary 0.75 point)
						  (tree 1.0))
				      (article 1.0))))

> What I would like was for any message-mode buffer to pop up in its
> own frame. When I exit editing the message the frame should close.

Hmm.  I am unable to beat Gnus into doing something like this.  One
might expect this to pop up a 10x10 frame for messages:

(gnus-add-configuration
 '(message (frame (height 10 width 10) (message 1.0))))

However, it stays content with showing the message in the existing
frame.  The following does create a new frame, but it doesn't respect
the plist, nor does it remove the new frame when `C-c C-k' is
performed.

(gnus-add-configuration
 '(message (frame (height 10 width 10) (message 1.0) (message 1.0))))

Also, with the above, the "old" frame changes to message, which is
wrong.

I am not sure current window-configuration stuff can be made to do
what you want automatically.  Lars, could you perhaps extend it to
accomodate this?  Is the current behaviour a bug or a feature?

Re: gnus-configure-buffer

[David S. Goldberg]

> Anders Melchiorsen <and@kampsax.dtu.dk> writes:
>> I have tried and tried. I am unable to understand the manual on
>> Windows Configuration, though.

I'll take some responsibility; back in either Red or September I had
so much trouble with it that when (to borrow from Hrvoje) then light
dawned on me and I finally got things working the way I wanted I sent
some fixes and additional examples to Lars, most, if not all of which
were incorporated.  If anyone else can do a better job of clarifying
that documentation, I would love to not have to answer these sorts of
questions any more :-)

>> What I would like was for any message-mode buffer to pop up in its
>> own frame. When I exit editing the message the frame should close.

I can help you with the first part.  The latter is something I was
unable to get to work without breaking other things.

>>>>> Hrvoje Niksic writes:

> However, it stays content with showing the message in the existing
> frame.  The following does create a new frame, but it doesn't
> respect the plist, nor does it remove the new frame when `C-c C-k'
> is performed.

In this case, I think you should replace your plist with an alist.  At
least, when I switched to XEmacs from GNU Emacs, I left my alists for
the gnus-buffer-configuration intact and they still work for me.

> Also, with the above, the "old" frame changes to message, which is
> wrong.

Dealing with this is the tricky part and here's how I fixed it.
Perhaps these examples should be added to the documentation.  Yes, I
think they should.  I'll file a bug report on it later with a
suggested fix.  For now here's what works for me:

      (gnus-add-configuration
       '(message
	 (frame 1.0
		(if (not (buffer-live-p gnus-summary-buffer))
		    (car (cdr (assoc 'group gnus-buffer-configuration)))
		  (car (cdr (assoc 'summary gnus-buffer-configuration))))
		(vertical ((user-position . t) (top . 1) (left . 1)
			   (name . "Gnus Edit"))
			  (message 1.0 point)))))

Note the first split.  I test to see if the summary buffer is live.
If so I assume I'm sending the message from the summary mode and use
my summary configuration.  Perhaps this won't always be the case
depending on your usage, but for me it works.  If the summary buffer
isn't live I assume I'm calling message from group mode and use that
configuration for the first frame.  The second part of the split
defines the new frame.  As I said, I use an alist (I see that the Gnus
documentation says to do that, btw) to position it in the upper left
hand corner and give it a name (for fvwm purposes, not really
necessary for anything else).  I don't do anything to try to make it
disappear.  When I'm done with it, I just switch it to display a bogus
buffer (so anything else that wants to display the buffer that shows
up when message finishes doesn't get confused) and iconify it.  I also
do this for editing group parameters and such.  My system is fairly
slow, and I send enough mail that having the frame created just once
is in some sense an optimization for me :-)

At one point I did try to have the frame deleted automagically when
done with message.  I tried playing with the various message hooks,
but everything I did caused more harm than good.  Unfortunately my
memory is fuzzy so I can't elaborate.  One thing I didn't try at the
time (because I didn't know about it or perhaps it didn't exist in
that version of Emacs), that might work, is to make the window in the
frame dedicated to the message buffer.  I'm not sure how best to make
that happen though.

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

Re: gnus-configure-buffer

[Hrvoje Niksic]

dsg@mitre.org (David S. Goldberg) writes:

> > However, it stays content with showing the message in the existing
> > frame.  The following does create a new frame, but it doesn't
> > respect the plist, nor does it remove the new frame when `C-c C-k'
> > is performed.
> 
> In this case, I think you should replace your plist with an alist.

Then it is a bug, because the manual explicitly says that plists are
allowed under XEmacs.  Lars, what do you think?

> At least, when I switched to XEmacs from GNU Emacs, I left my alists
> for the gnus-buffer-configuration intact and they still work for me.

Well, yes, that is because XEmacs supports alists for backward
compatibility.  If, once upon a time, XEmacs stops supporting alists
things will break.

> Dealing with this is the tricky part and here's how I fixed it.
> Perhaps these examples should be added to the documentation.  Yes, I
> think they should.  I'll file a bug report on it later with a
> suggested fix.  For now here's what works for me:
> 
>       (gnus-add-configuration
>        '(message
> 	 (frame 1.0
> 		(if (not (buffer-live-p gnus-summary-buffer))
> 		    (car (cdr (assoc 'group gnus-buffer-configuration)))
> 		  (car (cdr (assoc 'summary gnus-buffer-configuration))))
> 		(vertical ((user-position . t) (top . 1) (left . 1)
> 			   (name . "Gnus Edit"))
> 			  (message 1.0 point)))))

I think there should be a cleaner way of doing it.  There should be a
way of saying that you want `message' to be created in a new,
temporary frame, with the old frame being untouched.

Re: gnus-configure-buffer

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Then it is a bug, because the manual explicitly says that plists are
> allowed under XEmacs.  Lars, what do you think?

It does sound like a bug.  It's been ages since I've fiddled with the
windowing code, since it, like, seems to have been working for what I
do with it, so I'm not totally up to speed with how it's supposed to
work.

Anyone want to propose a patch?

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

Re: gnus-configure-buffer

[David S. Goldberg]

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

> I wrote:

>> In this case, I think you should replace your plist with an alist.

> And Hrvoje Niksic responded:

> Then it is a bug, because the manual explicitly says that plists are
> allowed under XEmacs.  Lars, what do you think?

I just changed my alists to plists and it appears to work the same for
me as the alists did.

> [my hack, er ah, example for grabbing the group or summary buffer
> config from gnus-buffer-configuration elided...]

> I think there should be a cleaner way of doing it.  There should be
> a way of saying that you want `message' to be created in a new,
> temporary frame, with the old frame being untouched.

I agree, but until that happens, here's a patch to gnus.texi from 0.69 
that describes my hack. I've also removed the section with the list of 
possible keys since it was wrong and is probably too much trouble to
keep track of.  Since the actual list for a given version can be
(according to the doc string, anyway) be found in the default value
for gnus-buffer-configuration, I refer the reader to that.

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

[-- Attachment #2: Type: application/x-patch, Size: 2464 bytes --]

Re: gnus-configure-buffer

[Jack Vinson]

>>>>> "AM" == Anders Melchiorsen <and@kampsax.dtu.dk> writes:

AM> I have tried and tried. I am unable to understand the manual on
AM> Windows Configuration, though. I can get it to change looks somewhat
AM> but I cannot make I do what I want it to do.
[snip]
AM> How would I do it? Should I instead set some hooks up to make-frame
AM> and delete-frame when I enter/leave message-mode? How would I do that, 
AM> then?

I was just playing with this a little.  message-send-and-exit calls the
list of actions in message-exit-actions.  If you add 'delete-frame to this
list of actions, message will delete the *message* frame after sending off
the message.  (There are several similar lists of message-.*-actions.  Gnus
uses these to return to the correct buffer configuration after the message
is sent.)

One could imagine adding delete-frame to the message-exit-actions in a
buffer-local fashion when opening this "temporary" message frame that
Anders suggests.  I don't know how one does this with
gnus-buffer-configuration.

With frame splits, the ideal situation would be to let one of the splits
actually be a window configuration object.  Then I could do something cool
like 
(gnus-add-configuration '(message 
			  (frame 1.0
				 (current-window-configuration)
				 (vertical ((height . 25) (width . 80)
					    (user-position . t)
					    (left . -1) (top . 1))
					   (message 1.0 point))
				 )))

-- 
Jack Vinson <jvinson@chevax.ecs.umass.edu>    http://www.cis.upenn.edu/~vinson/
Zippy: Ask me the DIFFERENCE between PHIL SILVERS and ALEXANDER HAIG!!