From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 19 11:02:05 2013 Received: (at submit) by debbugs.gnu.org; 19 Aug 2013 15:02:05 +0000 Received: from localhost ([127.0.0.1]:40505 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBQy3-0005cs-MO for submit@debbugs.gnu.org; Mon, 19 Aug 2013 11:02:04 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40654) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBQxx-0005cG-Hi for submit@debbugs.gnu.org; Mon, 19 Aug 2013 11:01:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBQxi-0000Ph-83 for submit@debbugs.gnu.org; Mon, 19 Aug 2013 11:01:52 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-99.2 required=5.0 tests=BAYES_50,USER_IN_WHITELIST autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:38199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBQxi-0000Pd-5X for submit@debbugs.gnu.org; Mon, 19 Aug 2013 11:01:42 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42295) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBQxZ-0004eb-Ga for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2013 11:01:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBQxQ-0000LD-RW for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2013 11:01:33 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:34475) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBQxQ-0000Km-Ja for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2013 11:01:24 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7JF1I1n025572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 19 Aug 2013 15:01:21 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JF1Hx3020902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Aug 2013 15:01:18 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JF1Hd5020865 for ; Mon, 19 Aug 2013 15:01:17 GMT MIME-Version: 1.0 Message-ID: <6bb534ef-d80b-4c35-9538-2ee383d95610@default> Date: Mon, 19 Aug 2013 08:01:20 -0700 (PDT) From: Drew Adams To: bug-gnu-emacs@gnu.org Subject: 24.3.50; REGRESSION: `after-make-frame-functions' now run with wrong frame selected X-Priority: 2 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -2.4 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) This regression was introduced after a build from 2013-08-08. It appears in the build cited below, from 2013-08-18. It makes Emacs unusable (by me). I have this as `after-make-frame-functions': `(fit-frame)', in order to fit the new frame to its displayed buffer.' When `after-make-frame-functions' is run in `make-frame' now, the original frame, not the newly created frame, is selected when it runs. So `fit-frame' is called with the original (wrong) frame selected. Here is a snapshot from the debugger: Debugger entered--entering a function: * fit-frame(#) * run-hook-with-args(fit-frame #) * (let* ((display (cdr (assq (quote display) parameters))) (w (cond ((assq = =3D (quote terminal) parameters) (let ((type ...)) (cond (... nil) (... ...) (t= =3D type)))) ((assq (quote window-system) parameters) (cdr (assq (quote window= =3D -system) parameters))) (display (or (window-system-for-display display) (er= =3D ror "Don't know how to interpret display \"%S\"" display))) (t window-syste= =3D m))) (frame-creation-function (cdr (assq w frame-creation-function-alist)))= =3D (oldframe (selected-frame)) (params parameters) frame) (if frame-creation-= =3D function nil (error "Don't know how to create a frame on window system %s" = =3D w)) (if (get w (quote window-system-initialized)) nil (funcall (cdr (assq w= =3D window-system-initialization-alist)) display) (setq x-display-name display= =3D ) (put w (quote window-system-initialized) t)) (progn (let ((--dolist-tail-= =3D - (cdr (assq w window-system-default-frame-alist))) p) (while --dolist-tail= =3D -- (setq p (car --dolist-tail--)) (if (assq (car p) params) nil (setq param= =3D s (cons p params))) (setq --dolist-tail-- (cdr --dolist-tail--))))) (progn = =3D (let ((--dolist-tail-- default-frame-alist) p) (while --dolist-tail-- (setq= =3D p (car --dolist-tail--)) (if (assq (car p) params) nil (setq params (cons = =3D p params))) (setq --dolist-tail-- (cdr --dolist-tail--))))) (run-hooks (quo= =3D te before-make-frame-hook)) (setq frame (funcall frame-creation-function pa= =3D rams)) (normal-erase-is-backspace-setup-frame frame) (progn (let ((--dolist= =3D -tail-- frame-inherited-parameters) param) (while --dolist-tail-- (setq par= =3D am (car --dolist-tail--)) (if (assq param parameters) nil (let ((val ...)) = =3D (if val (progn ...)))) (setq --dolist-tail-- (cdr --dolist-tail--))))) (run= =3D -hook-with-args (quote after-make-frame-functions) frame) frame) * (lambda (&optional parameters) "Return a newly created frame displaying t= =3D he current buffer.\nOptional argument PARAMETERS is an alist of frame param= =3D eters for\nthe new frame. Each element of PARAMETERS should have the\nform= =3D (NAME . VALUE), for example:\n\n (name . STRING)=09The frame should be nam= ed=3D STRING.\n\n (width . NUMBER)=09The frame should be NUMBER characters in wi= dt=3D h.\n (height . NUMBER)=09The frame should be NUMBER text lines high.\n\nYou= c=3D annot specify either `width' or `height', you must specify\nneither or both= =3D .\n\n (minibuffer . t)=09The frame should have a minibuffer.\n (minibuffer = . =3D nil)=09The frame should have no minibuffer.\n (minibuffer . only)=09The fra= me s=3D hould contain only a minibuffer.\n (minibuffer . WINDOW)=09The frame should= u=3D se WINDOW as its minibuffer window.\n\n (window-system . nil)=09The frame s= ho=3D uld be displayed on a terminal device.\n (window-system . x)=09The frame sh= ou=3D ld be displayed in an X window.\n\n (display . \":0\") The frame should= =3D appear on display :0.\n\n (terminal . TERMINAL) The frame should use the = =3D terminal object TERMINAL.\n\nIn addition, any parameter specified in `defau= =3D lt-frame-alist',\nbut not present in PARAMETERS, is applied.\n\nBefore crea= =3D ting the frame (via `frame-creation-function-alist'),\nthis function runs t= =3D he hook `before-make-frame-hook'. After\ncreating the frame, it runs the h= =3D ook `after-make-frame-functions'\nwith one arg, the newly created frame.\n\= =3D nIf a display parameter is supplied and a window-system is not,\nguess the = =3D window-system from the display.\n\nOn graphical displays, this function doe= =3D s not itself make the new\nframe the selected frame. However, the window s= =3D ystem may select\nthe new frame according to its own rules." (interactive) = =3D (let* ((display (cdr (assq (quote display) parameters))) (w (cond ((assq (q= =3D uote terminal) parameters) (let (...) (cond ... ... ...))) ((assq (quote wi= =3D ndow-system) parameters) (cdr (assq ... parameters))) (display (or (window-= =3D system-for-display display) (error "Don't know how to interpret display \"%= =3D S\"" display))) (t window-system))) (frame-creation-function (cdr (assq w f= =3D rame-creation-function-alist))) (oldframe (selected-frame)) (params paramet= =3D ers) frame) (if frame-creation-function nil (error "Don't know how to creat= =3D e a frame on window system %s" w)) (if (get w (quote window-system-initiali= =3D zed)) nil (funcall (cdr (assq w window-system-initialization-alist)) displa= =3D y) (setq x-display-name display) (put w (quote window-system-initialized) t= =3D )) (progn (let ((--dolist-tail-- (cdr (assq w window-system-default-frame-a= =3D list))) p) (while --dolist-tail-- (setq p (car --dolist-tail--)) (if (assq = =3D (car p) params) nil (setq params (cons p params))) (setq --dolist-tail-- (c= =3D dr --dolist-tail--))))) (progn (let ((--dolist-tail-- default-frame-alist) = =3D p) (while --dolist-tail-- (setq p (car --dolist-tail--)) (if (assq (car p) = =3D params) nil (setq params (cons p params))) (setq --dolist-tail-- (cdr --dol= =3D ist-tail--))))) (run-hooks (quote before-make-frame-hook)) (setq frame (fun= =3D call frame-creation-function params)) (normal-erase-is-backspace-setup-fram= =3D e frame) (progn (let ((--dolist-tail-- frame-inherited-parameters) param) (= =3D while --dolist-tail-- (setq param (car --dolist-tail--)) (if (assq param pa= =3D rameters) nil (let (...) (if val ...))) (setq --dolist-tail-- (cdr --dolist= =3D -tail--))))) (run-hook-with-args (quote after-make-frame-functions) frame) = =3D frame))(nil) * apply((lambda (&optional parameters) "Return a newly created frame displa= =3D ying the current buffer.\nOptional argument PARAMETERS is an alist of frame= =3D parameters for\nthe new frame. Each element of PARAMETERS should have the= =3D \nform (NAME . VALUE), for example:\n\n (name . STRING)=09The frame should = be=3D named STRING.\n\n (width . NUMBER)=09The frame should be NUMBER characters= i=3D n width.\n (height . NUMBER)=09The frame should be NUMBER text lines high.\= n\=3D nYou cannot specify either `width' or `height', you must specify\nneither o= =3D r both.\n\n (minibuffer . t)=09The frame should have a minibuffer.\n (minib= uf=3D fer . nil)=09The frame should have no minibuffer.\n (minibuffer . only)=09T= he f=3D rame should contain only a minibuffer.\n (minibuffer . WINDOW)=09The frame = sh=3D ould use WINDOW as its minibuffer window.\n\n (window-system . nil)=09The f= ra=3D me should be displayed on a terminal device.\n (window-system . x)=09The fr= am=3D e should be displayed in an X window.\n\n (display . \":0\") The frame = =3D should appear on display :0.\n\n (terminal . TERMINAL) The frame should us= =3D e the terminal object TERMINAL.\n\nIn addition, any parameter specified in = =3D `default-frame-alist',\nbut not present in PARAMETERS, is applied.\n\nBefor= =3D e creating the frame (via `frame-creation-function-alist'),\nthis function = =3D runs the hook `before-make-frame-hook'. After\ncreating the frame, it runs= =3D the hook `after-make-frame-functions'\nwith one arg, the newly created fra= =3D me.\n\nIf a display parameter is supplied and a window-system is not,\ngues= =3D s the window-system from the display.\n\nOn graphical displays, this functi= =3D on does not itself make the new\nframe the selected frame. However, the wi= =3D ndow system may select\nthe new frame according to its own rules." (interac= =3D tive) (let* ((display (cdr (assq (quote display) parameters))) (w (cond ((a= =3D ssq (quote terminal) parameters) (let (...) (cond ... ... ...))) ((assq (qu= =3D ote window-system) parameters) (cdr (assq ... parameters))) (display (or (w= =3D indow-system-for-display display) (error "Don't know how to interpret displ= =3D ay \"%S\"" display))) (t window-system))) (frame-creation-function (cdr (as= =3D sq w frame-creation-function-alist))) (oldframe (selected-frame)) (params p= =3D arameters) frame) (if frame-creation-function nil (error "Don't know how to= =3D create a frame on window system %s" w)) (if (get w (quote window-system-in= =3D itialized)) nil (funcall (cdr (assq w window-system-initialization-alist)) = =3D display) (setq x-display-name display) (put w (quote window-system-initiali= =3D zed) t)) (progn (let ((--dolist-tail-- (cdr (assq w window-system-default-f= =3D rame-alist))) p) (while --dolist-tail-- (setq p (car --dolist-tail--)) (if = =3D (assq (car p) params) nil (setq params (cons p params))) (setq --dolist-tai= =3D l-- (cdr --dolist-tail--))))) (progn (let ((--dolist-tail-- default-frame-a= =3D list) p) (while --dolist-tail-- (setq p (car --dolist-tail--)) (if (assq (c= =3D ar p) params) nil (setq params (cons p params))) (setq --dolist-tail-- (cdr= =3D --dolist-tail--))))) (run-hooks (quote before-make-frame-hook)) (setq fram= =3D e (funcall frame-creation-function params)) (normal-erase-is-backspace-setu= =3D p-frame frame) (progn (let ((--dolist-tail-- frame-inherited-parameters) pa= =3D ram) (while --dolist-tail-- (setq param (car --dolist-tail--)) (if (assq pa= =3D ram parameters) nil (let (...) (if val ...))) (setq --dolist-tail-- (cdr --= =3D dolist-tail--))))) (run-hook-with-args (quote after-make-frame-functions) f= =3D rame) frame)) nil) * make-frame(nil) (lambda nil (make-frame pop-up-frame-alist))() display-buffer-pop-up-frame(# ((inhibit-same-win= =3D dow . t))) display-buffer--maybe-pop-up-frame-or-window(# (= =3D (inhibit-same-window . t))) display-buffer(# t) pop-to-buffer(# t nil) switch-to-buffer-other-window(#) find-file-other-window("~/drews-lisp-20/autofit-frame.el" WILDCARDS) In GNU Emacs 24.3.50.1 (i686-pc-mingw32) of 2013-08-17 on ODIEONE Bzr revision: 113938 eliz@gnu.org-20130817171807-fxigtkbc6yy8m9iw Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --prefix=3D3D/c/Devel/emacs/binary --enable-checking=3D3Dyes,gl= yphs CFLAGS=3D3D-O0 -g3 LDFLAGS=3D3D-Lc:/Devel/emacs/lib CPPFLAGS=3D3D-Ic:/Devel/emacs/include' From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 19 11:08:32 2013 Received: (at 15133) by debbugs.gnu.org; 19 Aug 2013 15:08:32 +0000 Received: from localhost ([127.0.0.1]:40526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBR4K-0005nc-H6 for submit@debbugs.gnu.org; Mon, 19 Aug 2013 11:08:32 -0400 Received: from userp1050.oracle.com ([156.151.31.82]:27631) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBR4H-0005nJ-LR for 15133@debbugs.gnu.org; Mon, 19 Aug 2013 11:08:30 -0400 Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by userp1050.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7JF8Ekj009297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <15133@debbugs.gnu.org>; Mon, 19 Aug 2013 15:08:22 GMT Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7JF864s001865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <15133@debbugs.gnu.org>; Mon, 19 Aug 2013 15:08:07 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JF86am022159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <15133@debbugs.gnu.org>; Mon, 19 Aug 2013 15:08:06 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JF862p022151 for <15133@debbugs.gnu.org>; Mon, 19 Aug 2013 15:08:06 GMT MIME-Version: 1.0 Message-ID: <3b87a174-646d-4c83-ba73-e196b090ace9@default> Date: Mon, 19 Aug 2013 08:08:09 -0700 (PDT) From: Drew Adams To: 15133@debbugs.gnu.org Subject: RE: bug#15133: 24.3.50; REGRESSION: `after-make-frame-functions' now run with wrong frame selected References: <6bb534ef-d80b-4c35-9538-2ee383d95610@default> In-Reply-To: <6bb534ef-d80b-4c35-9538-2ee383d95610@default> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userp1040.oracle.com [156.151.31.81] X-Spam-Score: -5.1 (-----) X-Debbugs-Envelope-To: 15133 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.1 (-----) HTH: There was no code change in frame.el itself between the two builds cited, so the regression must have been introduced by other code. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 19 12:13:57 2013 Received: (at 15133) by debbugs.gnu.org; 19 Aug 2013 16:13:57 +0000 Received: from localhost ([127.0.0.1]:40653 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBS5c-00014a-Os for submit@debbugs.gnu.org; Mon, 19 Aug 2013 12:13:57 -0400 Received: from mout.gmx.net ([212.227.17.22]:61523) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBS5Y-00014B-LM for 15133@debbugs.gnu.org; Mon, 19 Aug 2013 12:13:54 -0400 Received: from [62.47.58.109] ([62.47.58.109]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0M8IuM-1VxO6S1oP4-00vvdC for <15133@debbugs.gnu.org>; Mon, 19 Aug 2013 18:13:46 +0200 Message-ID: <52124432.9010707@gmx.at> Date: Mon, 19 Aug 2013 18:13:38 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#15133: 24.3.50; REGRESSION: `after-make-frame-functions' now run with wrong frame selected References: <6bb534ef-d80b-4c35-9538-2ee383d95610@default> In-Reply-To: <6bb534ef-d80b-4c35-9538-2ee383d95610@default> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:2C2ctIneMDbIDEp1Hz3zKmSnVVVwFx+INu3Bly1RutdbEU/piD8 t7BOGMgtfMszdkd4uJav2T0EVjtDqnqHxTaVlXo6YMACq0EvqU06qF0QWh4IIda3BRV8DcI XG6UR5DcStcyikfkqxFpT6TrzTZ22RXghJyOChKtPTbhZgj2Q3GzsbZzQWKoHKbj0UD2OzY uL7QX7HgKGnSLTCGjL8Fg== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 15133 Cc: 15133@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > This regression was introduced after a build from 2013-08-08. It > appears in the build cited below, from 2013-08-18. It makes Emacs > unusable (by me). > > I have this as `after-make-frame-functions': `(fit-frame)', in order to > fit the new frame to its displayed buffer.' > > When `after-make-frame-functions' is run in `make-frame' now, the > original frame, not the newly created frame, is selected when it runs. > So `fit-frame' is called with the original (wrong) frame selected. If it can be fixed by commenting in the second line of the following comment in `pop-to-buffer' ;; This should be done by `select-window' below. ;; (set-buffer buffer) we have the following problem: Your `fit-frame' will work when using `pop-to-buffer' but not when using `display-buffer'. So maybe it's better to do the funcall in `display-buffer-pop-up-frame' as (with-current-buffer buffer (setq frame (funcall fun))) Please try them both, tell me whether they work for you, and, if so, which one you prefer. Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 19 14:25:45 2013 Received: (at 15133) by debbugs.gnu.org; 19 Aug 2013 18:25:45 +0000 Received: from localhost ([127.0.0.1]:40832 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBU99-0004gY-OV for submit@debbugs.gnu.org; Mon, 19 Aug 2013 14:25:44 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:17754) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBU95-0004gJ-0a for 15133@debbugs.gnu.org; Mon, 19 Aug 2013 14:25:41 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7JIPbsd027838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Aug 2013 18:25:37 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JIPZ3s009002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 18:25:36 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JIPYBT000250; Mon, 19 Aug 2013 18:25:34 GMT MIME-Version: 1.0 Message-ID: <391c84ad-a338-41df-96ed-287508f86d66@default> Date: Mon, 19 Aug 2013 11:25:37 -0700 (PDT) From: Drew Adams To: martin rudalics Subject: RE: bug#15133: 24.3.50; REGRESSION: `after-make-frame-functions' now run with wrong frame selected References: <6bb534ef-d80b-4c35-9538-2ee383d95610@default> <52124432.9010707@gmx.at> In-Reply-To: <52124432.9010707@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -5.1 (-----) X-Debbugs-Envelope-To: 15133 Cc: 15133@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.1 (-----) > > This regression was introduced after a build from 2013-08-08. It > > appears in the build cited below, from 2013-08-18. It makes Emacs > > unusable (by me). > > > > I have this as `after-make-frame-functions': `(fit-frame)', in order t= o > > fit the new frame to its displayed buffer.' > > > > When `after-make-frame-functions' is run in `make-frame' now, the > > original frame, not the newly created frame, is selected when it runs. > > So `fit-frame' is called with the original (wrong) frame selected. >=20 > If it can be fixed by commenting in the second line of the following > comment in `pop-to-buffer' >=20 > ;; This should be done by `select-window' below. > ;; (set-buffer buffer) >=20 > we have the following problem: Your `fit-frame' will work when using > `pop-to-buffer' but not when using `display-buffer'. So maybe it's > better to do the funcall in `display-buffer-pop-up-frame' as >=20 > =09 (with-current-buffer buffer > =09=09 (setq frame (funcall fun))) >=20 > Please try them both, tell me whether they work for you, and, if so, > which one you prefer. Sorry, I don't understand. What "both" would you like me to try? This needs to work as it did before the regression - both `pop-to-buffer' and `display-buffer'. But first, I don't understand either why there should be any difference. Why shouldn't functions on `after-make-frame-functions' always be passed the new frame as argument, as has been the case in the past? There is a `before-make-frame-functions' hook for passing the originally selected frame. Perhaps you are thinking that this is about _selecting_ the new frame? (I mistakenly mentioned "is selected" above, when I meant is passed to the hook functions.) I can understand that `pop-to-buffer' and `display-buffer' might act differently wrt selecting the buffer's frame. But I do not understand why suddenly the functions on hook `after-make-frame-functions' should be passed the original frame as arg instead of the new frame. How else can someone invoke a function on the new frame as part of the process of frame creation? From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 19 16:07:30 2013 Received: (at 15133) by debbugs.gnu.org; 19 Aug 2013 20:07:30 +0000 Received: from localhost ([127.0.0.1]:40997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBVjc-0000AP-V7 for submit@debbugs.gnu.org; Mon, 19 Aug 2013 16:07:29 -0400 Received: from mout.gmx.net ([212.227.15.19]:60678) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBVja-0000AE-Mc for 15133@debbugs.gnu.org; Mon, 19 Aug 2013 16:07:27 -0400 Received: from [62.47.60.71] ([62.47.60.71]) by mail.gmx.com (mrgmx002) with ESMTPA (Nemesis) id 0LmKOI-1VkIFr1J9G-00Zwm2 for <15133@debbugs.gnu.org>; Mon, 19 Aug 2013 22:07:25 +0200 Message-ID: <52127AEE.8010101@gmx.at> Date: Mon, 19 Aug 2013 22:07:10 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#15133: 24.3.50; REGRESSION: `after-make-frame-functions' now run with wrong frame selected References: <6bb534ef-d80b-4c35-9538-2ee383d95610@default> <52124432.9010707@gmx.at> <391c84ad-a338-41df-96ed-287508f86d66@default> In-Reply-To: <391c84ad-a338-41df-96ed-287508f86d66@default> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:KjXu7b0mkBp8NO2X2LzuxIDzhcHIqOdQhbOOyK/Nqw1wk+HL2K/ CZd5BtDW+3YHof9wq+PM2TTNcuI7/mGZXXTtSXi/J9MrRW9K4xl0xlGKoMRMQvXyP6VFQFC yR4D6eVIjm003JTz7se/P2EjcsNilnxF+2P9jWhtl8pYlGUte+iVlwDRY2elQBY0V45P5Lj 8KoqGZaJTwTrJ2oUa7tQw== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 15133 Cc: 15133@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > Sorry, I don't understand. What "both" would you like me to try? This > needs to work as it did before the regression - both `pop-to-buffer' > and `display-buffer'. Did `display-buffer' work correctly? > But first, I don't understand either why there should be any difference. > Why shouldn't functions on `after-make-frame-functions' always be passed > the new frame as argument, as has been the case in the past? There is a > `before-make-frame-functions' hook for passing the originally selected > frame. The problem is that the new frame doesn't yet show the buffer you want to display when `after-make-frame-functions' is called. > Perhaps you are thinking that this is about _selecting_ the new frame? > (I mistakenly mentioned "is selected" above, when I meant is passed to > the hook functions.) > > I can understand that `pop-to-buffer' and `display-buffer' might act > differently wrt selecting the buffer's frame. But I do not understand > why suddenly the functions on hook `after-make-frame-functions' should > be passed the original frame as arg instead of the new frame. Do they really get passed the original frame? > How else can someone invoke a function on the new frame as part of the > process of frame creation? Please check again. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 19 17:46:36 2013 Received: (at 15133) by debbugs.gnu.org; 19 Aug 2013 21:46:36 +0000 Received: from localhost ([127.0.0.1]:41152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBXHX-0002wi-Bj for submit@debbugs.gnu.org; Mon, 19 Aug 2013 17:46:35 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:39012) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBXHV-0002wa-51 for 15133@debbugs.gnu.org; Mon, 19 Aug 2013 17:46:33 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7JLkU8w004582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Aug 2013 21:46:31 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JLkTrQ011044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 21:46:30 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JLkTOC015847; Mon, 19 Aug 2013 21:46:29 GMT MIME-Version: 1.0 Message-ID: Date: Mon, 19 Aug 2013 14:46:31 -0700 (PDT) From: Drew Adams To: martin rudalics Subject: RE: bug#15133: 24.3.50; REGRESSION: `after-make-frame-functions' now run with wrong frame selected References: <6bb534ef-d80b-4c35-9538-2ee383d95610@default> <52124432.9010707@gmx.at> <391c84ad-a338-41df-96ed-287508f86d66@default> <52127AEE.8010101@gmx.at> In-Reply-To: <52127AEE.8010101@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -5.1 (-----) X-Debbugs-Envelope-To: 15133 Cc: 15133@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.1 (-----) > > Sorry, I don't understand. What "both" would you like me to try? Thi= s > > needs to work as it did before the regression - both `pop-to-buffer' > > and `display-buffer'. >=20 > Did `display-buffer' work correctly? Not sure what you mean. I haven't seen a problem until this build. Hence the report of this being a regression. > > But first, I don't understand either why there should be any differenc= e. > > Why shouldn't functions on `after-make-frame-functions' always be pass= ed > > the new frame as argument, as has been the case in the past? There is= a > > `before-make-frame-functions' hook for passing the originally selected > > frame. >=20 > The problem is that the new frame doesn't yet show the buffer you want > to display when `after-make-frame-functions' is called. I see. So you are saying that the new frame object is passed to the hook functions, but that new frame has not yet been displayed. If so, that is presumably the cause of the regression. What's the point of passing the newly created frame object to hook function= s intended to act on it, if that frame has not yet been displayed so they can do so? Perhaps you are allowing for hook functions that do not assume the frame is displayed. Is that the point of this change? Should I change the hook function here to, say, (lambda (fr) (raise-frame fr) (fit-frame fr))? Or perhaps `make-frame-visible' instead of `raise-frame'? I just tried those, and they does not work either. If I want to apply a function such as `fit-frame' to the new frame, and it is not yet displayed, what do I need to call in the hook function to display it first? The doc string of `make-frame' suggests, BTW, that it should both (a) make a frame object and (b) display it, as I have always thought it did do and should do. It says: "Return a newly created frame displaying the current buffer." You will perhaps say that the PARAMETERS argument could include `invisible' or `iconified' or some such that has the effect of creating a frame that is not visible (displayed). If that is the idea behind this change then I might not have anything against it, provided the frame is in fact displayed when PARAMETERS does not do something to make it invisible etc. IOW, in the use cases I have, an ordinary frame is created displayed, and after that happens I want to fit the frame. `after-make-frame-functions' has always been the right place to do that, in the past. Seems like this is being redefined now.=20 Please advise. This should be simple. And it's still not clear to me why it should not be as it was before (i.e., since forever). From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 20 03:05:54 2013 Received: (at 15133) by debbugs.gnu.org; 20 Aug 2013 07:05:54 +0000 Received: from localhost ([127.0.0.1]:41870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBg0m-0002qk-OQ for submit@debbugs.gnu.org; Tue, 20 Aug 2013 03:05:53 -0400 Received: from mout.gmx.net ([212.227.17.22]:59668) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBg0i-0002qa-Tr for 15133@debbugs.gnu.org; Tue, 20 Aug 2013 03:05:50 -0400 Received: from [62.47.56.73] ([62.47.56.73]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0LhjeH-1Vp9Za2ZPd-00msyf for <15133@debbugs.gnu.org>; Tue, 20 Aug 2013 09:05:47 +0200 Message-ID: <52131543.8030909@gmx.at> Date: Tue, 20 Aug 2013 09:05:39 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#15133: 24.3.50; REGRESSION: `after-make-frame-functions' now run with wrong frame selected References: <6bb534ef-d80b-4c35-9538-2ee383d95610@default> <52124432.9010707@gmx.at> <391c84ad-a338-41df-96ed-287508f86d66@default> <52127AEE.8010101@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:fq6wtHrfTJv3CgEdHuS9RdCHvginxvhBsYHIosnLENnN0Ij0Zmm NNlYpyOKwGFf6dc5XPzEA61kfHNDLX3/HQvXOb8osy/XP7TD4hLQftp2XtIj/zI3Zca5LJQ UTaRMFXd0EBl7rTcEm+5dKMNQRwtK80FWfVQtD0OFrxup74wnjERk8qBMD2rzsG0kQRnJSb Yuytu8pxnejI5N5VQorLg== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 15133 Cc: 15133@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> Did `display-buffer' work correctly? > > Not sure what you mean. I haven't seen a problem until this build. > Hence the report of this being a regression. So you didn't check? >> The problem is that the new frame doesn't yet show the buffer you want >> to display when `after-make-frame-functions' is called. > > I see. So you are saying that the new frame object is passed to the hook > functions, but that new frame has not yet been displayed. If so, that is > presumably the cause of the regression. No. I am saying that at the time `after-make-frame-functions' is called, the new frame does not yet show the buffer you want to display in it via plain `display-buffer'. > What's the point of passing the newly created frame object to hook functions > intended to act on it, if that frame has not yet been displayed so they can > do so? > > Perhaps you are allowing for hook functions that do not assume the frame is > displayed. Is that the point of this change? Should I change the hook > function here to, say, (lambda (fr) (raise-frame fr) (fit-frame fr))? Or > perhaps `make-frame-visible' instead of `raise-frame'? > > I just tried those, and they does not work either. If I want to apply a > function such as `fit-frame' to the new frame, and it is not yet displayed, > what do I need to call in the hook function to display it first? You want to apply `fit-frame' to the buffer you eventually want to display on the new frame. Right? > The doc string of `make-frame' suggests, BTW, that it should both (a) make > a frame object and (b) display it, as I have always thought it did do and > should do. It says: "Return a newly created frame displaying the current > buffer." The _current_ buffer. > You will perhaps say that the PARAMETERS argument could include `invisible' > or `iconified' or some such that has the effect of creating a frame that > is not visible (displayed). If that is the idea behind this change then > I might not have anything against it, provided the frame is in fact > displayed when PARAMETERS does not do something to make it invisible etc. > > IOW, in the use cases I have, an ordinary frame is created displayed, and > after that happens I want to fit the frame. `after-make-frame-functions' > has always been the right place to do that, in the past. Seems like this > is being redefined now. > > Please advise. This should be simple. And it's still not clear to me > why it should not be as it was before (i.e., since forever). Because the "since forever" behavior is inconsistent. Consider the following forms: (defun mess (frame) (message "selected: %s ... frame: %s ... buffer: %s" (selected-frame) frame (window-buffer (frame-root-window frame)))) (let ((pop-up-frames t)) (add-hook 'after-make-frame-functions 'mess) (display-buffer "*Messages*") (remove-hook 'after-make-frame-functions 'mess)) (let ((pop-up-frames t)) (add-hook 'after-make-frame-functions 'mess) (pop-to-buffer "*Messages*") (remove-hook 'after-make-frame-functions 'mess)) With emacs -Q evaluate the first and and then try the other two with some older version and the current trunk. You should notice that the FRAME argument of `mess' is always different from the selected frame. But the buffer FRAME displays is different. With the older versions the buffer is *scratch* for plain `display-buffer' and *Messages* for `pop-to-buffer'. With current trunk it is *scratch* for both. So I suppose that since forever your `fit-frame' function works on the "wrong" buffer when you call plain `display-buffer' and the buffer you want to display is not current at that time. What I propose is to use the following as substitute for the old `display-buffer-pop-up-frame': (defun display-buffer-pop-up-frame (buffer alist) "Display BUFFER in a new frame. This works by calling `pop-up-frame-function'. If successful, return the window used; otherwise return nil. If ALIST has a non-nil `inhibit-switch-frame' entry, avoid raising the new frame. If ALIST has a non-nil `pop-up-frame-parameters' entry, the corresponding value is an alist of frame parameters to give the new frame." (let* ((params (cdr (assq 'pop-up-frame-parameters alist))) (pop-up-frame-alist (append params pop-up-frame-alist)) (fun pop-up-frame-function) frame window) (when (and fun (with-current-buffer buffer (setq frame (funcall fun))) (setq window (frame-selected-window frame))) (prog1 (window--display-buffer buffer window 'frame alist display-buffer-mark-dedicated) (unless (cdr (assq 'inhibit-switch-frame alist)) (window--maybe-raise-frame frame)))))) With this the buffer printed by `mess' should be *Messages* for both, the plain `display-buffer' case and `pop-to-buffer'. martin From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 20 11:16:19 2013 Received: (at 15133) by debbugs.gnu.org; 20 Aug 2013 15:16:19 +0000 Received: from localhost ([127.0.0.1]:42753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBnfO-0000ou-8e for submit@debbugs.gnu.org; Tue, 20 Aug 2013 11:16:18 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:32709) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBnfM-0000oj-CQ for 15133@debbugs.gnu.org; Tue, 20 Aug 2013 11:16:17 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7KFGExw013149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Aug 2013 15:16:15 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7KFGDtB025371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 15:16:14 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7KFGDZt027873; Tue, 20 Aug 2013 15:16:13 GMT MIME-Version: 1.0 Message-ID: <6c66dc09-9091-4fcc-9183-1b77886b58ba@default> Date: Tue, 20 Aug 2013 08:16:12 -0700 (PDT) From: Drew Adams To: martin rudalics Subject: RE: bug#15133: 24.3.50; REGRESSION: `after-make-frame-functions' now run with wrong frame selected References: <6bb534ef-d80b-4c35-9538-2ee383d95610@default> <52124432.9010707@gmx.at> <391c84ad-a338-41df-96ed-287508f86d66@default> <52127AEE.8010101@gmx.at> <52131543.8030909@gmx.at> In-Reply-To: <52131543.8030909@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -5.1 (-----) X-Debbugs-Envelope-To: 15133 Cc: 15133@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.1 (-----) Replied in order, as I read. If you want to cut to the chase, see the end. > >> Did `display-buffer' work correctly? > > > > Not sure what you mean. I haven't seen a problem until this build. > > Hence the report of this being a regression. >=20 > So you didn't check? Can you please tell me what to check, and how? It's not clear to me what you are asking/suggesting; sorry. > >> The problem is that the new frame doesn't yet show the buffer you wan= t > >> to display when `after-make-frame-functions' is called. > > > > I see. So you are saying that the new frame object is passed to the h= ook > > functions, but that new frame has not yet been displayed. If so, that= is > > presumably the cause of the regression. >=20 > No. I am saying that at the time `after-make-frame-functions' is > called, the new frame does not yet show the buffer you want to display > in it via plain `display-buffer'. >=20 > > What's the point of passing the newly created frame object to hook > > functions intended to act on it, if that frame has not yet been displa= yed > > so they can do so? > > > > Perhaps you are allowing for hook functions that do not assume the fra= me > > is displayed. Is that the point of this change? Should I change the = hook > > function here to, say, (lambda (fr) (raise-frame fr) (fit-frame fr))? = Or > > perhaps `make-frame-visible' instead of `raise-frame'? > > > > I just tried those, and they does not work either. If I want to apply= a > > function such as `fit-frame' to the new frame, and it is not yet > > displayed, what do I need to call in the hook function to display it f= irst? >=20 > You want to apply `fit-frame' to the buffer you eventually want to > display on the new frame. Right? I want to apply it to the frame (not to a buffer) _after_ it has been displayed. Previously, creating the frame (`make-frame') also displayed it= , and it did so before hook `after-create-frame-functions' was invoked. > > The doc string of `make-frame' suggests, BTW, that it should both (a) > > make a frame object and (b) display it, as I have always thought it di= d > > do and should do. It says: "Return a newly created frame displaying t= he > > current buffer." >=20 > The _current_ buffer. The question is which buffer should be current for that frame at that point= . I'm not sure the doc string should really have said "current buffer", as in `current-buffer'. Seems like what was intended - what makes sense in terms of the hook, and what I have always thought has been the behavior until now= - is the buffer the frame was created to display (which is harder to say than "current buffer"). IOW, the buffer that ends up displayed in the frame. The key part of that doc string, for me, is that it returns a new frame tha= t is already displayed. No one ever _sees_ a newly created frame first displ= ay the `current-buffer' and then switch to the actual buffer to be displayed i= n the frame. What you see is only the frame displayed (immediately) with the proper buff= er. And that displayed frame, with the buffer it displays, is what has always been passed to the `after-make-frame-functions'. And previously that frame was always displayed before `after-make-frame-*' was invoked. So in a hook function you could do this, for example: (save-window-excursion (select-frame frame) (setq specbuf-p (and empty-buf-p (special-display-p (buffer-name (window-buffer)))))) And the `window-buffer' was the buffer that the frame displayed, which was already the buffer that the frame was created to display. > Because the "since forever" behavior is inconsistent. Consider the > following forms: >=20 > (defun mess (frame) > (message "selected: %s ... frame: %s ... buffer: %s" > =09 (selected-frame) frame > =09 (window-buffer (frame-root-window frame)))) >=20 > (let ((pop-up-frames t)) > (add-hook 'after-make-frame-functions 'mess) > (display-buffer "*Messages*") > (remove-hook 'after-make-frame-functions 'mess)) >=20 > (let ((pop-up-frames t)) > (add-hook 'after-make-frame-functions 'mess) > (pop-to-buffer "*Messages*") > (remove-hook 'after-make-frame-functions 'mess)) >=20 > With emacs -Q evaluate the first and and then try the other two with > some older version and the current trunk. You should notice that the > FRAME argument of `mess' is always different from the selected frame. > But the buffer FRAME displays is different. With the older versions the > buffer is *scratch* for plain `display-buffer' and *Messages* for > `pop-to-buffer'. With current trunk it is *scratch* for both. >=20 > So I suppose that since forever your `fit-frame' function works on the > "wrong" buffer when you call plain `display-buffer' and the buffer you > want to display is not current at that time. I see. Yes, I see the behavior you describe, from emacs -Q. However, I have never noticed a problem in this regard with my code - dunno why. For a moment I wondered if this is perhaps because on MS Windows a new frame gets a certain kind of focus (not sure how to characterize that behavior). But I also use my code on GNU/Linux with Emacs 21.3, and there too I have never see `fit-frame' fit a new frame to the wrong buffer (the previously current one) etc. Mystery. It is true that I also make other calls to `fit-frame', including on `temp-buffer-show-hook' for one-window frames. Perhaps one of those other calls has been compensating for the discrepency in Emacs -Q that you point out. Dunno. Anyway, here is my question, given this discrepancy. You want to make the buffer be consistent. OK, But you have so far chosen the `current-buffer' as the buffer to use, perhaps from a reading of the doc string. Why not instead choose the buffer that will be displayed in the frame, consistently? IOW, for your test above, always have the buffer be *Messages*, since that is the buffer displayed in the frame that is passed to `after-make-frame-functions'? What is the use case for passing the frame, which will display (or is already displaying?) the *Messages* buffer, have as its root-window buffer some other buffer (*scratch*) that is not even displayed in that frame and perhaps never will be? > What I propose is to use the following as substitute for the old > `display-buffer-pop-up-frame': > (defun display-buffer-pop-up-frame (buffer alist)... >=20 > With this the buffer printed by `mess' should be *Messages* for both, > the plain `display-buffer' case and `pop-to-buffer'. Sounds like you are suggesting the same thing I suggested immediately above, and you are providing code that implements that. And yes, a quick trial indicates that that does seem to work, so far. I will load that code at startup and let you know if I notice any problems. Thx. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 20 13:24:49 2013 Received: (at 15133) by debbugs.gnu.org; 20 Aug 2013 17:24:50 +0000 Received: from localhost ([127.0.0.1]:42988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBpfk-0006y9-SV for submit@debbugs.gnu.org; Tue, 20 Aug 2013 13:24:49 -0400 Received: from mout.gmx.net ([212.227.17.21]:64208) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBpfi-0006xw-14 for 15133@debbugs.gnu.org; Tue, 20 Aug 2013 13:24:47 -0400 Received: from [62.47.43.55] ([62.47.43.55]) by mail.gmx.com (mrgmx001) with ESMTPA (Nemesis) id 0LwJRe-1W9h9p0OAo-0180EB for <15133@debbugs.gnu.org>; Tue, 20 Aug 2013 19:24:43 +0200 Message-ID: <5213A651.9020502@gmx.at> Date: Tue, 20 Aug 2013 19:24:33 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#15133: 24.3.50; REGRESSION: `after-make-frame-functions' now run with wrong frame selected References: <6bb534ef-d80b-4c35-9538-2ee383d95610@default> <52124432.9010707@gmx.at> <391c84ad-a338-41df-96ed-287508f86d66@default> <52127AEE.8010101@gmx.at> <52131543.8030909@gmx.at> <6c66dc09-9091-4fcc-9183-1b77886b58ba@default> In-Reply-To: <6c66dc09-9091-4fcc-9183-1b77886b58ba@default> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:2TL5EjHgank9DWrnuIkc3i51slO196OHn581KEdkLLrZvBpw5rw eale09CNgUIySNsYUeBL6FJ+bYhjKrA4VbkJ7TjA0Qw21QPYVERh02oq6KLZJYotJg2Luxq AHBgvXSR9CzaYf9MQVTkG2mvJtJT/hL5bYpTYiUVVJGzVrs6M5ZLF/UtLBNilfIPZrDeKZ9 BG7ev1ufbak8pLCvblBbA== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 15133 Cc: 15133@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > Can you please tell me what to check, and how? It's not clear to me what > you are asking/suggesting; sorry. Whether with older versions your `fit-frame' function works with plain `display-buffer', that is, bypassing `pop-to-buffer'. Obviously, `special-display-popup-frame' is disallowed as well because it does (with-current-buffer buffer (make-frame (append args special-display-frame-alist)))) and `temp-buffer-window-show' is disallowed because it does (with-current-buffer buffer ... (setq window (display-buffer buffer action))) >> You want to apply `fit-frame' to the buffer you eventually want to >> display on the new frame. Right? > > I want to apply it to the frame (not to a buffer) _after_ it has been > displayed. Previously, creating the frame (`make-frame') also displayed it, > and it did so before hook `after-create-frame-functions' was invoked. It displayed it if and only if it was current at the time `make-frame' was called. Also, at the time `after-make-frame-functions' is called the buffer is not yet "displayed". `make-frame' simply sets a slot in the frame structure to reference that buffer. >> The _current_ buffer. > > The question is which buffer should be current for that frame at that point. It's up to the caller to determine that, `make-frame' wouldn't know. > I'm not sure the doc string should really have said "current buffer", as in > `current-buffer'. Seems like what was intended - what makes sense in terms > of the hook, and what I have always thought has been the behavior until now - > is the buffer the frame was created to display (which is harder to say than > "current buffer"). IOW, the buffer that ends up displayed in the frame. This is not what `make-frame' does. > The key part of that doc string, for me, is that it returns a new frame that > is already displayed. No. Otherwise with `display-buffer' you would first see one buffer and then another - or at least some kind of flicker. > No one ever _sees_ a newly created frame first display > the `current-buffer' and then switch to the actual buffer to be displayed in > the frame. Then put a `sit-for' in `display-buffer-pop-up-frame' before it calls `window--display-buffer'. > What you see is only the frame displayed (immediately) with the proper buffer. > And that displayed frame, with the buffer it displays, is what has always > been passed to the `after-make-frame-functions'. Not necessarily - only when the buffer current at that time was also the buffer finally displayed in that frame. > And previously that frame was always displayed before `after-make-frame-*' > was invoked. So in a hook function you could do this, for example: > > (save-window-excursion > (select-frame frame) > (setq specbuf-p > (and empty-buf-p > (special-display-p (buffer-name (window-buffer)))))) > > And the `window-buffer' was the buffer that the frame displayed, which was > already the buffer that the frame was created to display. I miss you here. For `display-buffer' the hook is called after the frame has been "created" but before it is ascertained that it displays the "right" buffer. > Anyway, here is my question, given this discrepancy. You want to make > the buffer be consistent. I want `display-buffer' DTRT. This means that it should call `make-frame' with the buffer to be displayed current. > OK, But you have so far chosen the > `current-buffer' as the buffer to use, perhaps from a reading of the > doc string. Why not instead choose the buffer that will be displayed > in the frame, consistently? But that's what I do: I make the buffer "that will be displayed in the frame" current so `make-frame' assigns it immediately to the new frame's root window. And I have to do this in the buffer display code because I cannot pass a buffer to `make-frame' just as I cannot pass a buffer to `split-window'. > IOW, for your test above, always have the buffer be *Messages*, since > that is the buffer displayed in the frame that is passed to > `after-make-frame-functions'? It's not passed. It's the current buffer at the time `after-make-frame-functions' is called. > What is the use case for passing the > frame, which will display (or is already displaying?) the *Messages* > buffer, have as its root-window buffer some other buffer (*scratch*) that > is not even displayed in that frame and perhaps never will be? `make-frame' has been designed that way - display the current buffer in the new frame. Just as `split-window' displays the buffer shown in the window to be split in the new window too. > Sounds like you are suggesting the same thing I suggested immediately > above, and you are providing code that implements that. And yes, a > quick trial indicates that that does seem to work, so far. I will > load that code at startup and let you know if I notice any problems. Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 20 14:03:37 2013 Received: (at 15133) by debbugs.gnu.org; 20 Aug 2013 18:03:37 +0000 Received: from localhost ([127.0.0.1]:43046 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBqHI-0008JI-Sl for submit@debbugs.gnu.org; Tue, 20 Aug 2013 14:03:37 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:27875) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBqHG-0008JA-Pk for 15133@debbugs.gnu.org; Tue, 20 Aug 2013 14:03:35 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7KI3M9H008787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Aug 2013 18:03:23 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7KI3L6F009103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 18:03:21 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7KI3LqP009094; Tue, 20 Aug 2013 18:03:21 GMT MIME-Version: 1.0 Message-ID: <3c3614a1-832b-4ebd-8a2f-13060dba45b4@default> Date: Tue, 20 Aug 2013 11:03:20 -0700 (PDT) From: Drew Adams To: martin rudalics Subject: RE: bug#15133: 24.3.50; REGRESSION: `after-make-frame-functions' now run with wrong frame selected References: <6bb534ef-d80b-4c35-9538-2ee383d95610@default> <52124432.9010707@gmx.at> <391c84ad-a338-41df-96ed-287508f86d66@default> <52127AEE.8010101@gmx.at> <52131543.8030909@gmx.at> <6c66dc09-9091-4fcc-9183-1b77886b58ba@default> <5213A651.9020502@gmx.at> In-Reply-To: <5213A651.9020502@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -5.1 (-----) X-Debbugs-Envelope-To: 15133 Cc: 15133@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.1 (-----) > > Can you please tell me what to check, and how? It's not clear to me w= hat > > you are asking/suggesting; sorry. >=20 > Whether with older versions your `fit-frame' function works with plain > `display-buffer', that is, bypassing `pop-to-buffer'. Yes, it does. But I cannot tell you now what part of my code takes care of that. If I try emacs -Q, load fit-frame.el, (setq pop-up-frames t), and (add-hook 'after-make-frame-functions 'fit-frame) then no, it does not work, as you expected. But in my full setup, it does work (i.e., (display-buffer "foo") shows buffer foo in a new frame, which is fit to the buffer contents). Dunno why it works, but it does. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 23 03:09:08 2013 Received: (at 15133) by debbugs.gnu.org; 23 Aug 2013 07:09:08 +0000 Received: from localhost ([127.0.0.1]:49315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VClUZ-0000NW-P5 for submit@debbugs.gnu.org; Fri, 23 Aug 2013 03:09:08 -0400 Received: from mout.gmx.net ([212.227.15.19]:50317) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VClUV-0000NM-L5 for 15133@debbugs.gnu.org; Fri, 23 Aug 2013 03:09:05 -0400 Received: from [62.47.51.135] ([62.47.51.135]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0M7CRe-1VxjmC1UE2-00x6TH for <15133@debbugs.gnu.org>; Fri, 23 Aug 2013 09:09:02 +0200 Message-ID: <52170A8B.402@gmx.at> Date: Fri, 23 Aug 2013 09:08:59 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#15133: 24.3.50; REGRESSION: `after-make-frame-functions' now run with wrong frame selected References: <6bb534ef-d80b-4c35-9538-2ee383d95610@default> <52124432.9010707@gmx.at> <391c84ad-a338-41df-96ed-287508f86d66@default> <52127AEE.8010101@gmx.at> <52131543.8030909@gmx.at> In-Reply-To: <52131543.8030909@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:YIsIaKS2DOLelAfm2+m7MR14tjW1gVnOBX9sd6gNuKg2KDBTd6c lRgNdhyInhQNlVtE5I3rPBn8wpKsrcsBI+NHCH/0AWDx55MRHe6jYM8qvnQKxFvzFdTczcH Exr2heJQl5tc6yGSm0eheeJfgXWjrzg9ALYVpapkjfMXOJyMVWf5IqrNTLyTewslF+HDd8P XFhYKmsSK1JeA7gfmeJsA== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 15133 Cc: 15133@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > What I propose is to use the following as substitute for the old > `display-buffer-pop-up-frame': Installed as revision #113977. Please check and close the bug if it works. Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 23 03:45:21 2013 Received: (at 15133) by debbugs.gnu.org; 23 Aug 2013 07:45:21 +0000 Received: from localhost ([127.0.0.1]:49364 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VCm3d-0002Hj-44 for submit@debbugs.gnu.org; Fri, 23 Aug 2013 03:45:21 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:25080) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VCm3Z-0002HW-9P for 15133@debbugs.gnu.org; Fri, 23 Aug 2013 03:45:18 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7N7jFqe001853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Aug 2013 07:45:16 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7N7jEs6026909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Aug 2013 07:45:15 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7N7jELD013635; Fri, 23 Aug 2013 07:45:14 GMT MIME-Version: 1.0 Message-ID: <08734db6-5a56-4829-a9bb-2e830c56406a@default> Date: Fri, 23 Aug 2013 00:45:13 -0700 (PDT) From: Drew Adams To: martin rudalics Subject: RE: bug#15133: 24.3.50; REGRESSION: `after-make-frame-functions' now run with wrong frame selected References: <6bb534ef-d80b-4c35-9538-2ee383d95610@default> <52124432.9010707@gmx.at> <391c84ad-a338-41df-96ed-287508f86d66@default> <52127AEE.8010101@gmx.at> <52131543.8030909@gmx.at> <52170A8B.402@gmx.at> In-Reply-To: <52170A8B.402@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -5.1 (-----) X-Debbugs-Envelope-To: 15133 Cc: 15133@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.1 (-----) > > What I propose is to use the following as substitute for the old > > `display-buffer-pop-up-frame': >=20 > Installed as revision #113977. Please check and close the bug if > it works. Will do when I get the next Emacs binary available. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 23 22:19:14 2013 Received: (at 15133) by debbugs.gnu.org; 24 Aug 2013 02:19:15 +0000 Received: from localhost ([127.0.0.1]:51327 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VD3Ra-0007xc-Hm for submit@debbugs.gnu.org; Fri, 23 Aug 2013 22:19:14 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:31151) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VD3RX-0007xT-TB for 15133@debbugs.gnu.org; Fri, 23 Aug 2013 22:19:12 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7O2J96L030441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Aug 2013 02:19:10 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7O2J8QD001643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Aug 2013 02:19:09 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7O2J869001640; Sat, 24 Aug 2013 02:19:08 GMT MIME-Version: 1.0 Message-ID: <9d5a8598-c358-46e0-a833-7462c6056204@default> Date: Fri, 23 Aug 2013 19:19:07 -0700 (PDT) From: Drew Adams To: martin rudalics Subject: RE: bug#15133: 24.3.50; REGRESSION: `after-make-frame-functions' now run with wrong frame selected References: <6bb534ef-d80b-4c35-9538-2ee383d95610@default> <52124432.9010707@gmx.at> <391c84ad-a338-41df-96ed-287508f86d66@default> <52127AEE.8010101@gmx.at> <52131543.8030909@gmx.at> <52170A8B.402@gmx.at> <08734db6-5a56-4829-a9bb-2e830c56406a@default> In-Reply-To: <08734db6-5a56-4829-a9bb-2e830c56406a@default> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -5.1 (-----) X-Debbugs-Envelope-To: 15133 Cc: 15133@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.1 (-----) > > > What I propose is to use the following as substitute for the old > > > `display-buffer-pop-up-frame': > > > > Installed as revision #113977. Please check and close the bug if > > it works. >=20 > Will do when I get the next Emacs binary available. > Thanks. Seems to fix the problem. Thanks; closing. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 23 22:21:38 2013 Received: (at control) by debbugs.gnu.org; 24 Aug 2013 02:21:38 +0000 Received: from localhost ([127.0.0.1]:51332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VD3Tu-00081J-4v for submit@debbugs.gnu.org; Fri, 23 Aug 2013 22:21:38 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:47414) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VD3Tr-000819-DX for control@debbugs.gnu.org; Fri, 23 Aug 2013 22:21:35 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7O2LXKC001198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 24 Aug 2013 02:21:34 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7O2LWs5003691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 24 Aug 2013 02:21:33 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7O2LWjG001731 for ; Sat, 24 Aug 2013 02:21:32 GMT MIME-Version: 1.0 Message-ID: Date: Fri, 23 Aug 2013 19:21:32 -0700 (PDT) From: Drew Adams To: control@debbugs.gnu.org Subject: bug #15133: close X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -5.1 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.1 (-----) close 15133 thanks From unknown Sun Jun 22 07:59:18 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 21 Sep 2013 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator