compose new message in new frame

compose new message in new frame

[Eric S Fraga]

I currently have gnus configured (using gnus-add-configuration) as follows:

--8<---------------cut here---------------start------------->8---
(gnus-add-configuration
 '(message
    (frame 1.0
             (vertical (message 1.0 point)))))
--8<---------------cut here---------------end--------------->8---

(elided, hopefully correctly, to the minimal bits as the body is
actually a cond which changes the behaviour depending on the monitor
size)

This does bring up a frame with the composition buffer but the original
frame also shows the same buffer, not the (say) summary and article that
I was reading.

The documentation, although quite extensive, doesn't tell me how to
ensure the original frame stays as it is/was before asking to compose a
new message.  Any suggestions welcome!

Thank you,
eric

-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-05-02) on Debian 11.6

Re: compose new message in new frame

[Felix Natter]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

[..]

hello Eric,

just a note, may or may not hit you: I ran into a bug where the Gcc:
header is not generated (and thus the mail is not archived) if you
compose a mail from a secondary frame (C-x 5 m or C-x 5 2, then m):

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62345

Best Regards,
Felix
--
Felix Natter
debian/rules!

Re: compose new message in new frame

[Andrew Cohen]

>>>>> "ESF" == Eric S Fraga <e.fraga@ucl.ac.uk> writes:

    ESF> I currently have gnus configured (using gnus-add-configuration)
    ESF> as follows: (gnus-add-configuration '(message (frame 1.0
    ESF> (vertical (message 1.0 point)))))

    ESF> (elided, hopefully correctly, to the minimal bits as the body
    ESF> is actually a cond which changes the behaviour depending on the
    ESF> monitor size)

    ESF> This does bring up a frame with the composition buffer but the
    ESF> original frame also shows the same buffer, not the (say)
    ESF> summary and article that I was reading.

You have to include the explicit config for it. For example I use
something like this (and similar things for reply, reply-yank, and forward):

(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 . "Message"))
                    (message 1.0 point)))))

(You also might want to kill the frame afterwards:

(add-hook 'gnus-message-setup-hook
	  (lambda ()
	    (message-add-action #'delete-frame 'exit 'postpone 'kill)))

-- 
Andrew Cohen

Re: compose new message in new frame

[Eric S Fraga]

On Saturday, 10 Jun 2023 at 15:03, Felix Natter wrote:
> just a note, may or may not hit you: I ran into a bug where the Gcc:
> header is not generated (and thus the mail is not archived) if you
> compose a mail from a secondary frame (C-x 5 m or C-x 5 2, then m):

Thank you for highlighting this.  I do see this sometimes.

-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-06-11) on Debian 12.0

Re: compose new message in new frame

[Eric S Fraga]

On Saturday, 10 Jun 2023 at 21:41, Andrew Cohen wrote:
> You have to include the explicit config for it. For example I use
> something like this (and similar things for reply, reply-yank, and forward):

Thank you.

What you are using is what the manual suggests and I had actually tried
that already.  However, it doesn't work for me for some reason.  What I
get is that the new frame is created with the summary or group
configuration and the original frame (which no longer has focus) has the
message composition buffer.  So basically the wrong way around.

More playing around required, methinks.

And I wonder whether I could simply use display-buffer-alist...?

> (You also might want to kill the frame afterwards:
>
> (add-hook 'gnus-message-setup-hook
> 	  (lambda ()
> 	    (message-add-action #'delete-frame 'exit 'postpone 'kill)))

Very nice compact solution.  Thanks again.

eric

-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-06-11) on Debian 12.0

Re: compose new message in new frame

[Andrew Cohen]

>>>>> "ESF" == Eric S Fraga <e.fraga@ucl.ac.uk> writes:

    ESF> On Saturday, 10 Jun 2023 at 21:41, Andrew Cohen wrote:
    >> You have to include the explicit config for it. For example I use
    >> something like this (and similar things for reply, reply-yank,
    >> and forward):

    ESF> Thank you.

    ESF> What you are using is what the manual suggests and I had
    ESF> actually tried that already.  However, it doesn't work for me
    ESF> for some reason.  What I get is that the new frame is created
    ESF> with the summary or group configuration and the original frame
    ESF> (which no longer has focus) has the message composition buffer.
    ESF> So basically the wrong way around.

That is odd (FWIW I have been using this for years without trouble). My
only guess is somehow the group and summary buffer configurations have
been modified from the default so that frobbing them might not do the
right thing. You might play around (although you might have already
tried) with explicit configurations to see what you can control. That
is, instead of using (car (cdr (assoc 'group
gnus-buffer-configuration))) (and ditto for the summary configuration)
just try an explicit split, for example:

(gnus-add-configuration
 '(message
   (frame 1.0
          (vertical  1.0
                    (summary 1.0))
          (vertical ((user-position . t) (top . 1) (left . 1)
                     (name . "Message"))
                    (message 1.0 point)))))
and see what happens. Does it still swap the frames?



-- 
Andrew Cohen

Re: compose new message in new frame

[Eric S Fraga]

On Saturday, 17 Jun 2023 at 07:46, Andrew Cohen wrote:
> My only guess is somehow the group and summary buffer configurations
> have been modified from the default so that frobbing them might not do
> the right thing. 

I agree.  I will play around.  Thank you.

-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-06-16) on Debian 12.0