message-add-action problem

message-add-action problem

[Karl Kleinpaste]

No Gnus v0.3, XEmacs 21.5.20.

For a very long time, I've been doing message composition in a separate
frame, using code I got from someone (unremembered, regrets) on this list:

  ; destroy the composition frame on any kind of exit from composition.
  (defun delete-frame-unless-tty ()
         (if (equal (console-type) 'x)
           (delete-frame)))
  (message-add-action 'delete-frame-unless-tty 'exit 'postpone 'kill)

  ; function to express "separate frame for composition startup".
  ; this is used conditionally on being in an X frame already.
  (setq gnus-karl-message-configuration
	'(frame 1.0
		(if (not (buffer-live-p gnus-summary-buffer))
		    (car (cdr (assoc 'group gnus-buffer-configuration)))
		  (car (cdr (assoc 'article gnus-buffer-configuration))))
		(vertical ((user-position . t)
			   (top . 4) (left . -1)
			   (name . "Message")) (message 1.0 point))))

  (gnus-add-configuration (list 'message gnus-karl-message-configuration))
  ; plus several similar -add-configs, for 'reply and whatnot.

However, since I upgraded to No v0.3, my message composition frames
are not deleted on send/kill/postpone any more.

message-mode's define-derived-mode in message.el is destroying the
global value of message-*-actions by making them all locals and
aggressively setting them to nil.  This can't possibly be correct,
unless these variables were never meant to be user-accessible.  That
was not my understanding.

When I tweak message-mode to re-assert those variables' values in the
make-local, the basic idea seems to come back...except that it's my
main Gnus frame that gets deleted, leaving the composition frame,
exactly the wrong effect.  (But that frame now shows *Summary*.)

A side issue is that, with some regularity but no consistency I have
yet identified, when I start composition, sometimes the newly-created
frame gets used by Gnus for the original pile of normal Gnus buffers
and the original frame is taken over for the message buffer all
alone...again, exactly the wrong effect.

I've tried to crawl through the text in info://Gnus/Window+Layout but
frankly the wording is so convoluted that I simply don't follow it.  I
tried adding a "frame-focus" element to the specification shown above,
next to "point", but it didn't seem to have any effect at all.

Can anyone offer thoughts on [a] why the message-*-actions are being
canceled by message-mode in the first place, [b] how to reliably get
their global values in use again, [c] why Gnus is deleting exactly the
wrong frame, and [d] why the new frame is sometimes misused as the
general Gnus buffer set instead of just for message composition?

--karl

Re: message-add-action problem

[Katsumi Yamaoka]

>>>>> In <vxkacnsai8t.fsf@mesquite.charcoal.com> Karl Kleinpaste wrote:

> No Gnus v0.3, XEmacs 21.5.20.

> For a very long time, I've been doing message composition in a separate
> frame, using code I got from someone (unremembered, regrets) on this list:

>   ; destroy the composition frame on any kind of exit from composition.
>   (defun delete-frame-unless-tty ()
>          (if (equal (console-type) 'x)
>            (delete-frame)))
>   (message-add-action 'delete-frame-unless-tty 'exit 'postpone 'kill)

[...]

> However, since I upgraded to No v0.3, my message composition frames
> are not deleted on send/kill/postpone any more.

> message-mode's define-derived-mode in message.el is destroying the
> global value of message-*-actions by making them all locals and
> aggressively setting them to nil.  This can't possibly be correct,
> unless these variables were never meant to be user-accessible.  That
> was not my understanding.

AFAIK, message-*-actions were all buffer-local over nine years.

> When I tweak message-mode to re-assert those variables' values in the
> make-local, the basic idea seems to come back...except that it's my
> main Gnus frame that gets deleted, leaving the composition frame,
> exactly the wrong effect.  (But that frame now shows *Summary*.)

So, that is just what we have to do.  I'm sorry not to have time
to analyze your code, but I'm satisfied with mine:

ftp://ftp.jpl.org/pub/elisp/message-multiple-frames.el.gz
 or http://www.jpl.org/ftp/pub/elisp/message-multiple-frames.el.gz

It also might be incomplete, though.

Re: message-add-action problem

[Karl Kleinpaste]

Katsumi Yamaoka <yamaoka@jpl.org> writes:
> AFAIK, message-*-actions were all buffer-local over nine years.

No.  I have 5.10.3 lying around, and its message.el, with mod date of
14 June 2003, makes these local (for purpose of adding some one-time
eval forms), but does not nil them out.  So the effect is that one's
preferred actions are combined with the one-time forms.

I just tried running that 5.10.3, and it works as expected other than
that it, too, deletes the wrong frame.  This is evidently an Xemacs
21.5 difficulty.

> ftp://ftp.jpl.org/pub/elisp/message-multiple-frames.el.gz
>  or http://www.jpl.org/ftp/pub/elisp/message-multiple-frames.el.gz

I will take a look.  Thanx.

--karl

Re: message-add-action problem

[Katsumi Yamaoka]

>>>>> In <vxkr7h4nn1m.fsf@mesquite.charcoal.com> Karl Kleinpaste wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>> AFAIK, message-*-actions were all buffer-local over nine years.

> No.  I have 5.10.3 lying around, and its message.el, with mod date of
> 14 June 2003, makes these local (for purpose of adding some one-time
> eval forms), but does not nil them out.  So the effect is that one's
> preferred actions are combined with the one-time forms.

> I just tried running that 5.10.3, and it works as expected other than
> that it, too, deletes the wrong frame.  This is evidently an Xemacs
> 21.5 difficulty.

I see.  I found out Lars had changed `message-mode' so as to set
those variables as nil.

2003-10-16  Lars Magne Ingebrigtsen  <larsi@gnus.org>

	* message.el (message-inserted-headers): New variable.
	(message-mode): Make local.
	(message-mode): Set all the local action variables to nil.	

I guess Lars considered there may be those who invoke the
message-mail command from the message-mode buffer.  In that
case, message-*-actions will get excessive (or possibly harmful)
values in the second message buffer.  I think it can be improved
as follows:

  (set (make-local-variable 'message-*-actions)
       (default-value 'message-*-actions))

I don't think we should do that because the doc-strings for
those variables don't begin with "*", though.

Re: message-add-action problem

[Karl Kleinpaste]

Katsumi Yamaoka <yamaoka@jpl.org> writes:
> I found out Lars had changed `message-mode' so as to set
> those variables as nil.
> 	* message.el (message-inserted-headers): New variable.
> 	(message-mode): Make local.
> 	(message-mode): Set all the local action variables to nil.	
> I guess Lars considered there may be those who invoke the
> message-mail command from the message-mode buffer.

It seems unwise to nil them out because then no user settings are ever
useful, which raises the question of why the variables should exist at
all, other than temporary, local items.

> I think it can be improved as follows:
>   (set (make-local-variable 'message-*-actions)
>        (default-value 'message-*-actions))
> I don't think we should do that because the doc-strings for
> those variables don't begin with "*", though.

On that reasoning, would we not also make oodles of -hook variables
equally untouchable?  I doubt that was the intent.  I think such a fix
would be appropriate.

In any event, my particular problem is gone because I have tried your
message-multiple-frames.el and it works quite nicely.  I suggest you
include
        (provide 'message-multiple-frames)
at its end, so that it sits well with the rest of the require/provide
framework used elsewhere in Gnus.

Thank you very much.

--karl