From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/60181 Path: news.gmane.org!not-for-mail From: Karl Kleinpaste Newsgroups: gmane.emacs.gnus.general Subject: message-add-action problem Date: Thu, 21 Apr 2005 00:03:46 -0400 Message-ID: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1114056648 25027 80.91.229.2 (21 Apr 2005 04:10:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 21 Apr 2005 04:10:48 +0000 (UTC) Original-X-From: ding-owner+M8708@lists.math.uh.edu Thu Apr 21 06:10:44 2005 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DOT1W-00069s-FL for ding-account@gmane.org; Thu, 21 Apr 2005 06:10:42 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1DOSvD-0002m9-00; Wed, 20 Apr 2005 23:04:11 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1DOSv5-0002m3-00 for ding@lists.math.uh.edu; Wed, 20 Apr 2005 23:04:03 -0500 Original-Received: from quimby.gnus.org ([80.91.224.244]) by util2.math.uh.edu with esmtp (Exim 4.30) id 1DOSv4-0004sn-0V for ding@lists.math.uh.edu; Wed, 20 Apr 2005 23:04:02 -0500 Original-Received: from zimbs-null.sp.cs.cmu.edu ([128.2.198.166] helo=mesquite.charcoal.com) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1DOSuy-0003NG-00 for ; Thu, 21 Apr 2005 06:03:56 +0200 Original-Received: from mesquite.charcoal.com (localhost [127.0.0.1]) by mesquite.charcoal.com (8.13.1/8.13.1) with ESMTP id j3L43nCA017381 for ; Thu, 21 Apr 2005 00:03:49 -0400 Original-Received: (from karl@localhost) by mesquite.charcoal.com (8.13.1/8.13.1/Submit) id j3L43k4t017380; Thu, 21 Apr 2005 00:03:46 -0400 Original-To: ding@gnus.org X-Face: ?=p^Gj2JkX~UU_@W}[q/'Dxn19x-zfIQ](y<&ky/?1-&Nz&,!W}R.Gp+"LeGojoR =RF>?!XVs{a:`Yt(gqM<#$Zy(C@]'dR4Hy4S1.I(n3:2"R:=Uy!)K9>U!gNTyH{p +_w#F[gt).$Vyvo5=9LF^PeQ(@H#}QLAbfyYxX/8t:TDR5nA\|RmJO"EwjL8tWyvM User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5-b20 (linux) X-Spam-Score: -4.6 (----) Precedence: bulk Original-Sender: ding-owner@lists.math.uh.edu Xref: news.gmane.org gmane.emacs.gnus.general:60181 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:60181 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