From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 15:49:28 2012 Received: (at submit) by debbugs.gnu.org; 16 Nov 2012 20:49:28 +0000 Received: from localhost ([127.0.0.1]:49281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZSqt-0004NL-3p for submit@debbugs.gnu.org; Fri, 16 Nov 2012 15:49:28 -0500 Received: from eggs.gnu.org ([208.118.235.92]:38841) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZSqr-0004NE-DK for submit@debbugs.gnu.org; Fri, 16 Nov 2012 15:49:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TZSq2-0004WW-2p for submit@debbugs.gnu.org; Fri, 16 Nov 2012 15:48:37 -0500 Received: from lists.gnu.org ([208.118.235.17]:36194) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZSq1-0004WS-Vf for submit@debbugs.gnu.org; Fri, 16 Nov 2012 15:48:33 -0500 Received: from eggs.gnu.org ([208.118.235.92]:59854) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZSpy-0003Nk-Sw for bug-gnu-emacs@gnu.org; Fri, 16 Nov 2012 15:48:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TZSpv-0004Vh-Qd for bug-gnu-emacs@gnu.org; Fri, 16 Nov 2012 15:48:30 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:49737) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZSpv-0004Vd-Jw for bug-gnu-emacs@gnu.org; Fri, 16 Nov 2012 15:48:27 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAGKmPVS024173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 16 Nov 2012 20:48:26 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAGKmPK4005046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 16 Nov 2012 20:48:25 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAGKmPba014587 for ; Fri, 16 Nov 2012 14:48:25 -0600 Received: from dradamslap1 (/10.159.229.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Nov 2012 12:48:25 -0800 From: "Drew Adams" To: Subject: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Date: Fri, 16 Nov 2012 12:48:20 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac3EO7aN5SlPcMx3Q4CXjOI7liHDdg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] 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: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) Please do not write such files willy nilly to the directory where the Emacs process was opened (or whatever). That is not user-friendly. Please let users decide where to write such files. Consider even giving them the option to prevent Emacs from writing such files altogether (short of giving up using Emacs completely). If such user control is not possible, then please confine such files to somewhere under .emacs.d or some other "hidden" directory that is typically far from the files that a user accesses using Emacs or other applications. Users do not want program-debugging information written to their folder of family vacation photos or their favorite lasagna recipes. Think _user_. Emacs is about users. In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) of 2012-11-05 on MS-W7-DANI Bzr revision: 110809 lekktu@gmail.com-20121105172930-a5gn0bwi4lndchhw Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.7) --no-opt --enable-checking --cflags -I../../libs/libXpm-3.5.10/include -I../../libs/libXpm-3.5.10/src -I../../libs/libpng-1.2.37-lib/include -I../../libs/zlib-1.2.5 -I../../libs/giflib-4.1.4-1-lib/include -I../../libs/jpeg-6b-4-lib/include -I../../libs/tiff-3.8.2-1-lib/include -I../../libs/libxml2-2.7.8-w32-bin/include/libxml2 -I../../libs/gnutls-3.0.9-w32-bin/include -I../../libs/libiconv-1.9.2-1-lib/include' From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 16:06:46 2012 Received: (at 12911) by debbugs.gnu.org; 16 Nov 2012 21:06:46 +0000 Received: from localhost ([127.0.0.1]:49332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZT7d-0004mR-Qg for submit@debbugs.gnu.org; Fri, 16 Nov 2012 16:06:46 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:23377) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZT7a-0004m7-IF for 12911@debbugs.gnu.org; Fri, 16 Nov 2012 16:06:43 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAGL5q5T006385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <12911@debbugs.gnu.org>; Fri, 16 Nov 2012 21:05:53 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAGL5qOu000920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <12911@debbugs.gnu.org>; Fri, 16 Nov 2012 21:05:52 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAGL5qlA025825 for <12911@debbugs.gnu.org>; Fri, 16 Nov 2012 15:05:52 -0600 Received: from dradamslap1 (/10.159.229.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Nov 2012 13:05:51 -0800 From: "Drew Adams" To: <12911@debbugs.gnu.org> References: Subject: RE: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written Date: Fri, 16 Nov 2012 13:05:47 -0800 Message-ID: <8D4E4720C2644369A04F3EB07D24CC40@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: Thread-Index: Ac3EO7aN5SlPcMx3Q4CXjOI7liHDdgAAkdmA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 12911 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) Please see bug #12908 for the start of the discussion (some arguments pro/con etc.). That might obviate some repetition here. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 16:20:25 2012 Received: (at 12911) by debbugs.gnu.org; 16 Nov 2012 21:20:25 +0000 Received: from localhost ([127.0.0.1]:49365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZTKq-00055d-OF for submit@debbugs.gnu.org; Fri, 16 Nov 2012 16:20:24 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:11518) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZTKp-00055W-CF for 12911@debbugs.gnu.org; Fri, 16 Nov 2012 16:20:23 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAG6Zu09sr+ZY/2dsb2JhbABEsEiDSYEIghUBAQQBViMFCws0BwsUGA0kiBwFugmQRAOIQpV3hHqBWIMH X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="207817606" Received: from 108-175-230-88.dsl.teksavvy.com (HELO pastel.home) ([108.175.230.88]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 16 Nov 2012 16:19:34 -0500 Received: by pastel.home (Postfix, from userid 20848) id DBBD859346; Fri, 16 Nov 2012 16:19:33 -0500 (EST) From: Stefan Monnier To: "Drew Adams" Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Message-ID: References: Date: Fri, 16 Nov 2012 16:19:33 -0500 In-Reply-To: (Drew Adams's message of "Fri, 16 Nov 2012 12:48:20 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) > If such user control is not possible, then please confine such files to > somewhere under .emacs.d or some other "hidden" directory that is Agreed: writing the file into ~/.emacs.d makes a lot more sense. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 02:28:02 2012 Received: (at 12911) by debbugs.gnu.org; 17 Nov 2012 07:28:02 +0000 Received: from localhost ([127.0.0.1]:50170 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZcor-0005W8-Bl for submit@debbugs.gnu.org; Sat, 17 Nov 2012 02:28:01 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:46836) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZcoo-0005Vt-7w for 12911@debbugs.gnu.org; Sat, 17 Nov 2012 02:27:59 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MDM00700F44RT00@a-mtaout21.012.net.il> for 12911@debbugs.gnu.org; Sat, 17 Nov 2012 09:27:06 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDM0070MFD0QV40@a-mtaout21.012.net.il>; Sat, 17 Nov 2012 09:27:01 +0200 (IST) Date: Sat, 17 Nov 2012 09:26:32 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83wqxk3d1z.fsf@gnu.org> References: X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Date: Fri, 16 Nov 2012 16:19:33 -0500 > Cc: 12911@debbugs.gnu.org > > > If such user control is not possible, then please confine such files to > > somewhere under .emacs.d or some other "hidden" directory that is > > Agreed: writing the file into ~/.emacs.d makes a lot more sense. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Date: Fri, 16 Nov 2012 16:19:33 -0500 > Cc: 12911@debbugs.gnu.org > > > If such user control is not possible, then please confine such files to > > somewhere under .emacs.d or some other "hidden" directory that is > > Agreed: writing the file into ~/.emacs.d makes a lot more sense. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4999] > From: Stefan Monnier > Date: Fri, 16 Nov 2012 16:19:33 -0500 > Cc: 12911@debbugs.gnu.org > > > If such user control is not possible, then please confine such files to > > somewhere under .emacs.d or some other "hidden" directory that is > > Agreed: writing the file into ~/.emacs.d makes a lot more sense. I agree, but we need to decide what to do if this directory is remote, because invoking file handlers in this situation is not possible. Also, on Unix, the information is under the home directory, and the Unix builds don't themselves create any files, but rather reuse system-wide settings (which AFAIU aren't settable by users). So I'm unsure what this means for platforms other than Windows. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 12:39:18 2012 Received: (at 12911) by debbugs.gnu.org; 17 Nov 2012 17:39:18 +0000 Received: from localhost ([127.0.0.1]:51149 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZmMO-0006tp-TS for submit@debbugs.gnu.org; Sat, 17 Nov 2012 12:39:17 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:46876) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZmMM-0006th-HU for 12911@debbugs.gnu.org; Sat, 17 Nov 2012 12:39:15 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAHHcJ3C000709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Nov 2012 17:38:20 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAHHcIwS014000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Nov 2012 17:38:18 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAHHcHgo029014; Sat, 17 Nov 2012 11:38:17 -0600 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Nov 2012 09:38:17 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" , "'Stefan Monnier'" References: <83wqxk3d1z.fsf@gnu.org> Subject: RE: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Date: Sat, 17 Nov 2012 09:38:10 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83wqxk3d1z.fsf@gnu.org> Thread-Index: Ac3ElPPpV2Pap5cpRSelG7ZgVSwZ4wAU28og X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) BTW, just a thought, in ignorance - ignore if not helpful. The backtrace file, wherever it might be saved: does it get overwritten when there is a new crash, or is a new version of it created (e.g. emacs_backtrace.txt~259~)? In either case, I assume that it would be good for a user to send a bug report with (at least) the latest such file. Would it be possible/useful for a new Emacs session to (a) look for such a file, (b) if found then automatically compose a bug-report message, and (c) ask the user whether to send it? And then (d) perhaps optionally delete the file? IOW, isn't there some easy way for Emacs Dev to get such info semi-automatically - upon user agreement/confirmation? Emacs should know where to look for the file, or at least be able to recognize it if seen by accident. And Emacs should be able to pick up the latest such file if there are multiple versions. Or perhaps it could combine all such files in a given directory into a single bug report, separating the backtraces and timestamping them with the file dates. Just a thought. Seems like we are expecting users to do things that they might not know, care, or bother about doing, when some of the more bothersome lifting for that could perhaps be done automatically by a subsequent Emacs session. Any such automatic activity must of course be able to be turned off/on by users, i.e., an option (opt-in or opt-out). I imagine that you guys have already thought about such things, and perhaps dismissed the idea, but I thought I'd mention it anyway, just in case. Again, ignore if not helpful. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 12:57:04 2012 Received: (at 12911) by debbugs.gnu.org; 17 Nov 2012 17:57:04 +0000 Received: from localhost ([127.0.0.1]:51167 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZmdc-0007I3-8U for submit@debbugs.gnu.org; Sat, 17 Nov 2012 12:57:04 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:58181) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZmdZ-0007Hb-1O for 12911@debbugs.gnu.org; Sat, 17 Nov 2012 12:57:02 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MDN002008GSP000@a-mtaout22.012.net.il> for 12911@debbugs.gnu.org; Sat, 17 Nov 2012 19:56:06 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDN002Q38HHGE60@a-mtaout22.012.net.il>; Sat, 17 Nov 2012 19:56:06 +0200 (IST) Date: Sat, 17 Nov 2012 19:55:38 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <8362542jxh.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: <12911@debbugs.gnu.org> > Date: Sat, 17 Nov 2012 09:38:10 -0800 > > The backtrace file, wherever it might be saved: does it get overwritten when > there is a new crash, or is a new version of it created (e.g. > emacs_backtrace.txt~259~)? [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: <12911@debbugs.gnu.org> > Date: Sat, 17 Nov 2012 09:38:10 -0800 > > The backtrace file, wherever it might be saved: does it get overwritten when > there is a new crash, or is a new version of it created (e.g. > emacs_backtrace.txt~259~)? [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4777] > From: "Drew Adams" > Cc: <12911@debbugs.gnu.org> > Date: Sat, 17 Nov 2012 09:38:10 -0800 > > The backtrace file, wherever it might be saved: does it get overwritten when > there is a new crash, or is a new version of it created (e.g. > emacs_backtrace.txt~259~)? On MS-Windows, neither: the new backtrace gets appended to the file. I don't know what happens on Unix. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 13:25:39 2012 Received: (at 12911) by debbugs.gnu.org; 17 Nov 2012 18:25:40 +0000 Received: from localhost ([127.0.0.1]:51214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZn5H-0007w3-Pl for submit@debbugs.gnu.org; Sat, 17 Nov 2012 13:25:39 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:45867) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZn5G-0007vw-7E for 12911@debbugs.gnu.org; Sat, 17 Nov 2012 13:25:38 -0500 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAHIOh4F002449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Nov 2012 18:24:43 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAHIOg9Z019132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Nov 2012 18:24:42 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAHIOfi0020255; Sat, 17 Nov 2012 12:24:41 -0600 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Nov 2012 10:24:41 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" References: <83wqxk3d1z.fsf@gnu.org> <8362542jxh.fsf@gnu.org> Subject: RE: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Date: Sat, 17 Nov 2012 10:24:34 -0800 Message-ID: <642CBD4430E145B1A2CC5C512E5A6445@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8362542jxh.fsf@gnu.org> Thread-Index: Ac3E7NK07fuJOZzLQBOps9o9K3xlMQAA7a2A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > > The backtrace file, wherever it might be saved: does it get > > overwritten when there is a new crash, or is a new version > > of it created (e.g. emacs_backtrace.txt~259~)? > > On MS-Windows, neither: the new backtrace gets appended to the file. > I don't know what happens on Unix. OK. Same question though - would it make sense for a subsequent Emacs session, if it finds the file, to prepare a bug-report message that includes the info in the file and propose that the user send it? And perhaps then delete the file? (All with user approval, of course.) From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 18:09:25 2012 Received: (at 12911) by debbugs.gnu.org; 17 Nov 2012 23:09:25 +0000 Received: from localhost ([127.0.0.1]:51498 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZrVs-0006r6-Rf for submit@debbugs.gnu.org; Sat, 17 Nov 2012 18:09:25 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:36281) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZrVr-0006qw-36; Sat, 17 Nov 2012 18:09:23 -0500 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAHN8QD7018088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Nov 2012 23:08:27 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAHN8P3a010912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Nov 2012 23:08:26 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAHN8Pb9021417; Sat, 17 Nov 2012 17:08:25 -0600 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Nov 2012 15:08:25 -0800 From: "Drew Adams" To: "'Paul Eggert'" , "'Eli Zaretskii'" References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com><50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org><50A7E5AB.3040006@cs.ucla.edu> <83zk2g10ew.fsf@gnu.org> <50A800BD.2@cs.ucla.edu> Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'? Date: Sat, 17 Nov 2012 15:08:17 -0800 Message-ID: <0D5E662929EB46BABC33674094EA6A24@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50A800BD.2@cs.ucla.edu> Thread-Index: Ac3FCi5B+BsyMFPLQSC5tWeGjwiO4wADdi8A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > > Unless we are going to ask each Emacs user to change the default so > > that the file ends up in .emacs.d, we still have a > > discrepancy vs what Stefan asked to do. > > I must have missed that request; all I see from him in Bug#12908 > is a comment about how to deal with the file names That's because Stefan wrote it in the proper bug thread, and not in this one (which Eli asked us to abandon (but which he too continues to populate)): > From: Stefan Monnier Sent: Friday, November 16, 2012 1:20 PM > To: Drew Adams Cc: 12911@debbugs.gnu.org > Subject: Re: bug#12911: 24.3.50; let users decide where (& > perhaps whether) `emacs_backtrace.txt' files are written > > > If such user control is not possible, then please confine > > such files to somewhere under .emacs.d or some other > > "hidden" directory that is > > Agreed: writing the file into ~/.emacs.d makes a lot more sense. > > Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 20:20:53 2012 Received: (at 12911) by debbugs.gnu.org; 18 Nov 2012 01:20:53 +0000 Received: from localhost ([127.0.0.1]:51676 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZtZ6-0002BH-D2 for submit@debbugs.gnu.org; Sat, 17 Nov 2012 20:20:53 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]:34716) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZtZ4-0002BA-9W for 12911@debbugs.gnu.org; Sat, 17 Nov 2012 20:20:51 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id D4F11A60017; Sat, 17 Nov 2012 17:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuIdcXKwJCUS; Sat, 17 Nov 2012 17:19:54 -0800 (PST) Received: from [192.168.1.3] (pool-71-189-154-249.lsanca.fios.verizon.net [71.189.154.249]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 5D5A9A60001; Sat, 17 Nov 2012 17:19:54 -0800 (PST) Message-ID: <50A837BD.10707@cs.ucla.edu> Date: Sat, 17 Nov 2012 17:19:57 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com><50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org><50A7E5AB.3040006@cs.ucla.edu> <83zk2g10ew.fsf@gnu.org> <50A800BD.2@cs.ucla.edu> <0D5E662929EB46BABC33674094EA6A24@us.oracle.com> In-Reply-To: <0D5E662929EB46BABC33674094EA6A24@us.oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 12911 Cc: Eli Zaretskii , 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.6 (-) On 11/17/2012 03:08 PM, Drew Adams wrote: >> I must have missed that request; all I see from him in Bug#12908 >> > is a comment about how to deal with the file names > That's because Stefan wrote it in the proper bug thread, and not in this one Stefan's comment was in response to the request "Please do not write such files willy nilly to the directory where the Emacs process was opened (or whatever). That is not user-friendly." Stefan agreed with the request, and suggested ~/.emacs.d. However, the request was about Emacs's behavior on Microsoft Windows. On GNU and other non-Microsoft platforms, Emacs already satisfies the request, because it relies on its invoker to specify where the debugging information will go, and in practice this approach works reasonably well on these platforms. Stefan's comment, in context, does not imply that Emacs should change its behavior on these platforms. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 22:57:20 2012 Received: (at 12911) by debbugs.gnu.org; 18 Nov 2012 03:57:20 +0000 Received: from localhost ([127.0.0.1]:51798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZw0V-0006jo-VI for submit@debbugs.gnu.org; Sat, 17 Nov 2012 22:57:20 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:44964) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZw0T-0006jg-GZ for 12911@debbugs.gnu.org; Sat, 17 Nov 2012 22:57:18 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDN00900ZYKCF00@a-mtaout20.012.net.il> for 12911@debbugs.gnu.org; Sun, 18 Nov 2012 05:56:20 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDO008F309VM1U0@a-mtaout20.012.net.il>; Sun, 18 Nov 2012 05:56:20 +0200 (IST) Date: Sun, 18 Nov 2012 05:55:53 +0200 From: Eli Zaretskii Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? In-reply-to: <50A837BD.10707@cs.ucla.edu> X-012-Sender: halo1@inter.net.il To: Paul Eggert Message-id: <83k3tj1s52.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <50A7E5AB.3040006@cs.ucla.edu> <83zk2g10ew.fsf@gnu.org> <50A800BD.2@cs.ucla.edu> <0D5E662929EB46BABC33674094EA6A24@us.oracle.com> <50A837BD.10707@cs.ucla.edu> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Sat, 17 Nov 2012 17:19:57 -0800 > From: Paul Eggert > CC: Eli Zaretskii , 12911@debbugs.gnu.org > > On 11/17/2012 03:08 PM, Drew Adams wrote: > >> I must have missed that request; all I see from him in Bug#12908 > >> > is a comment about how to deal with the file names > > That's because Stefan wrote it in the proper bug thread, and not in this one > > Stefan's comment was in response to the request > "Please do not write such files willy nilly to the directory where the > Emacs process was opened (or whatever). That is not user-friendly." > Stefan agreed with the request, and suggested ~/.emacs.d. However, > the request was about Emacs's behavior on Microsoft Windows. > > On GNU and other non-Microsoft platforms, Emacs already satisfies > the request, because it relies on its invoker to specify where > the debugging information will go, and in practice this approach > works reasonably well on these platforms. Stefan's comment, > in context, does not imply that Emacs should change its behavior > on these platforms. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4448] X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > Date: Sat, 17 Nov 2012 17:19:57 -0800 > From: Paul Eggert > CC: Eli Zaretskii , 12911@debbugs.gnu.org > > On 11/17/2012 03:08 PM, Drew Adams wrote: > >> I must have missed that request; all I see from him in Bug#12908 > >> > is a comment about how to deal with the file names > > That's because Stefan wrote it in the proper bug thread, and not in this one > > Stefan's comment was in response to the request > "Please do not write such files willy nilly to the directory where the > Emacs process was opened (or whatever). That is not user-friendly." > Stefan agreed with the request, and suggested ~/.emacs.d. However, > the request was about Emacs's behavior on Microsoft Windows. > > On GNU and other non-Microsoft platforms, Emacs already satisfies > the request, because it relies on its invoker to specify where > the debugging information will go, and in practice this approach > works reasonably well on these platforms. Stefan's comment, > in context, does not imply that Emacs should change its behavior > on these platforms. Then I guess we should close this bug as "wontfix", because I submit that Emacs on Windows does the same as on Unix, namely, puts this data on a file in a random (but documented) location on the disk. The only way the Windows code will be changed to write the file in .emacs.d is if the Unix code is changed to do the same. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 22:58:20 2012 Received: (at 12911) by debbugs.gnu.org; 18 Nov 2012 03:58:20 +0000 Received: from localhost ([127.0.0.1]:51804 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZw1T-0006lQ-KT for submit@debbugs.gnu.org; Sat, 17 Nov 2012 22:58:20 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:45106) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZw1Q-0006lD-Kl; Sat, 17 Nov 2012 22:58:17 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDN00900ZYKCF00@a-mtaout20.012.net.il>; Sun, 18 Nov 2012 05:57:20 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDO0080J0BJXNI0@a-mtaout20.012.net.il>; Sun, 18 Nov 2012 05:57:20 +0200 (IST) Date: Sun, 18 Nov 2012 05:56:53 +0200 From: Eli Zaretskii Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? In-reply-to: <0D5E662929EB46BABC33674094EA6A24@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83haon1s3e.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <50A7E5AB.3040006@cs.ucla.edu> <83zk2g10ew.fsf@gnu.org> <50A800BD.2@cs.ucla.edu> <0D5E662929EB46BABC33674094EA6A24@us.oracle.com> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: <12908@debbugs.gnu.org>, <12911@debbugs.gnu.org> > Date: Sat, 17 Nov 2012 15:08:17 -0800 > > > > Unless we are going to ask each Emacs user to change the default so > > > that the file ends up in .emacs.d, we still have a > > > discrepancy vs what Stefan asked to do. > > > > I must have missed that request; all I see from him in Bug#12908 > > is a comment about how to deal with the file names > > That's because Stefan wrote it in the proper bug thread, and not in this one > (which Eli asked us to abandon (but which he too continues to populate)): [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4998] X-Debbugs-Envelope-To: 12911 Cc: eggert@cs.ucla.edu, 12911@debbugs.gnu.org, 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > From: "Drew Adams" > Cc: <12908@debbugs.gnu.org>, <12911@debbugs.gnu.org> > Date: Sat, 17 Nov 2012 15:08:17 -0800 > > > > Unless we are going to ask each Emacs user to change the default so > > > that the file ends up in .emacs.d, we still have a > > > discrepancy vs what Stefan asked to do. > > > > I must have missed that request; all I see from him in Bug#12908 > > is a comment about how to deal with the file names > > That's because Stefan wrote it in the proper bug thread, and not in this one > (which Eli asked us to abandon (but which he too continues to populate)): I just reply to messages of others. I cannot afford reading the headers, nor keeping in mind all the bug numbers. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 18 12:09:44 2012 Received: (at 12911) by debbugs.gnu.org; 18 Nov 2012 17:09:44 +0000 Received: from localhost ([127.0.0.1]:53139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ta8NM-0000Mp-8V for submit@debbugs.gnu.org; Sun, 18 Nov 2012 12:09:44 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:45141) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ta8NJ-0000Mg-4Z for 12911@debbugs.gnu.org; Sun, 18 Nov 2012 12:09:42 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDP00J000V0FC00@a-mtaout20.012.net.il> for 12911@debbugs.gnu.org; Sun, 18 Nov 2012 19:08:40 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDP00IPA0YG9JO0@a-mtaout20.012.net.il>; Sun, 18 Nov 2012 19:08:40 +0200 (IST) Date: Sun, 18 Nov 2012 19:08:15 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written In-reply-to: <50A86FC6.6080009@cs.ucla.edu> X-012-Sender: halo1@inter.net.il To: Paul Eggert Message-id: <833906260w.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <753BC08DCC9A446BB22336EDB8AF31CF@us.oracle.com> <83fw471s0y.fsf@gnu.org> <50A86FC6.6080009@cs.ucla.edu> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > On 11/17/2012 07:58 PM, Eli Zaretskii wrote: > > On Unix, the data winds up in some directory under user's home > > directory. > > No, on Unix that data is sent to the standard error stream. > This is documented in the manual. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > On 11/17/2012 07:58 PM, Eli Zaretskii wrote: > > On Unix, the data winds up in some directory under user's home > > directory. > > No, on Unix that data is sent to the standard error stream. > This is documented in the manual. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4993] > On 11/17/2012 07:58 PM, Eli Zaretskii wrote: > > On Unix, the data winds up in some directory under user's home > > directory. > > No, on Unix that data is sent to the standard error stream. > This is documented in the manual. For the record, here's what the manual says: Emacs is not supposed to crash, but if it does, it produces a "crash report" prior to exiting. The crash report is printed to the standard error stream. If Emacs was started from a graphical desktop on a GNU or Unix system, the standard error stream is commonly redirected to a file such as `~/.xsession-errors', so you can look for the crash report there. On MS-Windows, the crash report is written to a file named `emacs_backtrace.txt' in the current directory of the Emacs process, in addition to the standard error stream. > It's common that stderr is redirected to a file, > but it's also common that it's not. Traditionally > it's not, and many people commonly run Emacs that way. Nowadays, tradition is shifting towards GUI invocation, so stderr will be redirected more often than not. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 18 12:18:56 2012 Received: (at 12911) by debbugs.gnu.org; 18 Nov 2012 17:18:56 +0000 Received: from localhost ([127.0.0.1]:53176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ta8WG-0001S8-4W for submit@debbugs.gnu.org; Sun, 18 Nov 2012 12:18:56 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:47489) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ta8WD-0001S0-PF for 12911@debbugs.gnu.org; Sun, 18 Nov 2012 12:18:54 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDP00J0017OGQ00@a-mtaout20.012.net.il> for 12911@debbugs.gnu.org; Sun, 18 Nov 2012 19:17:01 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDP00I421CC9JR0@a-mtaout20.012.net.il>; Sun, 18 Nov 2012 19:17:01 +0200 (IST) Date: Sun, 18 Nov 2012 19:16:35 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written In-reply-to: <50A86FE8.4020203@cs.ucla.edu> X-012-Sender: halo1@inter.net.il To: Paul Eggert Message-id: <83vcd2zv9o.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <50A7E5AB.3040006@cs.ucla.edu> <83zk2g10ew.fsf@gnu.org> <50A800BD.2@cs.ucla.edu> <83d2zb1rqr.fsf@gnu.org> <50A86FE8.4020203@cs.ucla.edu> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Sat, 17 Nov 2012 21:19:36 -0800 > From: Paul Eggert > CC: 12908@debbugs.gnu.org > > Gnulib has a dup2 implementation that works on Microsoft Windows, > so if we use that, it seems we should be able to use the same idea > there too. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4999] X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Sat, 17 Nov 2012 21:19:36 -0800 > From: Paul Eggert > CC: 12908@debbugs.gnu.org > > Gnulib has a dup2 implementation that works on Microsoft Windows, > so if we use that, it seems we should be able to use the same idea > there too. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4676] > Date: Sat, 17 Nov 2012 21:19:36 -0800 > From: Paul Eggert > CC: 12908@debbugs.gnu.org > > Gnulib has a dup2 implementation that works on Microsoft Windows, > so if we use that, it seems we should be able to use the same idea > there too. Thanks, but no, thanks. Gnulib's dup2 implementation uses so many non-trivial interfaces (exceptions, invalid parameter handlers, etc.) that I'd prefer not to deal with for a feature that needs to be rock solid and dependable. In any case, this is an almost orthogonal issue to what is being discussed here. The issue here is not _whether_ to redirect stderr, but rather _where_to_ to redirect it. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 18 12:55:05 2012 Received: (at 12911) by debbugs.gnu.org; 18 Nov 2012 17:55:05 +0000 Received: from localhost ([127.0.0.1]:53198 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ta95F-0002HG-0x for submit@debbugs.gnu.org; Sun, 18 Nov 2012 12:55:05 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:58049) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ta95C-0002Gq-15 for 12911@debbugs.gnu.org; Sun, 18 Nov 2012 12:55:04 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDP00J0030UUY00@a-mtaout20.012.net.il> for 12911@debbugs.gnu.org; Sun, 18 Nov 2012 19:54:02 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDP00IV2320S7Q0@a-mtaout20.012.net.il>; Sun, 18 Nov 2012 19:54:00 +0200 (IST) Date: Sun, 18 Nov 2012 19:53:35 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83r4nqztk0.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <753BC08DCC9A446BB22336EDB8AF31CF@us.oracle.com> <83fw471s0y.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: , <12908@debbugs.gnu.org> > Date: Sat, 17 Nov 2012 20:40:08 -0800 > > I don't care what Emacs does on Unix or on Windows. Well, I do. Which is why I'm working on developing and maintaining Emacs. And if you think that declaring your indifference to the cross-platform compatibility of Emacs raises the value of your arguments in my eyes, then I suggest that you reconsider. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12911 Cc: eggert@cs.ucla.edu, 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: , <12908@debbugs.gnu.org> > Date: Sat, 17 Nov 2012 20:40:08 -0800 > > I don't care what Emacs does on Unix or on Windows. Well, I do. Which is why I'm working on developing and maintaining Emacs. And if you think that declaring your indifference to the cross-platform compatibility of Emacs raises the value of your arguments in my eyes, then I suggest that you reconsider. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4021] > From: "Drew Adams" > Cc: , <12908@debbugs.gnu.org> > Date: Sat, 17 Nov 2012 20:40:08 -0800 > > I don't care what Emacs does on Unix or on Windows. Well, I do. Which is why I'm working on developing and maintaining Emacs. And if you think that declaring your indifference to the cross-platform compatibility of Emacs raises the value of your arguments in my eyes, then I suggest that you reconsider. > my concern is at the user level. Please don't mess with user data. That's > not nice. And this includes user folders containing user files. Any folder on Windows can contain user data, because most Windows users are usually local administrators and have almost unlimited privileges (except perhaps on corporate servers). In fact, Windows doesn't even have a firm notion of a home directory. There are guidelines where _applications_ should put their files, but nothing about what is "home" for the user, where the user should keep her precious lasagna recipes. We (Emacs) pick up one or 2 plausible locations and pretend they are that "home", but they aren't, as far as the OS and the rest of applications are concerned. They are just more or less random directories. > The first rule should be not to do any harm. You are making a mount out of a molehill. There is no harm. Well-behaving applications write to all kinds of directories all the time, including user home directories. Bash writes ~/.bash_history, Bazaar writes ~/.bzr.log, Eshell writes ~/.eshell/*. Etc. etc. -- this is the norm, not the exception. Emacs behaves according to well-established norms. I agree that putting that file in ~/.emacs.d/ (also in the home a directory, so maybe you will still protest) is slightly better. But if Emacs should do that, it should do it on all the supported platforms. I'm sorry, but unless this is what's agreed soon, I _will_ close this bug. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 18 13:43:20 2012 Received: (at 12911) by debbugs.gnu.org; 18 Nov 2012 18:43:20 +0000 Received: from localhost ([127.0.0.1]:53248 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ta9pv-0003Ns-Qo for submit@debbugs.gnu.org; Sun, 18 Nov 2012 13:43:20 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:50904) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ta9ps-0003Nk-SH for 12911@debbugs.gnu.org; Sun, 18 Nov 2012 13:43:18 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAIIgEf0032355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 18 Nov 2012 18:42:15 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAIIgEpX007633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Nov 2012 18:42:14 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAIIgElX010258; Sun, 18 Nov 2012 12:42:14 -0600 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 18 Nov 2012 10:42:14 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <753BC08DCC9A446BB22336EDB8AF31CF@us.oracle.com> <83fw471s0y.fsf@gnu.org> <83r4nqztk0.fsf@gnu.org> Subject: RE: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Date: Sun, 18 Nov 2012 10:42:03 -0800 Message-ID: <0798DA6CB6824DBDBB368EEF1821B2C0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83r4nqztk0.fsf@gnu.org> Thread-Index: Ac3FtbM1v1B3fGS4RoCNiWFCS3go2gABBISA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 12911 Cc: eggert@cs.ucla.edu, 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > > I don't care what Emacs does on Unix or on Windows. > > Well, I do. Which is why I'm working on developing and maintaining > Emacs. Read my statement in context. Taking it out of context reverses the intended meaning. > And if you think that declaring your indifference to the > cross-platform compatibility of Emacs I did no such thing. I am not at all indifferent to cross-platform compatibility. As you know full well. > raises the value of your arguments in my eyes, then I > suggest that you reconsider. > > > my concern is at the user level. Please don't mess with > > user data. That's not nice. And this includes user folders > > containing user files. > > Any folder on Windows can contain user data, because most Windows > users are usually local administrators and have almost unlimited > privileges (except perhaps on corporate servers). Don't make the perfect the enemy of the good. You are stretching things. Yes, what you say is true. No, it is not particularly relevant. Yes, my entire C:/ drive is my drive and my data. So what? Irrelevant to the discussion. Please stick to the particulars. > In fact, Windows > doesn't even have a firm notion of a home directory. There are > guidelines where _applications_ should put their files, but nothing > about what is "home" for the user, where the user should keep her > precious lasagna recipes. We (Emacs) pick up one or 2 plausible > locations and pretend they are that "home", but they aren't, as far as > the OS and the rest of applications are concerned. They are just more > or less random directories. I have no argument with any of what you said there. > > The first rule should be not to do any harm. > > You are making a mount out of a molehill. There is no harm. > Well-behaving applications write to all kinds of directories all the > time, including user home directories. Bash writes ~/.bash_history, > Bazaar writes ~/.bzr.log, Eshell writes ~/.eshell/*. Etc. etc. -- > this is the norm, not the exception. Emacs behaves according to > well-established norms. > > I agree that putting that file in ~/.emacs.d/ (also in the home a > directory, so maybe you will still protest) is slightly better. Why would I protest? I'm the one who _suggested_ putting it there. And I have not once mentioned "home" directory in this discussion. Perhaps you are confusing me with someone else. Anyway, I'm very glad you agree about ~/.emacs.d/. So at the very least this bug should remain open on the wishlist until fixed. To me, this bother is a regression, as I said earlier. But whether you look at it like that or not, at least you agree that it is better to put the file in ~/.emacs.d/. That's progress. > But if Emacs should do that, it should do it on all the > supported platforms. I'm sorry, but unless this is what's > agreed soon, I _will_ close this bug. I have no problem with the bug being fixed on all platforms. In fact, I have explicitly said (several times now) that if this is also a problem on other platforms then it _should_ be fixed there as well. And in the very mail which you quoted out of context above, reversing the sense of what I wrote! This is what I said: If Emacs on Unix is just as user-inconsiderate in this regard as it is on Windows, then it too needs to be sent back for regrooving. And: On any platform. It does not belong there. I just happen to be using Emacs on Windows, and I reported this problem there. If it is not Windows-specific, fine - please fix it wherever it occurs. Pretty damn clear, no? And this: If there is a problem on platform XYZ, please fix it on XYZ. For all XYZ, preferably. For Windows, at least. Is this problem a mountain or a mole hill? Closer to the latter, clearly. But Emacs users never had this bother before. Why should they have it now? Just because on MS Windows everything belongs to the user is no excuse to start polluting arbitrary folders. Such an argument is way off-base. A family who does not (or even cannot) lock their front door is not _asking_ you to come in and trash their house. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 18 14:19:25 2012 Received: (at 12911) by debbugs.gnu.org; 18 Nov 2012 19:19:25 +0000 Received: from localhost ([127.0.0.1]:53265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaAOr-0004AZ-1y for submit@debbugs.gnu.org; Sun, 18 Nov 2012 14:19:25 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]:33854) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaAOn-0004AR-Uc for 12911@debbugs.gnu.org; Sun, 18 Nov 2012 14:19:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id BE303A60003; Sun, 18 Nov 2012 11:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRBarVTPa30O; Sun, 18 Nov 2012 11:18:21 -0800 (PST) Received: from [192.168.1.3] (pool-71-189-154-249.lsanca.fios.verizon.net [71.189.154.249]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 4814FA60001; Sun, 18 Nov 2012 11:18:21 -0800 (PST) Message-ID: <50A93485.9070706@cs.ucla.edu> Date: Sun, 18 Nov 2012 11:18:29 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <50A7E5AB.3040006@cs.ucla.edu> <83zk2g10ew.fsf@gnu.org> <50A800BD.2@cs.ucla.edu> <83d2zb1rqr.fsf@gnu.org> <50A86FE8.4020203@cs.ucla.edu> <83vcd2zv9o.fsf@gnu.org> In-Reply-To: <83vcd2zv9o.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 11/18/2012 09:16 AM, Eli Zaretskii wrote: > The issue here is not _whether_ to redirect stderr, > but rather _where_to_ to redirect it. On GNU and Unix hosts, there's no issue. stderr should not be redirected. It never has been redirected, and there's no reason to change. > ... putting that file in ~/.emacs.d/ (also in the home a > directory, so maybe you will still protest) is slightly better. > But if Emacs should do that, it should do it on all the supported > platforms. There's no reason for Emacs to change its behavior on GNUish hosts. People on these hosts are used to the current behavior with stderr. Any problems in this area are limited to Microsoft platforms, and can be solved in a Microsoft-specific way. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 18 16:11:32 2012 Received: (at control) by debbugs.gnu.org; 18 Nov 2012 21:11:32 +0000 Received: from localhost ([127.0.0.1]:53504 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaC9M-0006lk-Fc for submit@debbugs.gnu.org; Sun, 18 Nov 2012 16:11:32 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:38902) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaC9J-0006lc-Si for control@debbugs.gnu.org; Sun, 18 Nov 2012 16:11:31 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MDP00K00C375M00@a-mtaout22.012.net.il> for control@debbugs.gnu.org; Sun, 18 Nov 2012 23:10:28 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDP00J4YC5FOJD0@a-mtaout22.012.net.il> for control@debbugs.gnu.org; Sun, 18 Nov 2012 23:10:28 +0200 (IST) Date: Sun, 18 Nov 2012 23:10:03 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written X-012-Sender: halo1@inter.net.il To: control@debbugs.gnu.org Message-id: <83ip92zkgk.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: tags 12911 wontfix stop [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: tags 12911 wontfix stop [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4991] tags 12911 wontfix stop From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 18 16:14:58 2012 Received: (at 12911-done) by debbugs.gnu.org; 18 Nov 2012 21:14:58 +0000 Received: from localhost ([127.0.0.1]:53515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaCCg-0006qs-Ct for submit@debbugs.gnu.org; Sun, 18 Nov 2012 16:14:58 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:45414) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaCCc-0006qY-Dy for 12911-done@debbugs.gnu.org; Sun, 18 Nov 2012 16:14:55 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDP00L00C2BPD00@a-mtaout20.012.net.il> for 12911-done@debbugs.gnu.org; Sun, 18 Nov 2012 23:10:36 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDP00LHVC5NKK50@a-mtaout20.012.net.il>; Sun, 18 Nov 2012 23:10:36 +0200 (IST) Date: Sun, 18 Nov 2012 23:10:11 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written In-reply-to: <50A93485.9070706@cs.ucla.edu> X-012-Sender: halo1@inter.net.il To: Paul Eggert Message-id: <83haomzkgc.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <50A7E5AB.3040006@cs.ucla.edu> <83zk2g10ew.fsf@gnu.org> <50A800BD.2@cs.ucla.edu> <83d2zb1rqr.fsf@gnu.org> <50A86FE8.4020203@cs.ucla.edu> <83vcd2zv9o.fsf@gnu.org> <50A93485.9070706@cs.ucla.edu> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Sun, 18 Nov 2012 11:18:29 -0800 > From: Paul Eggert > CC: 12911@debbugs.gnu.org > > There's no reason for Emacs to change its behavior > on GNUish hosts. People on these hosts are used to > the current behavior with stderr. Any problems > in this area are limited to Microsoft platforms, and > can be solved in a Microsoft-specific way. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4985] X-Debbugs-Envelope-To: 12911-done Cc: 12911-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > Date: Sun, 18 Nov 2012 11:18:29 -0800 > From: Paul Eggert > CC: 12911@debbugs.gnu.org > > There's no reason for Emacs to change its behavior > on GNUish hosts. People on these hosts are used to > the current behavior with stderr. Any problems > in this area are limited to Microsoft platforms, and > can be solved in a Microsoft-specific way. There are no problems on Windows, either. Bug closed. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 18 20:45:28 2012 Received: (at 12911) by debbugs.gnu.org; 19 Nov 2012 01:45:28 +0000 Received: from localhost ([127.0.0.1]:53780 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaGQS-0005V5-FD for submit@debbugs.gnu.org; Sun, 18 Nov 2012 20:45:28 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:53556) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaGQP-0005Ux-EC for 12911@debbugs.gnu.org; Sun, 18 Nov 2012 20:45:25 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAG6Zu09sr+ZY/2dsb2JhbABEsEiDSYEIghUBAQQBViMQCzQHCxQYDYhABboJixuCC4MeA4hClXeEeoFYgweBOA X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="207920239" Received: from 108-175-230-88.dsl.teksavvy.com (HELO pastel.home) ([108.175.230.88]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 18 Nov 2012 20:44:23 -0500 Received: by pastel.home (Postfix, from userid 20848) id 822DB597C1; Sun, 18 Nov 2012 20:44:23 -0500 (EST) From: Stefan Monnier To: 12911@debbugs.gnu.org Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Message-ID: References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <50A7E5AB.3040006@cs.ucla.edu> <83zk2g10ew.fsf@gnu.org> <50A800BD.2@cs.ucla.edu> <83d2zb1rqr.fsf@gnu.org> <50A86FE8.4020203@cs.ucla.edu> <83vcd2zv9o.fsf@gnu.org> <50A93485.9070706@cs.ucla.edu> <83haomzkgc.fsf@gnu.org> Date: Sun, 18 Nov 2012 20:44:23 -0500 In-Reply-To: <83haomzkgc.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 18 Nov 2012 23:10:11 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 12911 Cc: eliz@gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) >> There's no reason for Emacs to change its behavior >> on GNUish hosts. People on these hosts are used to >> the current behavior with stderr. Any problems >> in this area are limited to Microsoft platforms, and >> can be solved in a Microsoft-specific way. > There are no problems on Windows, either. There's clearly a problem: creating a file emacs_backtrace.txt in some "in your face" directory annoys some users (and I'm sure we can come up with funny hypothetical scenarios where it leads to serious breakage of god knows what). Hence the suggestion to use ~/.emacs.d which is much less "in your face" and much safer. Stefan "Boy do I wish we never moved away from plain macros" From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 18 20:53:47 2012 Received: (at 12911) by debbugs.gnu.org; 19 Nov 2012 01:53:47 +0000 Received: from localhost ([127.0.0.1]:53786 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaGYU-0005fq-90 for submit@debbugs.gnu.org; Sun, 18 Nov 2012 20:53:47 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:12172) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaGYT-0005fj-1V for 12911@debbugs.gnu.org; Sun, 18 Nov 2012 20:53:45 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAG6Zu09sr+ZY/2dsb2JhbABEsEiDSYEIghUBAQQBViMFCws0BwsUGA0kiBwFugmQRAOIQpV3hHqBWIMH X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="207920477" Received: from 108-175-230-88.dsl.teksavvy.com (HELO pastel.home) ([108.175.230.88]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 18 Nov 2012 20:52:43 -0500 Received: by pastel.home (Postfix, from userid 20848) id 5F6AE597C1; Sun, 18 Nov 2012 20:52:43 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Message-ID: References: <83wqxk3d1z.fsf@gnu.org> Date: Sun, 18 Nov 2012 20:52:43 -0500 In-Reply-To: <83wqxk3d1z.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 17 Nov 2012 09:26:32 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) >> > If such user control is not possible, then please confine such files to >> > somewhere under .emacs.d or some other "hidden" directory that is >> Agreed: writing the file into ~/.emacs.d makes a lot more sense. > I agree, but we need to decide what to do if this directory is remote, > because invoking file handlers in this situation is not possible. The file name should be passed straight to the OS without going through file-name-handlers. If the OS thinks the directory doesn't exit: no big deal! > Also, on Unix, the information is under the home directory, and the > Unix builds don't themselves create any files, but rather reuse > system-wide settings (which AFAIU aren't settable by users). So I'm > unsure what this means for platforms other than Windows. No need to change anything on platforms where stderr works. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 18 22:52:33 2012 Received: (at 12911) by debbugs.gnu.org; 19 Nov 2012 03:52:33 +0000 Received: from localhost ([127.0.0.1]:53878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaIPQ-0008In-Vs for submit@debbugs.gnu.org; Sun, 18 Nov 2012 22:52:33 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:54096) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaIPN-0008Id-Iw for 12911@debbugs.gnu.org; Sun, 18 Nov 2012 22:52:30 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDP00400UJMH900@a-mtaout20.012.net.il> for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 05:51:17 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDP0041MUPHBO90@a-mtaout20.012.net.il>; Mon, 19 Nov 2012 05:51:17 +0200 (IST) Date: Mon, 19 Nov 2012 05:50:53 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83zk2exnc2.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <50A7E5AB.3040006@cs.ucla.edu> <83zk2g10ew.fsf@gnu.org> <50A800BD.2@cs.ucla.edu> <83d2zb1rqr.fsf@gnu.org> <50A86FE8.4020203@cs.ucla.edu> <83vcd2zv9o.fsf@gnu.org> <50A93485.9070706@cs.ucla.edu> <83haomzkgc.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Cc: eliz@gnu.org, drew.adams@oracle.com > Date: Sun, 18 Nov 2012 20:44:23 -0500 > > >> There's no reason for Emacs to change its behavior > >> on GNUish hosts. People on these hosts are used to > >> the current behavior with stderr. Any problems > >> in this area are limited to Microsoft platforms, and > >> can be solved in a Microsoft-specific way. > > There are no problems on Windows, either. > > There's clearly a problem: creating a file emacs_backtrace.txt in some > "in your face" directory annoys some users (and I'm sure we can come up > with funny hypothetical scenarios where it leads to serious breakage of > god knows what). > Hence the suggestion to use ~/.emacs.d which is much less "in your face" > and much safer. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4999] X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > From: Stefan Monnier > Cc: eliz@gnu.org, drew.adams@oracle.com > Date: Sun, 18 Nov 2012 20:44:23 -0500 > > >> There's no reason for Emacs to change its behavior > >> on GNUish hosts. People on these hosts are used to > >> the current behavior with stderr. Any problems > >> in this area are limited to Microsoft platforms, and > >> can be solved in a Microsoft-specific way. > > There are no problems on Windows, either. > > There's clearly a problem: creating a file emacs_backtrace.txt in some > "in your face" directory annoys some users (and I'm sure we can come up > with funny hypothetical scenarios where it leads to serious breakage of > god knows what). > Hence the suggestion to use ~/.emacs.d which is much less "in your face" > and much safer. I'm waiting for this to be implemented on Posix platforms, then. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 18 22:52:58 2012 Received: (at 12911) by debbugs.gnu.org; 19 Nov 2012 03:52:58 +0000 Received: from localhost ([127.0.0.1]:53881 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaIPq-0008JR-9p for submit@debbugs.gnu.org; Sun, 18 Nov 2012 22:52:58 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:63057) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaIPo-0008JK-Qr for 12911@debbugs.gnu.org; Sun, 18 Nov 2012 22:52:57 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MDP00N00ULZ5700@a-mtaout23.012.net.il> for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 05:51:54 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDP00M9FUQHXIF0@a-mtaout23.012.net.il>; Mon, 19 Nov 2012 05:51:54 +0200 (IST) Date: Mon, 19 Nov 2012 05:51:30 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83y5hyxnb1.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Sun, 18 Nov 2012 20:52:43 -0500 > > No need to change anything on platforms where stderr works. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.175 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4911] X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Sun, 18 Nov 2012 20:52:43 -0500 > > No need to change anything on platforms where stderr works. stderr works on Windows as well. See the code I wrote. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 18 23:08:30 2012 Received: (at 12911) by debbugs.gnu.org; 19 Nov 2012 04:08:30 +0000 Received: from localhost ([127.0.0.1]:53928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaIes-0000FU-2Z for submit@debbugs.gnu.org; Sun, 18 Nov 2012 23:08:30 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:19600) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaIeq-0000FN-BS for 12911@debbugs.gnu.org; Sun, 18 Nov 2012 23:08:28 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAG6Zu09sr+ZY/2dsb2JhbABEsEiDSYEIghUBAQQBViMQCzQHCxQYDRABE4gcBboJkEQDiEKVd4R6gViDBw X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="207925697" Received: from 108-175-230-88.dsl.teksavvy.com (HELO pastel.home) ([108.175.230.88]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 18 Nov 2012 23:07:25 -0500 Received: by pastel.home (Postfix, from userid 20848) id 8C253597C1; Sun, 18 Nov 2012 23:07:25 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Message-ID: References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> Date: Sun, 18 Nov 2012 23:07:25 -0500 In-Reply-To: <83y5hyxnb1.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 19 Nov 2012 05:51:30 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.0 (/) >> No need to change anything on platforms where stderr works. > stderr works on Windows as well. See the code I wrote. If stderr works, then why do we need emacs_backtrace.txt? Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 19 10:54:26 2012 Received: (at 12911) by debbugs.gnu.org; 19 Nov 2012 15:54:26 +0000 Received: from localhost ([127.0.0.1]:55229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaTg2-0000V1-6J for submit@debbugs.gnu.org; Mon, 19 Nov 2012 10:54:26 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:34433) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaTfw-0000Uq-NI for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 10:54:23 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDQ00E00S351K00@a-mtaout20.012.net.il> for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 17:53:14 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDQ00DKZS4NBB80@a-mtaout20.012.net.il>; Mon, 19 Nov 2012 17:53:12 +0200 (IST) Date: Mon, 19 Nov 2012 17:52:49 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83wqxhy4ha.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Sun, 18 Nov 2012 23:07:25 -0500 > > >> No need to change anything on platforms where stderr works. > > stderr works on Windows as well. See the code I wrote. > > If stderr works, then why do we need emacs_backtrace.txt? [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4985] X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Sun, 18 Nov 2012 23:07:25 -0500 > > >> No need to change anything on platforms where stderr works. > > stderr works on Windows as well. See the code I wrote. > > If stderr works, then why do we need emacs_backtrace.txt? For when the stuff written to stderr ends up in the Great Void, or scrolls off the screen, or whatever. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 19 13:05:32 2012 Received: (at 12911) by debbugs.gnu.org; 19 Nov 2012 18:05:32 +0000 Received: from localhost ([127.0.0.1]:55386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaViu-0003Vz-2N for submit@debbugs.gnu.org; Mon, 19 Nov 2012 13:05:32 -0500 Received: from relais.videotron.ca ([24.201.245.36]:10898) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaViq-0003Vn-Fk for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 13:05:29 -0500 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ceviche.home ([24.201.208.110]) by VL-VM-MR003.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0MDQ008MJY794SL0@VL-VM-MR003.ip.videotron.ca> for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 13:04:21 -0500 (EST) Received: by ceviche.home (Postfix, from userid 20848) id ED5A0660FF; Mon, 19 Nov 2012 13:04:20 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Message-id: References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> Date: Mon, 19 Nov 2012 13:04:20 -0500 In-reply-to: <83wqxhy4ha.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >> >> No need to change anything on platforms where stderr works. >> > stderr works on Windows as well. See the code I wrote. >> If stderr works, then why do we need emacs_backtrace.txt? > For when the stuff written to stderr ends up in the Great Void, or > scrolls off the screen, or whatever. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [24.201.245.36 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] 0.0 T_HDRS_LCASE Odd capitalization of message header 0.0 T_MANY_HDRS_LCASE Odd capitalization of multiple message headers X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >> >> No need to change anything on platforms where stderr works. >> > stderr works on Windows as well. See the code I wrote. >> If stderr works, then why do we need emacs_backtrace.txt? > For when the stuff written to stderr ends up in the Great Void, or > scrolls off the screen, or whatever. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [24.201.245.36 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] >> >> No need to change anything on platforms where stderr works. >> > stderr works on Windows as well. See the code I wrote. >> If stderr works, then why do we need emacs_backtrace.txt? > For when the stuff written to stderr ends up in the Great Void, or > scrolls off the screen, or whatever. Right. That's what I meant by "stderr doesn't work" (IOW while it does work in some cases, it can't be relied upon). So let me reword my suggestion: I suggested to change the code such that, in those cases where we need to use emacs_backtrace.txt, we use ~/.emacs.d/backtrace.txt instead. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 19 13:14:58 2012 Received: (at 12911) by debbugs.gnu.org; 19 Nov 2012 18:14:58 +0000 Received: from localhost ([127.0.0.1]:55416 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaVs2-0003jE-9A for submit@debbugs.gnu.org; Mon, 19 Nov 2012 13:14:58 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:45385) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaVs0-0003j5-8t for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 13:14:57 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MDQ00E00YHBMG00@a-mtaout22.012.net.il> for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 20:13:26 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDQ00EPQYMDCZ70@a-mtaout22.012.net.il>; Mon, 19 Nov 2012 20:13:26 +0200 (IST) Date: Mon, 19 Nov 2012 20:13:03 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83fw45xxzk.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Mon, 19 Nov 2012 13:04:20 -0500 > > >> >> No need to change anything on platforms where stderr works. > >> > stderr works on Windows as well. See the code I wrote. > >> If stderr works, then why do we need emacs_backtrace.txt? > > For when the stuff written to stderr ends up in the Great Void, or > > scrolls off the screen, or whatever. > > Right. That's what I meant by "stderr doesn't work" (IOW while it does > work in some cases, it can't be relied upon). [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Mon, 19 Nov 2012 13:04:20 -0500 > > >> >> No need to change anything on platforms where stderr works. > >> > stderr works on Windows as well. See the code I wrote. > >> If stderr works, then why do we need emacs_backtrace.txt? > > For when the stuff written to stderr ends up in the Great Void, or > > scrolls off the screen, or whatever. > > Right. That's what I meant by "stderr doesn't work" (IOW while it does > work in some cases, it can't be relied upon). [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4618] > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Mon, 19 Nov 2012 13:04:20 -0500 > > >> >> No need to change anything on platforms where stderr works. > >> > stderr works on Windows as well. See the code I wrote. > >> If stderr works, then why do we need emacs_backtrace.txt? > > For when the stuff written to stderr ends up in the Great Void, or > > scrolls off the screen, or whatever. > > Right. That's what I meant by "stderr doesn't work" (IOW while it does > work in some cases, it can't be relied upon). But then your first sentence above applies not only to Windows, because stderr "doesn't work" in this sense on Unix as well. > So let me reword my suggestion: > > I suggested to change the code such that, in those cases where we need > to use emacs_backtrace.txt, we use ~/.emacs.d/backtrace.txt instead. I already agreed to this, provided that Emacs puts stderr output there on all platforms. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 19 13:36:24 2012 Received: (at 12911) by debbugs.gnu.org; 19 Nov 2012 18:36:24 +0000 Received: from localhost ([127.0.0.1]:55454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaWCm-0004FK-F1 for submit@debbugs.gnu.org; Mon, 19 Nov 2012 13:36:24 -0500 Received: from relais.videotron.ca ([24.201.245.36]:62582) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaWCk-0004FE-Nf for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 13:36:23 -0500 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ceviche.home ([24.201.208.110]) by VL-VM-MR006.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0MDQ00HMUZMSUU80@VL-VM-MR006.ip.videotron.ca> for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 13:35:17 -0500 (EST) Received: by ceviche.home (Postfix, from userid 20848) id C88DA660FF; Mon, 19 Nov 2012 13:35:15 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Message-id: References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> Date: Mon, 19 Nov 2012 13:35:15 -0500 In-reply-to: <83fw45xxzk.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >> >> >> No need to change anything on platforms where stderr works. >> >> > stderr works on Windows as well. See the code I wrote. >> >> If stderr works, then why do we need emacs_backtrace.txt? >> > For when the stuff written to stderr ends up in the Great Void, or >> > scrolls off the screen, or whatever. >> Right. That's what I meant by "stderr doesn't work" (IOW while it does >> work in some cases, it can't be relied upon). > But then your first sentence above applies not only to Windows, > because stderr "doesn't work" in this sense on Unix as well. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [24.201.245.36 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] 0.0 T_HDRS_LCASE Odd capitalization of message header 0.0 T_MANY_HDRS_LCASE Odd capitalization of multiple message headers X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >> >> >> No need to change anything on platforms where stderr works. >> >> > stderr works on Windows as well. See the code I wrote. >> >> If stderr works, then why do we need emacs_backtrace.txt? >> > For when the stuff written to stderr ends up in the Great Void, or >> > scrolls off the screen, or whatever. >> Right. That's what I meant by "stderr doesn't work" (IOW while it does >> work in some cases, it can't be relied upon). > But then your first sentence above applies not only to Windows, > because stderr "doesn't work" in this sense on Unix as well. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [24.201.245.36 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] >> >> >> No need to change anything on platforms where stderr works. >> >> > stderr works on Windows as well. See the code I wrote. >> >> If stderr works, then why do we need emacs_backtrace.txt? >> > For when the stuff written to stderr ends up in the Great Void, or >> > scrolls off the screen, or whatever. >> Right. That's what I meant by "stderr doesn't work" (IOW while it does >> work in some cases, it can't be relied upon). > But then your first sentence above applies not only to Windows, > because stderr "doesn't work" in this sense on Unix as well. I don't know of any case under Unix where stderr is dumped into the great void (except for cases where the user would then also want the backtrace to be dumped in that great void). >> So let me reword my suggestion: >> I suggested to change the code such that, in those cases where we need >> to use emacs_backtrace.txt, we use ~/.emacs.d/backtrace.txt instead. > I already agreed to this, provided that Emacs puts stderr output there > on all platforms. Yes, on all platforms where emacs_backtrace.txt is needed (in practice, this does reduce to w32, AFAIK). Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 19 13:41:42 2012 Received: (at 12911) by debbugs.gnu.org; 19 Nov 2012 18:41:42 +0000 Received: from localhost ([127.0.0.1]:55460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaWHu-0004MO-2x for submit@debbugs.gnu.org; Mon, 19 Nov 2012 13:41:42 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:39876) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaWHr-0004MG-SY for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 13:41:41 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MDQ00600ZOXBZ00@a-mtaout23.012.net.il> for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 20:40:33 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDQ006S2ZVK8D30@a-mtaout23.012.net.il>; Mon, 19 Nov 2012 20:40:33 +0200 (IST) Date: Mon, 19 Nov 2012 20:40:10 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83ehjpxwqd.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Mon, 19 Nov 2012 13:35:15 -0500 > > >> >> >> No need to change anything on platforms where stderr works. > >> >> > stderr works on Windows as well. See the code I wrote. > >> >> If stderr works, then why do we need emacs_backtrace.txt? > >> > For when the stuff written to stderr ends up in the Great Void, or > >> > scrolls off the screen, or whatever. > >> Right. That's what I meant by "stderr doesn't work" (IOW while it does > >> work in some cases, it can't be relied upon). > > But then your first sentence above applies not only to Windows, > > because stderr "doesn't work" in this sense on Unix as well. > > I don't know of any case under Unix where stderr is dumped into the > great void [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.175 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Mon, 19 Nov 2012 13:35:15 -0500 > > >> >> >> No need to change anything on platforms where stderr works. > >> >> > stderr works on Windows as well. See the code I wrote. > >> >> If stderr works, then why do we need emacs_backtrace.txt? > >> > For when the stuff written to stderr ends up in the Great Void, or > >> > scrolls off the screen, or whatever. > >> Right. That's what I meant by "stderr doesn't work" (IOW while it does > >> work in some cases, it can't be relied upon). > > But then your first sentence above applies not only to Windows, > > because stderr "doesn't work" in this sense on Unix as well. > > I don't know of any case under Unix where stderr is dumped into the > great void [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.175 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4939] > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Mon, 19 Nov 2012 13:35:15 -0500 > > >> >> >> No need to change anything on platforms where stderr works. > >> >> > stderr works on Windows as well. See the code I wrote. > >> >> If stderr works, then why do we need emacs_backtrace.txt? > >> > For when the stuff written to stderr ends up in the Great Void, or > >> > scrolls off the screen, or whatever. > >> Right. That's what I meant by "stderr doesn't work" (IOW while it does > >> work in some cases, it can't be relied upon). > > But then your first sentence above applies not only to Windows, > > because stderr "doesn't work" in this sense on Unix as well. > > I don't know of any case under Unix where stderr is dumped into the > great void It can still scroll off the screen. Or end up in some file that the window-system developers or admins set up, and that is some random or unknown place, as far as Emacs users and maintainers are concerned. I see no significant difference. > >> So let me reword my suggestion: > >> I suggested to change the code such that, in those cases where we need > >> to use emacs_backtrace.txt, we use ~/.emacs.d/backtrace.txt instead. > > I already agreed to this, provided that Emacs puts stderr output there > > on all platforms. > > Yes, on all platforms where emacs_backtrace.txt is needed (in practice, > this does reduce to w32, AFAIK). No, on _all_ platforms. But I'm repeating myself. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 19 14:48:47 2012 Received: (at 12911) by debbugs.gnu.org; 19 Nov 2012 19:48:47 +0000 Received: from localhost ([127.0.0.1]:55539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaXKp-0007f8-Fo for submit@debbugs.gnu.org; Mon, 19 Nov 2012 14:48:47 -0500 Received: from relais.videotron.ca ([24.201.245.36]:61237) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaXKm-0007ey-3J for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 14:48:45 -0500 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ceviche.home ([24.201.208.110]) by VL-VM-MR004.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0MDR002RV2Z2RY40@VL-VM-MR004.ip.videotron.ca> for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 14:47:26 -0500 (EST) Received: by ceviche.home (Postfix, from userid 20848) id 1CCA6660FF; Mon, 19 Nov 2012 14:47:26 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Message-id: References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> Date: Mon, 19 Nov 2012 14:47:26 -0500 In-reply-to: <83ehjpxwqd.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >> I don't know of any case under Unix where stderr is dumped into the >> great void > It can still scroll off the screen. Or end up in some file that the > window-system developers or admins set up, and that is some random or > unknown place, as far as Emacs users and maintainers are concerned. > I see no significant difference. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [24.201.245.36 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] 0.0 T_HDRS_LCASE Odd capitalization of message header 0.0 T_MANY_HDRS_LCASE Odd capitalization of multiple message headers X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >> I don't know of any case under Unix where stderr is dumped into the >> great void > It can still scroll off the screen. Or end up in some file that the > window-system developers or admins set up, and that is some random or > unknown place, as far as Emacs users and maintainers are concerned. > I see no significant difference. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [24.201.245.36 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] >> I don't know of any case under Unix where stderr is dumped into the >> great void > It can still scroll off the screen. Or end up in some file that the > window-system developers or admins set up, and that is some random or > unknown place, as far as Emacs users and maintainers are concerned. > I see no significant difference. The difference is that the above cases are hypothetical, whereas the w32 case is the norm. >> >> So let me reword my suggestion: >> >> I suggested to change the code such that, in those cases where we need >> >> to use emacs_backtrace.txt, we use ~/.emacs.d/backtrace.txt instead. >> > I already agreed to this, provided that Emacs puts stderr output there >> > on all platforms. >> Yes, on all platforms where emacs_backtrace.txt is needed (in practice, >> this does reduce to w32, AFAIK). > No, on _all_ platforms. We disagree on the "is needed" part. I'm not sure that w32 is the only one where it's needed, but so far the need hasn't cropped up elsewhere. Maybe macsox needs it as well? Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 19 15:07:06 2012 Received: (at 12911) by debbugs.gnu.org; 19 Nov 2012 20:07:06 +0000 Received: from localhost ([127.0.0.1]:55575 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaXcV-0000W9-7f for submit@debbugs.gnu.org; Mon, 19 Nov 2012 15:07:06 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:46155) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaXcP-0000Vh-Ls for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 15:07:01 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MDR006003TMQ800@a-mtaout23.012.net.il> for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 22:05:50 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDR006L63TPLJ50@a-mtaout23.012.net.il>; Mon, 19 Nov 2012 22:05:50 +0200 (IST) Date: Mon, 19 Nov 2012 22:05:27 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <838v9xxss8.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Mon, 19 Nov 2012 14:47:26 -0500 > > >> I don't know of any case under Unix where stderr is dumped into the > >> great void > > It can still scroll off the screen. Or end up in some file that the > > window-system developers or admins set up, and that is some random or > > unknown place, as far as Emacs users and maintainers are concerned. > > I see no significant difference. > > The difference is that the above cases are hypothetical, whereas the w32 > case is the norm. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.175 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Mon, 19 Nov 2012 14:47:26 -0500 > > >> I don't know of any case under Unix where stderr is dumped into the > >> great void > > It can still scroll off the screen. Or end up in some file that the > > window-system developers or admins set up, and that is some random or > > unknown place, as far as Emacs users and maintainers are concerned. > > I see no significant difference. > > The difference is that the above cases are hypothetical, whereas the w32 > case is the norm. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.175 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4990] > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Mon, 19 Nov 2012 14:47:26 -0500 > > >> I don't know of any case under Unix where stderr is dumped into the > >> great void > > It can still scroll off the screen. Or end up in some file that the > > window-system developers or admins set up, and that is some random or > > unknown place, as far as Emacs users and maintainers are concerned. > > I see no significant difference. > > The difference is that the above cases are hypothetical, whereas the w32 > case is the norm. Neither is correct. I just had the backtrace on GNU/Linux scroll off on me (a TTY session crashed). And I almost always invoke Emacs on Windows in a way that leaves stderr output around. But that is besides the point. For J.R. Hacker who reads the manual, what matters is what happens on her machine, not the statistical average. And what happens on her machine could well be that stderr ends up in some random place on her disk. As long as that is a real possibility, writing emacs_backtrace.txt in the directory it is written now on Windows is equivalent to what happens on Unix. Making it in ~/.emacs.d on w32 alone doesn't change the basic fact that most of the users we care about will still have their backtraces in random places. Why not change that on all platforms? Why demand that only of w32? For that matter, why do you care so much about w32 users? > >> >> So let me reword my suggestion: > >> >> I suggested to change the code such that, in those cases where we need > >> >> to use emacs_backtrace.txt, we use ~/.emacs.d/backtrace.txt instead. > >> > I already agreed to this, provided that Emacs puts stderr output there > >> > on all platforms. > >> Yes, on all platforms where emacs_backtrace.txt is needed (in practice, > >> this does reduce to w32, AFAIK). > > No, on _all_ platforms. > > We disagree on the "is needed" part. No, we disagree about the importance of uniformity in operation across platforms. Either the data is in a platform-specific place, in which case the current arrangement is as good as any, or it is in the same Emacs-specific place on all platforms. The latter is the arrangement I'd support and it will give me enough motivation to spend more effort on this (although I'm not sure I have any energy left after this longish discussion). From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 19 16:16:29 2012 Received: (at 12911) by debbugs.gnu.org; 19 Nov 2012 21:16:29 +0000 Received: from localhost ([127.0.0.1]:55649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaYhg-00023o-PL for submit@debbugs.gnu.org; Mon, 19 Nov 2012 16:16:28 -0500 Received: from relais.videotron.ca ([24.201.245.36]:16139) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaYhe-00023f-8I for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 16:16:27 -0500 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ceviche.home ([24.201.208.110]) by VL-VM-MR001.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0MDR007OE71IRP80@VL-VM-MR001.ip.videotron.ca> for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 16:15:18 -0500 (EST) Received: by ceviche.home (Postfix, from userid 20848) id 25DD4660FF; Mon, 19 Nov 2012 16:15:17 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Message-id: References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> Date: Mon, 19 Nov 2012 16:15:17 -0500 In-reply-to: <838v9xxss8.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Making it in ~/.emacs.d on w32 alone doesn't change the basic fact > that most of the users we care about will still have their backtraces > in random places. No, ~/.xsesson-errors is not a random place. Even if the user doesn't know it, we do. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [24.201.245.36 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] 0.0 T_HDRS_LCASE Odd capitalization of message header 0.0 T_MANY_HDRS_LCASE Odd capitalization of multiple message headers X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Making it in ~/.emacs.d on w32 alone doesn't change the basic fact > that most of the users we care about will still have their backtraces > in random places. No, ~/.xsesson-errors is not a random place. Even if the user doesn't know it, we do. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [24.201.245.36 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] > Making it in ~/.emacs.d on w32 alone doesn't change the basic fact > that most of the users we care about will still have their backtraces > in random places. No, ~/.xsesson-errors is not a random place. Even if the user doesn't know it, we do. > Why not change that on all platforms? Because stderr is good enough under GNU/Linux (and it's easy to redirect when it matters). > Why demand that only of w32? Because currently w32 users get annoyed with new files appearing where they don't want any. If you prefer to always send it to stderr under Windows, please do so, I really couldn't care less if that means it's usually sent to /dev/null. > No, we disagree about the importance of uniformity in operation across > platforms. I suggested above another way to be uniform across platforms. > Either the data is in a platform-specific place, in which > case the current arrangement is as good as any, No, writing to an arbitrary file in the current directory is not a good arrangement. I personally don't care whether it's uniform across platforms or not. I didn't like the backtrace business to start with and am finding it worse by the day. And it doesn't even give me the info that the old "assert in a macro" gave me. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 19 23:00:07 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 04:00:07 +0000 Received: from localhost ([127.0.0.1]:56063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Taf0I-0003WH-IE for submit@debbugs.gnu.org; Mon, 19 Nov 2012 23:00:06 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:55985) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Taf0F-0003W9-Vd for 12911@debbugs.gnu.org; Mon, 19 Nov 2012 23:00:04 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDR00L00PD10O00@a-mtaout20.012.net.il> for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 05:58:55 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDR00KT4PQ6YG30@a-mtaout20.012.net.il>; Tue, 20 Nov 2012 05:58:55 +0200 (IST) Date: Tue, 20 Nov 2012 05:58:33 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83zk2dvsba.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Mon, 19 Nov 2012 16:15:17 -0500 > > > Making it in ~/.emacs.d on w32 alone doesn't change the basic fact > > that most of the users we care about will still have their backtraces > > in random places. > > No, ~/.xsesson-errors is not a random place. Even if the user doesn't > know it, we do. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Mon, 19 Nov 2012 16:15:17 -0500 > > > Making it in ~/.emacs.d on w32 alone doesn't change the basic fact > > that most of the users we care about will still have their backtraces > > in random places. > > No, ~/.xsesson-errors is not a random place. Even if the user doesn't > know it, we do. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4999] > From: Stefan Monnier > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Mon, 19 Nov 2012 16:15:17 -0500 > > > Making it in ~/.emacs.d on w32 alone doesn't change the basic fact > > that most of the users we care about will still have their backtraces > > in random places. > > No, ~/.xsesson-errors is not a random place. Even if the user doesn't > know it, we do. This place is also platform-specific. Not on every Posix platform stderr is put there. > > Why not change that on all platforms? > > Because stderr is good enough under GNU/Linux (and it's easy to > redirect when it matters). And the current arrangement on Windows is good enough for that system. > > Why demand that only of w32? > > Because currently w32 users get annoyed with new files appearing where > they don't want any. Only one user complained so far. > If you prefer to always send it to stderr under Windows, please do > so, I really couldn't care less if that means it's usually sent to > /dev/null. Well, I do care, so I wrote the code to be better than that. > No, writing to an arbitrary file in the current directory is not > a good arrangement. I disagree, obviously. > I didn't like the backtrace business to start with and am finding it > worse by the day. Should I say "told you so"? From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 00:00:32 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 05:00:32 +0000 Received: from localhost ([127.0.0.1]:56101 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tafwm-0004qo-A3 for submit@debbugs.gnu.org; Tue, 20 Nov 2012 00:00:32 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:56980) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tafwk-0004qh-UG for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 00:00:31 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAG6Zu09sr+ZY/2dsb2JhbABEsEiDSYEIghUBAQQBViMQCzQHCxQYDSSIHAW6CZBEA4hClXeEeoFYgwc X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="208025361" Received: from 108-175-230-88.dsl.teksavvy.com (HELO pastel.home) ([108.175.230.88]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 19 Nov 2012 23:59:22 -0500 Received: by pastel.home (Postfix, from userid 20848) id 462E3597C9; Mon, 19 Nov 2012 23:59:21 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Message-ID: References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> Date: Mon, 19 Nov 2012 23:59:21 -0500 In-Reply-To: <83zk2dvsba.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 20 Nov 2012 05:58:33 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) >> Because currently w32 users get annoyed with new files appearing where >> they don't want any. > Only one user complained so far. FWIW, I'd be annoyed if I were a w32 user and had to deal with emacs_backtrace.txt files appearing in directories without my saying so explicitly. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 00:03:40 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 05:03:40 +0000 Received: from localhost ([127.0.0.1]:56105 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tafzn-0004vB-OP for submit@debbugs.gnu.org; Tue, 20 Nov 2012 00:03:40 -0500 Received: from dancol.org ([96.126.100.184]:37814) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tafzl-0004v3-S5 for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 00:03:39 -0500 Received: from c-76-22-66-162.hsd1.wa.comcast.net ([76.22.66.162] helo=[0.0.0.0]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tafye-0007en-Bs; Mon, 19 Nov 2012 21:02:28 -0800 Message-ID: <50AB0EDE.40109@dancol.org> Date: Mon, 19 Nov 2012 21:02:22 -0800 From: Daniel Colascione User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8F0688C090A9EFE073795950" X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 12911 Cc: Eli Zaretskii , 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.4 (/) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8F0688C090A9EFE073795950 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/19/2012 8:59 PM, Stefan Monnier wrote: >>> Because currently w32 users get annoyed with new files appearing wher= e >>> they don't want any. >> Only one user complained so far. >=20 > FWIW, I'd be annoyed if I were a w32 user and had to deal with > emacs_backtrace.txt files appearing in directories without my saying > so explicitly. I agree that the behavior is bad. If we really need these emacs_backtrace= =2Etxt, they should go under %LOCALAPPDATA%. --------------enig8F0688C090A9EFE073795950 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Cygwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCrDuIACgkQ17c2LVA10VsWvACglpeyNauymFxc8ajHgs4Gb58W 30IAoNIBf1UiY/el9fDPZPaCCm73u4Oy =zOB3 -----END PGP SIGNATURE----- --------------enig8F0688C090A9EFE073795950-- From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 08:18:00 2012 Received: (at submit) by debbugs.gnu.org; 20 Nov 2012 13:18:00 +0000 Received: from localhost ([127.0.0.1]:56431 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaniC-00005z-Bd for submit@debbugs.gnu.org; Tue, 20 Nov 2012 08:18:00 -0500 Received: from eggs.gnu.org ([208.118.235.92]:48200) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tani9-00005R-Qk for submit@debbugs.gnu.org; Tue, 20 Nov 2012 08:17:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tangx-00042E-UB for submit@debbugs.gnu.org; Tue, 20 Nov 2012 08:16:48 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:58143) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tangx-000429-Qp for submit@debbugs.gnu.org; Tue, 20 Nov 2012 08:16:43 -0500 Received: from eggs.gnu.org ([208.118.235.92]:40753) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tangs-000314-4o for bug-gnu-emacs@gnu.org; Tue, 20 Nov 2012 08:16:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tangm-00040A-8z for bug-gnu-emacs@gnu.org; Tue, 20 Nov 2012 08:16:38 -0500 Received: from plane.gmane.org ([80.91.229.3]:41820) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tangm-0003zV-2P for bug-gnu-emacs@gnu.org; Tue, 20 Nov 2012 08:16:32 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Tangt-00051F-FU for bug-gnu-emacs@gnu.org; Tue, 20 Nov 2012 14:16:39 +0100 Received: from uk.solarflare.com ([193.34.186.16]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Nov 2012 14:16:39 +0100 Received: from andrewjmoreton by uk.solarflare.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Nov 2012 14:16:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Andy Moreton Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Date: Tue, 20 Nov 2012 13:16:18 +0000 Lines: 18 Message-ID: References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: uk.solarflare.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (windows-nt) Cancel-Lock: sha1:Sd3BMEkMZw3tsLBZbAyGT3OIxsQ= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.0 (-----) On Tue 20 Nov 2012, Daniel Colascione wrote: > On 11/19/2012 8:59 PM, Stefan Monnier wrote: >>>> Because currently w32 users get annoyed with new files appearing where >>>> they don't want any. >>> Only one user complained so far. >> >> FWIW, I'd be annoyed if I were a w32 user and had to deal with >> emacs_backtrace.txt files appearing in directories without my saying >> so explicitly. > > I agree that the behavior is bad. If we really need these emacs_backtrace.txt, > they should go under %LOCALAPPDATA%. Given that the backtrace does not include symbols, it seems fairly useless to me. I'd vote for getting rid of it on all platforms. AndyM From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 11:29:56 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 16:29:57 +0000 Received: from localhost ([127.0.0.1]:57073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Taqhw-0004bI-JH for submit@debbugs.gnu.org; Tue, 20 Nov 2012 11:29:56 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:39816) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Taqht-0004b8-Ip for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 11:29:54 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDS00700OCW5C00@a-mtaout20.012.net.il> for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 18:28:07 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDS006TDOEVJTC0@a-mtaout20.012.net.il>; Tue, 20 Nov 2012 18:28:07 +0200 (IST) Date: Tue, 20 Nov 2012 18:27:47 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written In-reply-to: X-012-Sender: halo1@inter.net.il To: Andy Moreton Message-id: <83txskw870.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Andy Moreton > Date: Tue, 20 Nov 2012 13:16:18 +0000 > > Given that the backtrace does not include symbols, it seems fairly > useless to me. I'd vote for getting rid of it on all platforms. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4958] X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > From: Andy Moreton > Date: Tue, 20 Nov 2012 13:16:18 +0000 > > Given that the backtrace does not include symbols, it seems fairly > useless to me. I'd vote for getting rid of it on all platforms. I'd be the last to defend the feature, but out of fairness: symbolic information (i.e. file names and source line numbers) are one command away. See the manual for details. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 11:38:44 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 16:38:44 +0000 Received: from localhost ([127.0.0.1]:57091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaqqR-0004oQ-RD for submit@debbugs.gnu.org; Tue, 20 Nov 2012 11:38:44 -0500 Received: from mail-ee0-f44.google.com ([74.125.83.44]:60272) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaqqP-0004oI-Jl for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 11:38:42 -0500 Received: by mail-ee0-f44.google.com with SMTP id b47so3913124eek.3 for <12911@debbugs.gnu.org>; Tue, 20 Nov 2012 08:37:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=T5OnO3pRQ7i6wWoqh0HVd0izUTBSk7RP8mvbNFmAPW4=; b=0YHnUObBpJ/Epkf/UknbFl8+IKll0J6k19PZxG3T2j5HfoDwiUpyMoaOSdF98mWi1n VNjlkq33+3PQlUNq+jxDOj1A7Avo9ib1uvYVkf3FgG6jC23Y/Hcydpq//DGLo8PPjr6u JiX1xLAfxRnlUAd5xdwqDz5Q4BN7RXZB8URE/EMzr0CEnlqVdc62K9/9z1Tpc7v6ZiyI waI1Z+GbKPoa+Mm23cuEco7YYGvA+yi1tTucasvcOsXJE+q4y8T0FKU1dk8/4oL9BXKp GI2+S5EKktaC0xzYFcWNlbMqBIMos4EobnSWsh3yMTXzXitZwESB6nEnN3atQhYKgZQs iEPg== Received: by 10.14.193.136 with SMTP id k8mr35577366een.30.1353429450970; Tue, 20 Nov 2012 08:37:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.4.209 with HTTP; Tue, 20 Nov 2012 08:36:50 -0800 (PST) In-Reply-To: References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> From: Juanma Barranquero Date: Tue, 20 Nov 2012 17:36:50 +0100 Message-ID: Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written To: Stefan Monnier Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12911 Cc: Eli Zaretskii , 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On Tue, Nov 20, 2012 at 5:59 AM, Stefan Monnier wrote: > FWIW, I'd be annoyed if I were a w32 user and had to deal with > emacs_backtrace.txt files appearing in directories without my saying > so explicitly. Windows binaries for official releases (as opposed to trunk snapshots) rarely crash. It's not as if the user is going to get backtraces all over his hard disk on every single run. Juanma From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 12:05:16 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 17:05:16 +0000 Received: from localhost ([127.0.0.1]:57122 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TarG7-0005RZ-VL for submit@debbugs.gnu.org; Tue, 20 Nov 2012 12:05:16 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:55829) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TarG4-0005RO-OD for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 12:05:14 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MDS00600Q19G500@a-mtaout22.012.net.il> for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 19:03:47 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDS0059MQ2ATNB0@a-mtaout22.012.net.il>; Tue, 20 Nov 2012 19:03:47 +0200 (IST) Date: Tue, 20 Nov 2012 19:03:27 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written In-reply-to: <50AB0EDE.40109@dancol.org> X-012-Sender: halo1@inter.net.il To: Daniel Colascione Message-id: <83r4now6jk.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Mon, 19 Nov 2012 21:02:22 -0800 > From: Daniel Colascione > CC: Eli Zaretskii , 12911@debbugs.gnu.org > > On 11/19/2012 8:59 PM, Stefan Monnier wrote: > >>> Because currently w32 users get annoyed with new files appearing where > >>> they don't want any. > >> Only one user complained so far. > > > > FWIW, I'd be annoyed if I were a w32 user and had to deal with > > emacs_backtrace.txt files appearing in directories without my saying > > so explicitly. > > I agree that the behavior is bad. If we really need these emacs_backtrace.txt, > they should go under %LOCALAPPDATA%. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.2 (/) > Date: Mon, 19 Nov 2012 21:02:22 -0800 > From: Daniel Colascione > CC: Eli Zaretskii , 12911@debbugs.gnu.org > > On 11/19/2012 8:59 PM, Stefan Monnier wrote: > >>> Because currently w32 users get annoyed with new files appearing where > >>> they don't want any. > >> Only one user complained so far. > > > > FWIW, I'd be annoyed if I were a w32 user and had to deal with > > emacs_backtrace.txt files appearing in directories without my saying > > so explicitly. > > I agree that the behavior is bad. If we really need these emacs_backtrace.txt, > they should go under %LOCALAPPDATA%. Maybe you guys think I've decided to put the file in the current directory without any thought, just because I find it easier not to futz with leading directories. That's far from being true. I did invest some thought and a bit of research before making a decision. Look, we are talking about emergency measures. Not some normal feature that writes files as a matter of habit. Emacs is going down in flames, and we want at the last moment to get some information from it. Code that does that must be as simple and as reliable as possible, or it will not work, or, worse, cause nested exceptions that will completely obscure the original cause. %LOCALAPPDATA%? It doesn't exist on XP and earlier systems. There's only %APPDATA% there. To distinguish, we'd need to probe the OS version, or try both places. That means more system API calls. Not rocket science, but still: complications, at the time that every tweak counts. (Incidentally, %APPDATA% is what we by default treat as HOME, a directory that I'm told is full of lasagna recipes we are not allowed to contaminate.) Accessing environment variables is another problematic place. We are crashing, so the heap or the whole arena can be trashed. Who can be sure the environment variables will not point to garbled places? And what if the %LOCALAPPDATA% doesn't exist as an environment variable? We'd need to access the Registry. More complications and API calls. Someone else suggested to write into the directory where the Emacs binary is installed. But latest Windows versions make the directory where programs are installed write-protected, especially if the user has Administrator privileges. Worse, there's this thing called "filesystem virtualization", whereby the program is allowed to write to those directories, but the data is actually redirected into some hidden directory no one can find, even if they know about this. Etc., etc. Yes, the current directory is far from ideal. But on balance, I find it the lesser evil, and my long experience on MS-Windows tells me that it is still the best choice for data you must reliably write somewhere. (Of course, Stefan says that he doesn't care if the data is lost, so all of the above doesn't matter to him. But, as long as we have this feature, I _do_ care, otherwise I wouldn't have sit down and written it. Arguments whose authors don't care cannot possibly convince me. If we _really_ don't care, let's go ahead and rip out the whole feature. That'd be at least honest.) From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 12:13:06 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 17:13:06 +0000 Received: from localhost ([127.0.0.1]:57146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TarNi-0005dT-4i for submit@debbugs.gnu.org; Tue, 20 Nov 2012 12:13:06 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:32417) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TarNf-0005dL-QL for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 12:13:04 -0500 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAKHBqnq002459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Nov 2012 17:11:53 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAKHBpus016818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2012 17:11:52 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAKHBpBU008756; Tue, 20 Nov 2012 11:11:51 -0600 Received: from dradamslap1 (/10.159.225.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Nov 2012 09:11:51 -0800 From: "Drew Adams" To: "'Juanma Barranquero'" , "'Stefan Monnier'" References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> Subject: RE: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written Date: Tue, 20 Nov 2012 09:11:46 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac3HPWoQ8d4+vMXBTqyG2IgQaAW+qQAALHVw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > > FWIW, I'd be annoyed if I were a w32 user and had to deal with > > emacs_backtrace.txt files appearing in directories without my saying > > so explicitly. > > Windows binaries for official releases (as opposed to trunk snapshots) > rarely crash. It's not as if the user is going to get backtraces all > over his hard disk on every single run. FWIW, that is not my experience, not with Emacs 24. Official Emacs binaries 24.1 and 24.2 crash for me, seemingly randomly, sooner or later, pretty much each time I use them - and I don't get to use them for long. If I had a recipe I would send it along. I sent an emacs-backtrace.txt file recently, which Eli said should be useful, but no news yet on whether it helped fix some bug. ;-) I agree, however, that a user is not going to be getting backtraces all over the place. That's some consolation, but not reason enough by itself to introduce this regression, IMHO (just one opinion). As Eli himself said - and was the first to point out AFAIK (http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00501.html): EZ> Based on my experience, I expect this "feature" to be hated, EZ> by users and Emacs maintainers alike. I think he's likely to be right in that guess. And he points out several reasons against introducing this feature (reasons I'm not qualified to judge). Eli also said, there: EZ> using the limited information it provides can be quite difficult Whether the feature is worth the various drawbacks mentioned, I, for one, cannot say. But it sure would be good to find a way to put these backtrace files somewhere other than a user folder. That I will say. FWIW, both Emacs maintainers have seemed to agree. Yidong said this (http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00870.html): CY> Littering the filesystem with these backtrace files is CY> kind of obnoxious. Certainly, plopping them into user folders is. User data is not for Emacs to fiddle with uninvited, and that includes folders. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 12:37:54 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 17:37:54 +0000 Received: from localhost ([127.0.0.1]:57182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tarlh-000746-Ne for submit@debbugs.gnu.org; Tue, 20 Nov 2012 12:37:54 -0500 Received: from dancol.org ([96.126.100.184]:39598) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tarlf-00073y-Ck for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 12:37:52 -0500 Received: from c-76-22-66-162.hsd1.wa.comcast.net ([76.22.66.162] helo=[192.168.1.2]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TarkV-0000C2-2d; Tue, 20 Nov 2012 09:36:39 -0800 Message-ID: <50ABBFA4.6080402@dancol.org> Date: Tue, 20 Nov 2012 09:36:36 -0800 From: Daniel Colascione User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> <83r4now6jk.fsf@gnu.org> In-Reply-To: <83r4now6jk.fsf@gnu.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig91172F8A1B46B397D910855B" X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.4 (/) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig91172F8A1B46B397D910855B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/20/12 9:03 AM, Eli Zaretskii wrote: >> Date: Mon, 19 Nov 2012 21:02:22 -0800 >> From: Daniel Colascione >> CC: Eli Zaretskii , 12911@debbugs.gnu.org >> >> On 11/19/2012 8:59 PM, Stefan Monnier wrote: >>>>> Because currently w32 users get annoyed with new files appearing wh= ere >>>>> they don't want any. >>>> Only one user complained so far. >>> >>> FWIW, I'd be annoyed if I were a w32 user and had to deal with >>> emacs_backtrace.txt files appearing in directories without my saying >>> so explicitly. >> >> I agree that the behavior is bad. If we really need these emacs_backtr= ace.txt, >> they should go under %LOCALAPPDATA%. >=20 > %LOCALAPPDATA%? It doesn't exist on XP and earlier systems. There's > only %APPDATA% there. To distinguish, we'd need to probe the OS > version, or try both places. That means more system API calls. Not > rocket science, but still: complications, at the time that every tweak > counts. > Accessing environment variables is another problematic place. > And what if the %LOCALAPPDATA% doesn't exist as an environment > variable? We'd need to access the Registry. Compute the name of the backtrace file when Emacs starts. A crash is unlikely to corrupt a single allocation. > (Incidentally, %APPDATA% is what we by default treat as HOME, a > directory that I'm told is full of lasagna recipes we are not allowed > to contaminate.) %USERPROFILE% is where I put my lasagna recipes. %APPDATA% is full of non-user-visible application data on my system. Is %APPDATA% actually a user-visible directory of some sort on XP? > We are > crashing, so the heap or the whole arena can be trashed. Who can be > sure the environment variables will not point to garbled places? A process cannot reliably report all of its own crashes. That's why Windows Error Reporting monitors processes with a service and collects dumps of crashing processes from outside, in a separate process. Collecting information about most crashes is adequate. --------------enig91172F8A1B46B397D910855B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlCrv6UACgkQ17c2LVA10VtWkACeN45EZFYgK1dtCSaQgKczDp3+ VXAAoOSnBbRnMnqylrYSsOXEjhU+9GC7 =CQ8T -----END PGP SIGNATURE----- --------------enig91172F8A1B46B397D910855B-- From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 12:50:53 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 17:50:53 +0000 Received: from localhost ([127.0.0.1]:57210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaryG-0007Ob-KR for submit@debbugs.gnu.org; Tue, 20 Nov 2012 12:50:52 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:61376) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TaryF-0007OU-0q for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 12:50:51 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDS00700S4QWA00@a-mtaout20.012.net.il> for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 19:49:39 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDS0079HS6RRW40@a-mtaout20.012.net.il>; Tue, 20 Nov 2012 19:49:39 +0200 (IST) Date: Tue, 20 Nov 2012 19:49:19 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written In-reply-to: X-012-Sender: halo1@inter.net.il To: Juanma Barranquero Message-id: <83lidww4f4.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Juanma Barranquero > Date: Tue, 20 Nov 2012 17:36:50 +0100 > Cc: Eli Zaretskii , 12911@debbugs.gnu.org > > It's not as if the user is going to get backtraces all over his hard > disk on every single run. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4552] X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.2 (/) > From: Juanma Barranquero > Date: Tue, 20 Nov 2012 17:36:50 +0100 > Cc: Eli Zaretskii , 12911@debbugs.gnu.org > > It's not as if the user is going to get backtraces all over his hard > disk on every single run. "All over the hard disk" will almost never happen, because people who invoke Emacs from a desktop icon will always have Emacs run in the same directory. All the backtraces will be on a single file in that directory. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 12:55:12 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 17:55:12 +0000 Received: from localhost ([127.0.0.1]:57217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tas2S-0007Un-A7 for submit@debbugs.gnu.org; Tue, 20 Nov 2012 12:55:12 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:37080) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tas2P-0007Uf-KZ for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 12:55:10 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MDS00600S8RU100@a-mtaout22.012.net.il> for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 19:53:39 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDS00657SDEGYB0@a-mtaout22.012.net.il>; Tue, 20 Nov 2012 19:53:39 +0200 (IST) Date: Tue, 20 Nov 2012 19:53:19 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83ip90w48g.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 12911 Cc: lekktu@gmail.com, 12911@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Date: Tue, 20 Nov 2012 09:11:46 -0800 > Cc: 12911@debbugs.gnu.org > > I sent an emacs-backtrace.txt file recently Where? I must have missed that, or maybe forgot. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 13:04:18 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 18:04:18 +0000 Received: from localhost ([127.0.0.1]:57221 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TasBG-0007hf-7L for submit@debbugs.gnu.org; Tue, 20 Nov 2012 13:04:18 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:64681) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TasBC-0007hW-H5 for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 13:04:16 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDS00700SAIYI00@a-mtaout20.012.net.il> for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 20:03:03 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDS007O7ST2I9A0@a-mtaout20.012.net.il>; Tue, 20 Nov 2012 20:03:03 +0200 (IST) Date: Tue, 20 Nov 2012 20:02:43 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written In-reply-to: <50ABBFA4.6080402@dancol.org> X-012-Sender: halo1@inter.net.il To: Daniel Colascione Message-id: <83haokw3ss.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> <83r4now6jk.fsf@gnu.org> <50ABBFA4.6080402@dancol.org> X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.2 (/) > Date: Tue, 20 Nov 2012 09:36:36 -0800 > From: Daniel Colascione > CC: monnier@iro.umontreal.ca, 12911@debbugs.gnu.org > > Compute the name of the backtrace file when Emacs starts. Sorry, as long as this is a Windows-specific issue, I don't have any motivation to go to that length. > > (Incidentally, %APPDATA% is what we by default treat as HOME, a > > directory that I'm told is full of lasagna recipes we are not allowed > > to contaminate.) > > %USERPROFILE% is where I put my lasagna recipes. %APPDATA% is full of > non-user-visible application data on my system. That's another sign of what I said earlier: there's no home directory on Windows. Yet another candidate is "My Documents" (e.g., bzr uses it). But none of them is really for the user, according to Windows guidelines. > Is %APPDATA% actually a user-visible directory of some sort on XP? Yes. Each user is the owner of her %APPDATA%, and has full access rights. That directory is for applications to put their per-user data. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 13:11:52 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 18:11:52 +0000 Received: from localhost ([127.0.0.1]:57231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TasIZ-0007s8-W9 for submit@debbugs.gnu.org; Tue, 20 Nov 2012 13:11:52 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:39007) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TasIX-0007s0-CB for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 13:11:50 -0500 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAKIAaMe010798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Nov 2012 18:10:37 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAKIAand017128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2012 18:10:36 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAKIAZiP021268; Tue, 20 Nov 2012 12:10:35 -0600 Received: from dradamslap1 (/10.159.225.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Nov 2012 10:10:35 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <83ip90w48g.fsf@gnu.org> Subject: RE: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written Date: Tue, 20 Nov 2012 10:10:30 -0800 Message-ID: <4AB1E6AB8BB448AAB037D70CBECBFD9D@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83ip90w48g.fsf@gnu.org> Thread-Index: Ac3HSAbXMibR4CYYTciEDkmECIrJqAAARnuQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 12911 Cc: lekktu@gmail.com, 12911@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > > I sent an emacs-backtrace.txt file recently > > Where? I must have missed that, or maybe forgot. The first mail that started this discussion: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12908 This is the exchange we had about it: EZ>>>> Users should include it with their bug reports. DA>>> DA>>> Does my having included it in this bug report help in some DA>>> way? I'm guessing no, but would love to be shown wrong. EZ>> EZ>> Your guess is wrong, that file includes enough information EZ>> to understand where the crash happened, and in some cases EZ>> also why. DA> DA> That's good news. Let's hope it helps fix some of the DA> crashing problems. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 13:29:13 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 18:29:13 +0000 Received: from localhost ([127.0.0.1]:57248 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TasZM-0008HF-PV for submit@debbugs.gnu.org; Tue, 20 Nov 2012 13:29:13 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:37774) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TasZJ-0008H6-2x for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 13:29:10 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDS00800TYF9F00@a-mtaout20.012.net.il> for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 20:27:57 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDS007WJTYKRWC0@a-mtaout20.012.net.il>; Tue, 20 Nov 2012 20:27:57 +0200 (IST) Date: Tue, 20 Nov 2012 20:27:37 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written In-reply-to: <4AB1E6AB8BB448AAB037D70CBECBFD9D@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams , Dani Moncayo Message-id: <83d2z8w2na.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <83ip90w48g.fsf@gnu.org> <4AB1E6AB8BB448AAB037D70CBECBFD9D@us.oracle.com> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12911 Cc: lekktu@gmail.com, 12911@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Cc: , , <12911@debbugs.gnu.org> > Date: Tue, 20 Nov 2012 10:10:30 -0800 > > > > I sent an emacs-backtrace.txt file recently > > > > Where? I must have missed that, or maybe forgot. > > The first mail that started this discussion: > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12908 Thanks. Dani, where can I find the binary which fits this: In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) of 2012-11-05 on MS-W7-DANI Bzr revision: 110809 lekktu gmail.com-20121105172930-a5gn0bwi4lndchhw Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.7) --no-opt --enable-checking --cflags -I../../libs/libXpm-3.5.10/include -I../../libs/libXpm-3.5.10/src -I../../libs/libpng-1.2.37-lib/include -I../../libs/zlib-1.2.5 -I../../libs/giflib-4.1.4-1-lib/include -I../../libs/jpeg-6b-4-lib/include -I../../libs/tiff-3.8.2-1-lib/include -I../../libs/libxml2-2.7.8-w32-bin/include/libxml2 -I../../libs/gnutls-3.0.9-w32-bin/include -I../../libs/libiconv-1.9.2-1-lib/include' Or maybe you (Dani) can run addr2line on that binary and tell what you get from Drew's backtraces. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 13:32:09 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 18:32:09 +0000 Received: from localhost ([127.0.0.1]:57255 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TascD-0008MK-HS for submit@debbugs.gnu.org; Tue, 20 Nov 2012 13:32:09 -0500 Received: from chene.dit.umontreal.ca ([132.204.246.20]:54292) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TascA-0008M1-0o for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 13:32:07 -0500 Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id qAKIUr9i028727; Tue, 20 Nov 2012 13:30:53 -0500 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id EC8C5B4278; Tue, 20 Nov 2012 13:30:52 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Message-ID: References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> <83r4now6jk.fsf@gnu.org> Date: Tue, 20 Nov 2012 13:30:52 -0500 In-Reply-To: <83r4now6jk.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 20 Nov 2012 19:03:27 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4408=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4408> : streams <862304> : uri <1272927> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12911 Cc: Daniel Colascione , 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.9 (---) > Accessing environment variables is another problematic place. We are > crashing, so the heap or the whole arena can be trashed. Who can be > sure the environment variables will not point to garbled places? Just to put things in perspective: this backtrace "feature" was put in to replace/supplement the previous assertion failure output (because with asserts now being inside inlinable functions, the line&file info we get is not the one we want any more). So the environment is usually still pretty sane, because assertions are usually caught fairly early. Of course, there will be cases where the process is sufficiently botched up that we can't build the file name ~/.emacs.d/backtrace.txt, while we might still be able to just use "backtrace.txt" successfully, but I don't think those borderline cases are sufficiently common to be worry about them. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 13:38:52 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 18:38:52 +0000 Received: from localhost ([127.0.0.1]:57264 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tasih-0008VT-RY for submit@debbugs.gnu.org; Tue, 20 Nov 2012 13:38:52 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:48034) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tasie-0008VK-Vp for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 13:38:49 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MDS00700U046U00@a-mtaout22.012.net.il> for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 20:37:37 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDS007FJUEN4530@a-mtaout22.012.net.il>; Tue, 20 Nov 2012 20:37:35 +0200 (IST) Date: Tue, 20 Nov 2012 20:37:15 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83a9ucw278.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> <83r4now6jk.fsf@gnu.org> X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 12911 Cc: dancol@dancol.org, 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: Daniel Colascione , 12911@debbugs.gnu.org > Date: Tue, 20 Nov 2012 13:30:52 -0500 > > > Accessing environment variables is another problematic place. We are > > crashing, so the heap or the whole arena can be trashed. Who can be > > sure the environment variables will not point to garbled places? > > Just to put things in perspective: this backtrace "feature" was put in > to replace/supplement the previous assertion failure output (because > with asserts now being inside inlinable functions, the line&file info > we get is not the one we want any more). So the environment is usually > still pretty sane, because assertions are usually caught fairly early. If the backtrace is created due to assertion violation, yes. But it is also invoked for all the other fatal signals. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 13:58:29 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 18:58:29 +0000 Received: from localhost ([127.0.0.1]:57295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tat1g-0000Ww-Qw for submit@debbugs.gnu.org; Tue, 20 Nov 2012 13:58:29 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:46795) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tat1e-0000Wo-D6 for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 13:58:27 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAKIv7cx021516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Nov 2012 18:57:08 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAKIv51o003706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2012 18:57:06 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAKIv5tv024358; Tue, 20 Nov 2012 12:57:05 -0600 Received: from dradamslap1 (/10.159.225.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Nov 2012 10:57:05 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" , "'Daniel Colascione'" References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org><50AB0EDE.40109@dancol.org> <83r4now6jk.fsf@gnu.org><50ABBFA4.6080402@dancol.org> <83haokw3ss.fsf@gnu.org> Subject: RE: bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' files are written Date: Tue, 20 Nov 2012 10:57:00 -0800 Message-ID: <5CBDAE291F7447E8834BD7E61FF36B8A@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83haokw3ss.fsf@gnu.org> Thread-Index: Ac3HSXAMAZDt2zNHR4Wjk6F69krCDQABCcbQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Yet another candidate is "My Documents" (e.g., bzr uses > it). But none of them is really for the user, according to Windows > guidelines. Really? I don't know (or care too much) what Windows guidelines might say about this. But I would be mildly curious about that, if you happen to have a URL. Everyone I know considers `My Documents' and its subfolders to be a user folder - maybe even *THE* user folder par excellence. There is even a `My Documents' folder for each user defined for the machine. (Another name for it can be Administrator's Documents, Drew's Documents, Eli's Documents. etc.) Pretty clear to me that this intended to separate one users documents from those of another user, as well as from non-user documents. Why any program (e.g. bzr, apparently) would want to consider that folder as fair game for stuffing its internal stuff is beyond me. How impolite. Anyway, let's see what good ol' Wikipedia has to say... http://en.wikipedia.org/wiki/My_Documents My Documents is the name of a special folder on the computer's hard drive that the system commonly uses to store a user's documents, music, pictures, downloads, and other files. Whaddya know? And it says `My Documents' was introduced, "as a standard location for storing user-created files." Hm. That all sounds just like what I think about it. And about its subfolders, including `My Music',... That "My" should tell us something, I would think. `My Documents' is not the kind of place a civilized program would want to pollute with its own crap. Now of course, installing a program might well create a subfolder under `My Documents' that is intended for user-created data that is specific to that program - e.g. music files you save. Nothing wrong with that. That is not the same as a place to stuff program-internal data. We have `Program Files' and user-specific `Local Settings\Application Data' for that kind of thing. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 14:16:28 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 19:16:28 +0000 Received: from localhost ([127.0.0.1]:57309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TatJ5-0001nq-Jj for submit@debbugs.gnu.org; Tue, 20 Nov 2012 14:16:28 -0500 Received: from mail-ee0-f44.google.com ([74.125.83.44]:60708) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TatJ1-0001nh-5m for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 14:16:25 -0500 Received: by mail-ee0-f44.google.com with SMTP id b47so4004711eek.3 for <12911@debbugs.gnu.org>; Tue, 20 Nov 2012 11:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RzHmrIQkIJiqzBgocOy6Qup5sHXwXX7xNXir7skfSNQ=; b=EJoYTvH7ia3xVigVLKwI8qAziChXH50nDBZaibGhKPh8i/rYIrWLxC1cUGljV5wXhV BlgWNXCdY2zUh2uJH5IcbcXfq5xb6Phbb1W7xviKONBo2UEJ99o6o30MeCR/4x9bh3LR 84I5QcnX9qOrMCcVktp825ED4l9YBIPLdDFspO4urLBjsdO5a/92F3n1LA291g6Utntk xkeQtCHqeWyOEa1dGs1zy9JxZc3ehRAnBY/vhs6uMIKRDPaPyUlse9KU0AFuEz/hHKPN +KtyJqFwvamSOftVQfPPpYj898u0gTqsOZSYEOM/NSBQQSln8asi0O3MdYI6fOVodJD7 rMbw== MIME-Version: 1.0 Received: by 10.14.223.4 with SMTP id u4mr36380051eep.19.1353438910404; Tue, 20 Nov 2012 11:15:10 -0800 (PST) Received: by 10.14.123.84 with HTTP; Tue, 20 Nov 2012 11:15:10 -0800 (PST) In-Reply-To: <83d2z8w2na.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <83ip90w48g.fsf@gnu.org> <4AB1E6AB8BB448AAB037D70CBECBFD9D@us.oracle.com> <83d2z8w2na.fsf@gnu.org> Date: Tue, 20 Nov 2012 20:15:10 +0100 Message-ID: Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written From: Dani Moncayo To: Eli Zaretskii Content-Type: multipart/mixed; boundary=047d7b6707277ad7ed04cef20d99 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 12911 Cc: lekktu@gmail.com, 12911@debbugs.gnu.org, monnier@iro.umontreal.ca, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --047d7b6707277ad7ed04cef20d99 Content-Type: text/plain; charset=ISO-8859-1 >> > > I sent an emacs-backtrace.txt file recently >> > >> > Where? I must have missed that, or maybe forgot. >> >> The first mail that started this discussion: >> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12908 > > Thanks. > > Dani, where can I find the binary which fits this: (I've caught this by chance - I was not in the "to" or the "cc") You can get the binary from https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8 The file to pick up is obvious looking at the revno (110809). > In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) > of 2012-11-05 on MS-W7-DANI > Bzr revision: 110809 lekktu gmail.com-20121105172930-a5gn0bwi4lndchhw > Windowing system distributor `Microsoft Corp.', version 5.1.2600 > Configured using: > `configure --with-gcc (4.7) --no-opt --enable-checking --cflags > -I../../libs/libXpm-3.5.10/include -I../../libs/libXpm-3.5.10/src > -I../../libs/libpng-1.2.37-lib/include -I../../libs/zlib-1.2.5 > -I../../libs/giflib-4.1.4-1-lib/include > -I../../libs/jpeg-6b-4-lib/include > -I../../libs/tiff-3.8.2-1-lib/include > -I../../libs/libxml2-2.7.8-w32-bin/include/libxml2 > -I../../libs/gnutls-3.0.9-w32-bin/include > -I../../libs/libiconv-1.9.2-1-lib/include' > > Or maybe you (Dani) can run addr2line on that binary and tell what you > get from Drew's backtraces. I'm never done that, but I've tried it: addr2line -e emacs.exe < bt-in.txt > bt-out.txt where the "emacs.exe" is the one from the build used by Drew. I'm attaching both files. HTH. -- Dani Moncayo --047d7b6707277ad7ed04cef20d99 Content-Type: text/plain; charset=US-ASCII; name="bt-in.txt" Content-Disposition: attachment; filename="bt-in.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h9reh6920 QmFja3RyYWNlOgoweDAxMTU0NzBECjB4MDExNTQ3N0YKMHgwMTAwMTQ1OQoweDAxMDIxQTA3CjB4 MDEyMDcyQjgKMHgwMTIwODBCOQoweDAxMDNCNTRGCjB4MDEwNEYxNEIKMHgwMTAzODg3OAoweDAx MDEwRURFCjB4MDEwMzgwMEIKMHgwMTAxMDkzQgoweDAxMDM3RkM1CjB4MDEwMzc1N0YKMHgwMTAz NzhBQwoweDAxMDAyOUFCCjB4MDEwMDEwRjkKMHg3QzgxNzA3MwogCkJhY2t0cmFjZToKMHgwMTE1 NDcwRAoweDAxMTU0NzdGCjB4MDEwMDE0NTkKMHgwMTAyMUEwNwoweDAxMDYzRTQwCjB4MDEwMDMw RkYKMHgwMTAwMTQxMQoweDAxMDIxQTA3CjB4MDEyMDhCNkYKMHgwMTIwNkZBMAoweDAxMjAzRDc0 CjB4MDEwM0I1NTYKMHgwMTA0RjE0QgoweDAxMDM4ODc4CjB4MDEwMTBFREUKMHgwMTAzODAwQgow eDAxMDEwOTNCCjB4MDEwMzdGQzUKMHgwMTAzNzU3RgoweDAxMDM3OEFDCjB4MDEwMDI5QUIKMHgw MTAwMTBGOQoweDdDODE3MDczCiAKQmFja3RyYWNlOgoweDAxMTU0NzBECjB4MDExNTQ3N0YKMHgw MTAwMTQ1OQoweDAxMTQ0RDRGCjB4MDExNDREMkEKMHgwMTE0NEQ4MwoweDAxMDAxMUU2CjB4N0M4 NDM4RjYKIApCYWNrdHJhY2U6CjB4MDExNTQ3MEQKMHgwMTE1NDc3RgoweDAxMDAxNDU5CjB4MDEx NDRENEYKMHgwMTE0NEQyQQoweDAxMTQ0RDgzCjB4MDEwMDExRTYKMHg3Qzg0MzhGNgogCkJhY2t0 cmFjZToKMHgwMTE1NDcwRAoweDAxMTU0NzdGCjB4MDEwMDE0NTkKMHgwMTAyMUEwNwoweDAxMDYz RTQwCjB4MDEwMDMwRkYKMHgwMTAwMTQxMQoweDAxMDIxQTA3CjB4MDEyNzE5ODcKMHgwMTI3NTND RgoweDAxMjAxMzM0CjB4MDEyMDI0MTAKMHgwMTIxMTYwRAoweDAxMjA4QzE0CjB4MDEwMTBGQzYK MHgwMTIwOEJBMQoweDAxMjA2RkEwCjB4MDEyMDNENzQKMHgwMTAzQjU1NgoweDAxMDRGMTRCCjB4 MDEwMzg4NzgKMHgwMTAxMEVERQoweDAxMDM4MDBCCjB4MDEwMTA5M0IKMHgwMTAzN0ZDNQoweDAx MDM3NTdGCjB4MDEwMzc4QUMKMHgwMTAwMjlBQgoweDAxMDAxMEY5CjB4N0M4MTcwNzMKIApCYWNr dHJhY2U6CjB4MDExNTQ3MEQKMHgwMTE1NDc3RgoweDAxMDAxNDU5CjB4MDEwMjFBMDcKMHgwMTBF RkVFQQoweDAxMEY2QTY4CjB4MDEwRjUyMDgKMHgwMTBGNDhGNAoweDAxMEY0NjE2CjB4MDEyMDcx MEUKMHgwMTIwM0Q3NAoweDAxMDNCNTU2CjB4MDEwNEYxNEIKMHgwMTAzODg3OAoweDAxMDEwRURF CjB4MDEwMzgwMEIKMHgwMTAxMDkzQgoweDAxMDM3RkM1CjB4MDEwMzc1N0YKMHgwMTAzNzhBQwow eDAxMDAyOUFCCjB4MDEwMDEwRjkKMHg3QzgxNzA3MwogCkJhY2t0cmFjZToKMHgwMTE1NDcwRAow eDAxMTU0NzdGCjB4MDEwMDE0NTkKMHgwMTE0NEQ0RgoweDAxMTQ0RDJBCjB4MDExNDREODMKMHgw MTAwMTFFNgoweDdDODQzOEY2CiAKQmFja3RyYWNlOgoweDAxMTU0NzBECjB4MDExNTQ3N0YKMHgw MTAwMTQ1OQoweDAxMDIxQTA3CjB4MDEyRDMyRDMKMHgwMTAxNEY2NAoweDAxMEUxMTdGCjB4MDEw MTVFN0UKMHgwMTAxNTMxNwoweDAxMEUxMTdGCjB4MDEwMTVFN0UKMHgwMTAxNTMxNwoweDAxMEUx MTdGCjB4MDEwMTVFN0UKMHgwMTAxNTMxNwoweDAxMEUxMTdGCjB4MDEwMTVFN0UKMHgwMTAxNTMx NwoweDAxMEU2QzFDCjB4MDEwMTRGRDUKMHgwMTAxNDczMwoweDAxMDUyQzU1CjB4MDEwMzkwQzcK MHgwMTAxMEVERQoweDAxMDM4MDBCCjB4MDEwMTA5M0IKMHgwMTAzN0ZDNQoweDAxMDM3NTdGCjB4 MDEwMzc4QUMKMHgwMTAwMjlBQgoweDAxMDAxMEY5CjB4N0M4MTcwNzMK --047d7b6707277ad7ed04cef20d99 Content-Type: text/plain; charset=US-ASCII; name="bt-out.txt" Content-Disposition: attachment; filename="bt-out.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h9reh69c1 Pz86MA0KYzpcZW1hY3NcdHJ1bmtcc3JjL3czMmZucy5jOjc3MTcNCmM6XGVtYWNzXHRydW5rXHNy Yy93MzJmbnMuYzo3NzQ5DQpjOlxlbWFjc1x0cnVua1xzcmMvZW1hY3MuYzozNDUNCmM6XGVtYWNz XHRydW5rXHNyYy9hbGxvYy5jOjY0NDANCmM6XGVtYWNzXHRydW5rXHNyYy94ZGlzcC5jOjEzNTQw DQpjOlxlbWFjc1x0cnVua1xzcmMveGRpc3AuYzoxMzc0OA0KYzpcZW1hY3NcdHJ1bmtcc3JjL2tl eWJvYXJkLmM6MjQyNg0KYzpcZW1hY3NcdHJ1bmtcc3JjL2tleWJvYXJkLmM6OTIyMw0KYzpcZW1h Y3NcdHJ1bmtcc3JjL2tleWJvYXJkLmM6MTQ1OA0KYzpcZW1hY3NcdHJ1bmtcc3JjL2V2YWwuYzox Mjg4DQpjOlxlbWFjc1x0cnVua1xzcmMva2V5Ym9hcmQuYzoxMTY3DQpjOlxlbWFjc1x0cnVua1xz cmMvZXZhbC5jOjEwNTkNCmM6XGVtYWNzXHRydW5rXHNyYy9rZXlib2FyZC5jOjExNDYNCmM6XGVt YWNzXHRydW5rXHNyYy9rZXlib2FyZC5jOjc3OA0KYzpcZW1hY3NcdHJ1bmtcc3JjL2tleWJvYXJk LmM6ODQyDQpjOlxlbWFjc1x0cnVua1xzcmMvZW1hY3MuYzoxNTY0DQpjcnQxLmM6MA0KPz86MA0K Pz86MA0KPz86MA0KYzpcZW1hY3NcdHJ1bmtcc3JjL3czMmZucy5jOjc3MTcNCmM6XGVtYWNzXHRy dW5rXHNyYy93MzJmbnMuYzo3NzQ5DQpjOlxlbWFjc1x0cnVua1xzcmMvZW1hY3MuYzozNDUNCmM6 XGVtYWNzXHRydW5rXHNyYy9hbGxvYy5jOjY0NDANCmM6XGVtYWNzXHRydW5rXHNyYy9maWxlaW8u Yzo1MzgwDQpjOlxlbWFjc1x0cnVua1xzcmMvZW1hY3MuYzoxOTQxDQpjOlxlbWFjc1x0cnVua1xz cmMvZW1hY3MuYzozMjkNCmM6XGVtYWNzXHRydW5rXHNyYy9hbGxvYy5jOjY0NDANCmM6XGVtYWNz XHRydW5rXHNyYy94ZGlzcC5jOjEzOTA5DQpjOlxlbWFjc1x0cnVua1xzcmMveGRpc3AuYzoxMzQ5 MQ0KYzpcZW1hY3NcdHJ1bmtcc3JjL3hkaXNwLmM6MTI2OTENCmM6XGVtYWNzXHRydW5rXHNyYy9r ZXlib2FyZC5jOjI0MjgNCmM6XGVtYWNzXHRydW5rXHNyYy9rZXlib2FyZC5jOjkyMjMNCmM6XGVt YWNzXHRydW5rXHNyYy9rZXlib2FyZC5jOjE0NTgNCmM6XGVtYWNzXHRydW5rXHNyYy9ldmFsLmM6 MTI4OA0KYzpcZW1hY3NcdHJ1bmtcc3JjL2tleWJvYXJkLmM6MTE2Nw0KYzpcZW1hY3NcdHJ1bmtc c3JjL2V2YWwuYzoxMDU5DQpjOlxlbWFjc1x0cnVua1xzcmMva2V5Ym9hcmQuYzoxMTQ2DQpjOlxl bWFjc1x0cnVua1xzcmMva2V5Ym9hcmQuYzo3NzgNCmM6XGVtYWNzXHRydW5rXHNyYy9rZXlib2Fy ZC5jOjg0Mg0KYzpcZW1hY3NcdHJ1bmtcc3JjL2VtYWNzLmM6MTU2NA0KY3J0MS5jOjANCj8/OjAN Cj8/OjANCj8/OjANCmM6XGVtYWNzXHRydW5rXHNyYy93MzJmbnMuYzo3NzE3DQpjOlxlbWFjc1x0 cnVua1xzcmMvdzMyZm5zLmM6Nzc0OQ0KYzpcZW1hY3NcdHJ1bmtcc3JjL2VtYWNzLmM6MzQ1DQpj OlxlbWFjc1x0cnVua1xzcmMvc3lzZGVwLmM6MTYzOA0KYzpcZW1hY3NcdHJ1bmtcc3JjL3N5c2Rl cC5jOjE2MTQNCmM6XGVtYWNzXHRydW5rXHNyYy9zeXNkZXAuYzoxNjUwDQpjcnQxLmM6MA0KPz86 MA0KPz86MA0KPz86MA0KYzpcZW1hY3NcdHJ1bmtcc3JjL3czMmZucy5jOjc3MTcNCmM6XGVtYWNz XHRydW5rXHNyYy93MzJmbnMuYzo3NzQ5DQpjOlxlbWFjc1x0cnVua1xzcmMvZW1hY3MuYzozNDUN CmM6XGVtYWNzXHRydW5rXHNyYy9zeXNkZXAuYzoxNjM4DQpjOlxlbWFjc1x0cnVua1xzcmMvc3lz ZGVwLmM6MTYxNA0KYzpcZW1hY3NcdHJ1bmtcc3JjL3N5c2RlcC5jOjE2NTANCmNydDEuYzowDQo/ PzowDQo/PzowDQo/PzowDQpjOlxlbWFjc1x0cnVua1xzcmMvdzMyZm5zLmM6NzcxNw0KYzpcZW1h Y3NcdHJ1bmtcc3JjL3czMmZucy5jOjc3NDkNCmM6XGVtYWNzXHRydW5rXHNyYy9lbWFjcy5jOjM0 NQ0KYzpcZW1hY3NcdHJ1bmtcc3JjL2FsbG9jLmM6NjQ0MA0KYzpcZW1hY3NcdHJ1bmtcc3JjL2Zp bGVpby5jOjUzODANCmM6XGVtYWNzXHRydW5rXHNyYy9lbWFjcy5jOjE5NDENCmM6XGVtYWNzXHRy dW5rXHNyYy9lbWFjcy5jOjMyOQ0KYzpcZW1hY3NcdHJ1bmtcc3JjL2FsbG9jLmM6NjQ0MA0KYzpc ZW1hY3NcdHJ1bmtcc3JjL3RleHRwcm9wLmM6NDY3DQpjOlxlbWFjc1x0cnVua1xzcmMvdGV4dHBy b3AuYzoxNDg3DQpjOlxlbWFjc1x0cnVua1xzcmMveGRpc3AuYzoxMTYxMw0KYzpcZW1hY3NcdHJ1 bmtcc3JjL3hkaXNwLmM6MTE5ODANCmM6XGVtYWNzXHRydW5rXHNyYy94ZGlzcC5jOjE2MjQ2DQpj OlxlbWFjc1x0cnVua1xzcmMveGRpc3AuYzoxMzkzMg0KYzpcZW1hY3NcdHJ1bmtcc3JjL2V2YWwu YzoxMzI2DQpjOlxlbWFjc1x0cnVua1xzcmMveGRpc3AuYzoxMzkxMg0KYzpcZW1hY3NcdHJ1bmtc c3JjL3hkaXNwLmM6MTM0OTENCmM6XGVtYWNzXHRydW5rXHNyYy94ZGlzcC5jOjEyNjkxDQpjOlxl bWFjc1x0cnVua1xzcmMva2V5Ym9hcmQuYzoyNDI4DQpjOlxlbWFjc1x0cnVua1xzcmMva2V5Ym9h cmQuYzo5MjIzDQpjOlxlbWFjc1x0cnVua1xzcmMva2V5Ym9hcmQuYzoxNDU4DQpjOlxlbWFjc1x0 cnVua1xzcmMvZXZhbC5jOjEyODgNCmM6XGVtYWNzXHRydW5rXHNyYy9rZXlib2FyZC5jOjExNjcN CmM6XGVtYWNzXHRydW5rXHNyYy9ldmFsLmM6MTA1OQ0KYzpcZW1hY3NcdHJ1bmtcc3JjL2tleWJv YXJkLmM6MTE0Ng0KYzpcZW1hY3NcdHJ1bmtcc3JjL2tleWJvYXJkLmM6Nzc4DQpjOlxlbWFjc1x0 cnVua1xzcmMva2V5Ym9hcmQuYzo4NDINCmM6XGVtYWNzXHRydW5rXHNyYy9lbWFjcy5jOjE1NjQN CmNydDEuYzowDQo/PzowDQo/PzowDQo/PzowDQpjOlxlbWFjc1x0cnVua1xzcmMvdzMyZm5zLmM6 NzcxNw0KYzpcZW1hY3NcdHJ1bmtcc3JjL3czMmZucy5jOjc3NDkNCmM6XGVtYWNzXHRydW5rXHNy Yy9lbWFjcy5jOjM0NQ0KYzpcZW1hY3NcdHJ1bmtcc3JjL2FsbG9jLmM6NjQ0MA0KYzpcZW1hY3Nc dHJ1bmtcc3JjL2Rpc3BuZXcuYzoxMjU3DQpjOlxlbWFjc1x0cnVua1xzcmMvZGlzcG5ldy5jOjQy MzkNCmM6XGVtYWNzXHRydW5rXHNyYy9kaXNwbmV3LmM6MzUzMg0KYzpcZW1hY3NcdHJ1bmtcc3Jj L2Rpc3BuZXcuYzozMjg0DQpjOlxlbWFjc1x0cnVua1xzcmMvZGlzcG5ldy5jOjMyMTMNCmM6XGVt YWNzXHRydW5rXHNyYy94ZGlzcC5jOjEzNTI4DQpjOlxlbWFjc1x0cnVua1xzcmMveGRpc3AuYzox MjY5MQ0KYzpcZW1hY3NcdHJ1bmtcc3JjL2tleWJvYXJkLmM6MjQyOA0KYzpcZW1hY3NcdHJ1bmtc c3JjL2tleWJvYXJkLmM6OTIyMw0KYzpcZW1hY3NcdHJ1bmtcc3JjL2tleWJvYXJkLmM6MTQ1OA0K YzpcZW1hY3NcdHJ1bmtcc3JjL2V2YWwuYzoxMjg4DQpjOlxlbWFjc1x0cnVua1xzcmMva2V5Ym9h cmQuYzoxMTY3DQpjOlxlbWFjc1x0cnVua1xzcmMvZXZhbC5jOjEwNTkNCmM6XGVtYWNzXHRydW5r XHNyYy9rZXlib2FyZC5jOjExNDYNCmM6XGVtYWNzXHRydW5rXHNyYy9rZXlib2FyZC5jOjc3OA0K YzpcZW1hY3NcdHJ1bmtcc3JjL2tleWJvYXJkLmM6ODQyDQpjOlxlbWFjc1x0cnVua1xzcmMvZW1h Y3MuYzoxNTY0DQpjcnQxLmM6MA0KPz86MA0KPz86MA0KPz86MA0KYzpcZW1hY3NcdHJ1bmtcc3Jj L3czMmZucy5jOjc3MTcNCmM6XGVtYWNzXHRydW5rXHNyYy93MzJmbnMuYzo3NzQ5DQpjOlxlbWFj c1x0cnVua1xzcmMvZW1hY3MuYzozNDUNCmM6XGVtYWNzXHRydW5rXHNyYy9zeXNkZXAuYzoxNjM4 DQpjOlxlbWFjc1x0cnVua1xzcmMvc3lzZGVwLmM6MTYxNA0KYzpcZW1hY3NcdHJ1bmtcc3JjL3N5 c2RlcC5jOjE2NTANCmNydDEuYzowDQo/PzowDQo/PzowDQo/PzowDQpjOlxlbWFjc1x0cnVua1xz cmMvdzMyZm5zLmM6NzcxNw0KYzpcZW1hY3NcdHJ1bmtcc3JjL3czMmZucy5jOjc3NDkNCmM6XGVt YWNzXHRydW5rXHNyYy9lbWFjcy5jOjM0NQ0KYzpcZW1hY3NcdHJ1bmtcc3JjL2FsbG9jLmM6NjQ0 MA0KYzpcZW1hY3NcdHJ1bmtcc3JjL2ZvbnRzZXQuYzoxOTk5DQpjOlxlbWFjc1x0cnVua1xzcmMv ZXZhbC5jOjI3NzcNCmM6XGVtYWNzXHRydW5rXHNyYy9ieXRlY29kZS5jOjg5OQ0KYzpcZW1hY3Nc dHJ1bmtcc3JjL2V2YWwuYzozMDA2DQpjOlxlbWFjc1x0cnVua1xzcmMvZXZhbC5jOjI4MjMNCmM6 XGVtYWNzXHRydW5rXHNyYy9ieXRlY29kZS5jOjg5OQ0KYzpcZW1hY3NcdHJ1bmtcc3JjL2V2YWwu YzozMDA2DQpjOlxlbWFjc1x0cnVua1xzcmMvZXZhbC5jOjI4MjMNCmM6XGVtYWNzXHRydW5rXHNy Yy9ieXRlY29kZS5jOjg5OQ0KYzpcZW1hY3NcdHJ1bmtcc3JjL2V2YWwuYzozMDA2DQpjOlxlbWFj c1x0cnVua1xzcmMvZXZhbC5jOjI4MjMNCmM6XGVtYWNzXHRydW5rXHNyYy9ieXRlY29kZS5jOjg5 OQ0KYzpcZW1hY3NcdHJ1bmtcc3JjL2V2YWwuYzozMDA2DQpjOlxlbWFjc1x0cnVua1xzcmMvZXZh bC5jOjI4MjMNCmM6XGVtYWNzXHRydW5rXHNyYy9jYWxsaW50LmM6ODUyDQpjOlxlbWFjc1x0cnVu a1xzcmMvZXZhbC5jOjI3ODENCmM6XGVtYWNzXHRydW5rXHNyYy9ldmFsLmM6MjU5OQ0KYzpcZW1h Y3NcdHJ1bmtcc3JjL2tleWJvYXJkLmM6MTAyMzMNCmM6XGVtYWNzXHRydW5rXHNyYy9rZXlib2Fy ZC5jOjE1ODYNCmM6XGVtYWNzXHRydW5rXHNyYy9ldmFsLmM6MTI4OA0KYzpcZW1hY3NcdHJ1bmtc c3JjL2tleWJvYXJkLmM6MTE2Nw0KYzpcZW1hY3NcdHJ1bmtcc3JjL2V2YWwuYzoxMDU5DQpjOlxl bWFjc1x0cnVua1xzcmMva2V5Ym9hcmQuYzoxMTQ2DQpjOlxlbWFjc1x0cnVua1xzcmMva2V5Ym9h cmQuYzo3NzgNCmM6XGVtYWNzXHRydW5rXHNyYy9rZXlib2FyZC5jOjg0Mg0KYzpcZW1hY3NcdHJ1 bmtcc3JjL2VtYWNzLmM6MTU2NA0KY3J0MS5jOjANCj8/OjANCg== --047d7b6707277ad7ed04cef20d99-- From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 14:43:10 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 19:43:10 +0000 Received: from localhost ([127.0.0.1]:57319 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tativ-0002QX-A9 for submit@debbugs.gnu.org; Tue, 20 Nov 2012 14:43:09 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:63947) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tatis-0002QN-Kt for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 14:43:08 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MDS00700X80XY00@a-mtaout22.012.net.il> for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 21:41:54 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDS007O5XDTWP20@a-mtaout22.012.net.il>; Tue, 20 Nov 2012 21:41:54 +0200 (IST) Date: Tue, 20 Nov 2012 21:41:34 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written In-reply-to: X-012-Sender: halo1@inter.net.il To: Dani Moncayo Message-id: <837gpgvz81.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <83ip90w48g.fsf@gnu.org> <4AB1E6AB8BB448AAB037D70CBECBFD9D@us.oracle.com> <83d2z8w2na.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12911 Cc: lekktu@gmail.com, 12911@debbugs.gnu.org, monnier@iro.umontreal.ca, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Tue, 20 Nov 2012 20:15:10 +0100 > From: Dani Moncayo > Cc: Drew Adams , lekktu@gmail.com, monnier@iro.umontreal.ca, > 12911@debbugs.gnu.org > > > Dani, where can I find the binary which fits this: > > (I've caught this by chance - I was not in the "to" or the "cc") ??? Of course you were in "To", take another look. > You can get the binary from > https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8 Thanks. > > Or maybe you (Dani) can run addr2line on that binary and tell what you > > get from Drew's backtraces. > > I'm never done that, but I've tried it: > addr2line -e emacs.exe < bt-in.txt > bt-out.txt > > where the "emacs.exe" is the one from the build used by Drew. I'm > attaching both files. Thanks. Drew, you really should report these, and try cooperating in the resolution of these problems. There are at least 2 crashes here that I never saw. > c:\emacs\trunk\src/w32fns.c:7717 > c:\emacs\trunk\src/w32fns.c:7749 > c:\emacs\trunk\src/emacs.c:345 > c:\emacs\trunk\src/alloc.c:6440 > c:\emacs\trunk\src/xdisp.c:13540 This is assertion violation in redisplay_internal, here: eassert (EQ (XFRAME (selected_frame)->selected_window, selected_window)); This crash is probably of the kind you reported in the past, related to the selected-frame/selected-window issues. > c:\emacs\trunk\src/w32fns.c:7717 > c:\emacs\trunk\src/w32fns.c:7749 > c:\emacs\trunk\src/emacs.c:345 > c:\emacs\trunk\src/alloc.c:6440 > c:\emacs\trunk\src/fileio.c:5380 This is a crash in auto-save, which I never saw before: for (do_handled_files = 0; do_handled_files < 2; do_handled_files++) for (tail = Vbuffer_alist; CONSP (tail); tail = XCDR (tail)) { buf = XCDR (XCAR (tail)); b = XBUFFER (buf); <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > c:\emacs\trunk\src/w32fns.c:7717 > c:\emacs\trunk\src/w32fns.c:7749 > c:\emacs\trunk\src/emacs.c:345 > c:\emacs\trunk\src/alloc.c:6440 > c:\emacs\trunk\src/dispnew.c:1257 Another assertion violation in redisplay: static bool row_equal_p (struct glyph_row *a, struct glyph_row *b, bool mouse_face_p) { eassert (verify_row_hash (a)); eassert (verify_row_hash (b)); <<<<<<<<<<<<<<<<<<<<<<<<<<<<< > c:\emacs\trunk\src/w32fns.c:7717 > c:\emacs\trunk\src/w32fns.c:7749 > c:\emacs\trunk\src/emacs.c:345 > c:\emacs\trunk\src/alloc.c:6440 > c:\emacs\trunk\src/fontset.c:1999 This crash is in fontset-info: /* Then store opened font names to cdr of each elements. */ for (i = 0; ! NILP (realized[k][i]); i++) { if (c <= MAX_5_BYTE_CHAR) val = FONTSET_REF (realized[k][i], c); else val = FONTSET_FALLBACK (realized[k][i]); if (! CONSP (val) || ! VECTORP (XCDR (val))) continue; /* VAL: (int . [[FACE-ID FONT-DEF FONT-OBJECT int] ... ]) */ val = XCDR (val); for (j = 0; j < ASIZE (val); j++) { elt = AREF (val, j); if (FONT_OBJECT_P (RFONT_DEF_OBJECT (elt))) <<<<<<<<< I don't think I've ever heard about such crashes. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 15:00:13 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 20:00:13 +0000 Received: from localhost ([127.0.0.1]:57335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TatzQ-0002op-Pm for submit@debbugs.gnu.org; Tue, 20 Nov 2012 15:00:13 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:60231) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TatzO-0002oh-0H for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 15:00:11 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDS00900Y1W5A00@a-mtaout20.012.net.il> for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 21:58:55 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDS008W1Y66MJB0@a-mtaout20.012.net.il>; Tue, 20 Nov 2012 21:58:55 +0200 (IST) Date: Tue, 20 Nov 2012 21:58:35 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' files are written In-reply-to: <5CBDAE291F7447E8834BD7E61FF36B8A@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <836250vyfo.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> <83r4now6jk.fsf@gnu.org> <50ABBFA4.6080402@dancol.org> <83haokw3ss.fsf@gnu.org> <5CBDAE291F7447E8834BD7E61FF36B8A@us.oracle.com> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, > RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.2 > From: "Drew Adams" > Cc: <12911@debbugs.gnu.org> > Date: Tue, 20 Nov 2012 10:57:00 -0800 > > > Yet another candidate is "My Documents" (e.g., bzr uses > > it). But none of them is really for the user, according to Windows > > guidelines. > > Really? I don't know (or care too much) what Windows guidelines might say about > this. But I would be mildly curious about that, if you happen to have a URL. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12911 Cc: dancol@dancol.org, 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, > RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 > From: "Drew Adams" > Cc: <12911@debbugs.gnu.org> > Date: Tue, 20 Nov 2012 10:57:00 -0800 > > > Yet another candidate is "My Documents" (e.g., bzr uses > > it). But none of them is really for the user, according to Windows > > guidelines. > > Really? I don't know (or care too much) what Windows guidelines might say about > this. But I would be mildly curious about that, if you happen to have a URL. http://msdn.microsoft.com/en-us/library/windows/desktop/bb762494%28v=vs.85%29.aspx > Everyone I know considers `My Documents' and its subfolders to be a user folder > - maybe even *THE* user folder par excellence. "The file system directory used to physically store a user's common repository of documents." What do you make of that? "User's documents", not "user's files". > There is even a `My Documents' folder for each user defined for the machine. > (Another name for it can be Administrator's Documents, Drew's Documents, Eli's > Documents. etc.) Yes, that's the "virtual folder" part in the description on the above URL. But then you also have per-user "Application Data", "Temporary Internet Files", "Favorites", and many more. Being per user does not mean it's up for grabs for any particular purpose. > Why any program (e.g. bzr, apparently) would want to consider that folder as > fair game for stuffing its internal stuff is beyond me. How impolite. Not at all. It is customary, at least on Unix, to put logs, command history, and other similar files in the user's home directory. > Anyway, let's see what good ol' Wikipedia has to say... > http://en.wikipedia.org/wiki/My_Documents > > My Documents is the name of a special folder on the computer's > hard drive that the system commonly uses to store a user's > documents, music, pictures, downloads, and other files. > > Whaddya know? And it says `My Documents' was introduced, "as a standard > location for storing user-created files." Don't believe everything Wikipedia says. > Hm. That all sounds just like what I think about it. And about its subfolders, > including `My Music',... That "My" should tell us something, I would think. Then why did that "My" part disappear in latest Windows versions? There's no C:\Users\\Documents etc., with "My Documents" just a symlink. See http://windows.microsoft.com/is-IS/windows-vista/What-happened-to-My-Documents > `My Documents' is not the kind of place a civilized program would want to > pollute with its own crap. It's _your_ crap, because it's _you_ who runs that program. > That is not the same as a place to stuff program-internal data. We have > `Program Files' and user-specific `Local Settings\Application Data' for that > kind of thing. As I wrote earlier, writing to "Program Files" is a bad idea, as it is not writable in Vista and later. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 15:12:37 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 20:12:37 +0000 Received: from localhost ([127.0.0.1]:57342 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TauBR-000353-7w for submit@debbugs.gnu.org; Tue, 20 Nov 2012 15:12:37 -0500 Received: from mail-ee0-f44.google.com ([74.125.83.44]:50279) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TauBP-00034v-5C for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 15:12:35 -0500 Received: by mail-ee0-f44.google.com with SMTP id b47so4035909eek.3 for <12911@debbugs.gnu.org>; Tue, 20 Nov 2012 12:11:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9i4vfQfYcnnuHK+y4mJY7EM6i1nvFuq3f3K2Z8TIKt4=; b=F6PVE2jKhM19a8+ly5f33MgEFICJ0T9OK9yMznsLuCRsqkL8JuGveXvINmUYGpU4I3 HVxpea7CUh4Kp/m8ttk6KD8IP6Rh1PKGQ/qIUuseXsz22SYL+zOjI8bq+LTkP5XWPcmL PvX8Hn22KOlC1NxaYlU1KNAd4F2q+pSiGHs0ZoVc7yhR4/wyP718+A1v0jqbmn/kL82e GLPZKuyIQaauxwVPtaURhLAC2oMe7f9HJaejRbZZD9BguXvs8RP+qxeHfUucGlvJJQ94 v2PY9AmEVi2YqTKRblYsosjFUY9MzrpfufQhrUhu+XOBPrqLDjPHscnLL5iJRmMaPja0 Kq7Q== MIME-Version: 1.0 Received: by 10.14.207.68 with SMTP id m44mr37046396eeo.40.1353442283572; Tue, 20 Nov 2012 12:11:23 -0800 (PST) Received: by 10.14.123.84 with HTTP; Tue, 20 Nov 2012 12:11:23 -0800 (PST) In-Reply-To: <837gpgvz81.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <83ip90w48g.fsf@gnu.org> <4AB1E6AB8BB448AAB037D70CBECBFD9D@us.oracle.com> <83d2z8w2na.fsf@gnu.org> <837gpgvz81.fsf@gnu.org> Date: Tue, 20 Nov 2012 21:11:23 +0100 Message-ID: Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written From: Dani Moncayo To: Eli Zaretskii Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12911 Cc: lekktu@gmail.com, 12911@debbugs.gnu.org, monnier@iro.umontreal.ca, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) >> > Dani, where can I find the binary which fits this: >> >> (I've caught this by chance - I was not in the "to" or the "cc") > > ??? Of course you were in "To", take another look. Brain fart, sorry. -- Dani Moncayo From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 15:16:19 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 20:16:19 +0000 Received: from localhost ([127.0.0.1]:57352 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TauF0-0003Al-UV for submit@debbugs.gnu.org; Tue, 20 Nov 2012 15:16:19 -0500 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:40167) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TauEy-0003Ac-1q for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 15:16:17 -0500 Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id qAKKF2FQ025377; Tue, 20 Nov 2012 15:15:02 -0500 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 43DACB4278; Tue, 20 Nov 2012 15:15:02 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Message-ID: References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> <83r4now6jk.fsf@gnu.org> <83a9ucw278.fsf@gnu.org> Date: Tue, 20 Nov 2012 15:15:02 -0500 In-Reply-To: <83a9ucw278.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 20 Nov 2012 20:37:15 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4408=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4408> : streams <862350> : uri <1272990> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12911 Cc: dancol@dancol.org, 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.9 (---) >> > Accessing environment variables is another problematic place. We are >> > crashing, so the heap or the whole arena can be trashed. Who can be >> > sure the environment variables will not point to garbled places? >> Just to put things in perspective: this backtrace "feature" was put in >> to replace/supplement the previous assertion failure output (because >> with asserts now being inside inlinable functions, the line&file info >> we get is not the one we want any more). So the environment is usually >> still pretty sane, because assertions are usually caught fairly early. > If the backtrace is created due to assertion violation, yes. But it > is also invoked for all the other fatal signals. Yes, but the only case I care about is the assertion violation. The other cases have never generated any useful output in the past anyway and nobody complained abut that. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 16:49:07 2012 Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 21:49:07 +0000 Received: from localhost ([127.0.0.1]:57472 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tavgo-0005Jf-DI for submit@debbugs.gnu.org; Tue, 20 Nov 2012 16:49:06 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:33064) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tavgm-0005JU-33 for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 16:49:05 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAKLliF6010643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Nov 2012 21:47:45 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAKLliHr001015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2012 21:47:44 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAKLlhhm013876; Tue, 20 Nov 2012 15:47:43 -0600 Received: from dradamslap1 (/10.159.225.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Nov 2012 13:47:43 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> <83r4now6jk.fsf@gnu.org> <50ABBFA4.6080402@dancol.org> <83haokw3ss.fsf@gnu.org> <5CBDAE291F7447E8834BD7E61FF36B8A@us.oracle.com> <836250vyfo.fsf@gnu.org> Subject: RE: bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' files are written Date: Tue, 20 Nov 2012 13:47:38 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <836250vyfo.fsf@gnu.org> Thread-Index: Ac3HWXyYD+c3jlcdTXezPrmoDv7mjgABIx2A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 12911 Cc: dancol@dancol.org, 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) > "The file system directory used to physically store a user's common > repository of documents." What do you make of that? "User's > documents", not "user's files". A distinction without a meaning, in the present context. Trouncing user stuff is a no-no, whether that stuff is "documents" or files. The distinction that matters here is user vs application. The distinction between documents and files is a red herring, unless I'm missing something. > Yes, that's the "virtual folder" part in the description on the above > URL. But then you also have per-user "Application Data", "Temporary > Internet Files", "Favorites", and many more. Being per user does not > mean it's up for grabs for any particular purpose. I'm certainly not arguing that `My Documents' should be up for grabs by a program for any particular purpose. Far from it. Well behaved programs store user-specific internal data in places like `Application Data', NOT in `My Documents'. User-specific program data is not the same thing as user data. You do not seem to want to recognize any difference between a user's photo of his grandmother and a cache file used by a program to optimize access to that photo. (Hint: the user cares about Grandma; s?he does not care about the cache.) Why such a refusal to admit the obvious? Is this about arguing and winning an argument, or is it about progressing toward a solution? You seem to want to emphasize the continuum and shades of gray, whose existence no one would dispute, as an excuse not to recognize any distinction at all between the ends of the spectrum. (It's all connected; each electron is spread out and penetrates the entire universe. All is o n e.) It is not all the same. Red is not blue, even if there is a continuum of wavelengths. A program keeping to itself and its internal program thingies is more likely to be well behaved than one that refuses to recognize any difference between itself and the user. > Not at all. It is customary, at least on Unix, to put logs, > command history, and other similar files in the user's home > directory. Yes, and it is just as customary, or at least likely, that Unix user Eunice will put her documents/files in specific subdirectories under $HOME, and not just sprinkle them at the top level of $HOME. (Not to mention the custom/handling (e.g. by listing programs, shell, and various commands) of "hidden" dot files. All is not equal, even on Unix.) Argue this as you might for Unix, it is certainly the case on MS Windows, at least, that it is customary for users NOT to mix their own documents/files in with system data or application data. And it is just as customary for applications not to mix their data with user documents/files. It's hard for me to believe this is even a point open to debate. > Don't believe everything Wikipedia says. You don't seem to want to believe your own eyes. The existence of green does not prove that red is blue. > Then why did that "My" part disappear in latest Windows versions? > There's no C:\Users\\Documents etc., with "My Documents" > just a symlink. > http://windows.microsoft.com/is-IS/windows-vista/What-happened-to-My-Documents Irrelevant. (And you could have learned the same thing if you had read the Wikipedia entry I cited, BTW.) > > `My Documents' is not the kind of place a civilized program > > would want to pollute with its own crap. > > It's _your_ crap, because it's _you_ who runs that program. There you go again. That, I guess, is your core argument: it's all o n e. Sorry, I reject that argument entirely. I won't repeat the reasons, unless you really want me to. Red is not blue. User-specific app data is not the same thing as user data. Your program is not Eunice User, even if Eunice chooses to use your program. Sure, if you ask her whether you can put your stuff in her folder, and she says yes, then things are a bit different. Then we're talking mutual consent, not violation. ;-) The question is what Emacs can do to minimize intrusion/annoyance. Perhaps you'd prefer an opt-in EUA that Eunice must acknowledge in order to use Emacs, and containing a provision that Emacs reserves the right to stick its stuff anywhere at all? Yes, in that case, by agreeing, Emacs's crap becomes Eunice's crap. I hope we can avoid that. > > That is not the same as a place to stuff program-internal > > data. We have `Program Files' and user-specific `Local > > Settings\Application Data' for that kind of thing. > > As I wrote earlier, writing to "Program Files" is a bad idea, > as it is not writable in Vista and later. I said that programs store internal data in such places, and they do. Whether they also use `Program Files' to write new files to, once installed, is another matter. (And I don't hear you making the same claim wrt `Application Data', BTW.) Eli, please stop arguing peripheral minutiae. Store program-internal data where other programs do (on Windows). That's all. 'Nuff said. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 22:48:51 2012 Received: (at 12911) by debbugs.gnu.org; 21 Nov 2012 03:48:51 +0000 Received: from localhost ([127.0.0.1]:57665 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tb1Iw-0004xp-Vb for submit@debbugs.gnu.org; Tue, 20 Nov 2012 22:48:51 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:58796) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tb1Iu-0004xi-RK for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 22:48:50 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MDT00G00JJDEO00@a-mtaout21.012.net.il> for 12911@debbugs.gnu.org; Wed, 21 Nov 2012 05:47:34 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDT00GRAJVA6890@a-mtaout21.012.net.il>; Wed, 21 Nov 2012 05:47:34 +0200 (IST) Date: Wed, 21 Nov 2012 05:47:16 +0200 From: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' files are written In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83vcczvcqj.fsf@gnu.org> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> <83r4now6jk.fsf@gnu.org> <50ABBFA4.6080402@dancol.org> <83haokw3ss.fsf@gnu.org> <5CBDAE291F7447E8834BD7E61FF36B8A@us.oracle.com> <836250vyfo.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: , <12911@debbugs.gnu.org> > Date: Tue, 20 Nov 2012 13:47:38 -0800 > > > "The file system directory used to physically store a user's common > > repository of documents." What do you make of that? "User's > > documents", not "user's files". > > A distinction without a meaning, in the present context. Trouncing user stuff > is a no-no, whether that stuff is "documents" or files. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4709] X-Debbugs-Envelope-To: 12911 Cc: dancol@dancol.org, 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: , <12911@debbugs.gnu.org> > Date: Tue, 20 Nov 2012 13:47:38 -0800 > > > "The file system directory used to physically store a user's common > > repository of documents." What do you make of that? "User's > > documents", not "user's files". > > A distinction without a meaning, in the present context. Trouncing user stuff > is a no-no, whether that stuff is "documents" or files. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4691] > From: "Drew Adams" > Cc: , <12911@debbugs.gnu.org> > Date: Tue, 20 Nov 2012 13:47:38 -0800 > > > "The file system directory used to physically store a user's common > > repository of documents." What do you make of that? "User's > > documents", not "user's files". > > A distinction without a meaning, in the present context. Trouncing user stuff > is a no-no, whether that stuff is "documents" or files. That's your interpretation. It isn't written anywhere. > The distinction that matters here is user vs application. There's no distinction. > You do not seem to want to recognize any difference between a user's photo of > his grandmother and a cache file used by a program to optimize access to that > photo. (Hint: the user cares about Grandma; s?he does not care about the > cache.) Your hint is wrong. I care about my caches dearly. > It's hard for me to believe this is even a point open to debate. Well, it evidently is, and you fail to convince. You are just repeating yourself. > > Don't believe everything Wikipedia says. > > You don't seem to want to believe your own eyes. I believe my experience. > Store program-internal data where other programs do (on Windows). Which is everywhere and nowhere. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 20 23:04:27 2012 Received: (at 12911) by debbugs.gnu.org; 21 Nov 2012 04:04:27 +0000 Received: from localhost ([127.0.0.1]:57743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tb1Y1-0005LG-5Y for submit@debbugs.gnu.org; Tue, 20 Nov 2012 23:04:26 -0500 Received: from dancol.org ([96.126.100.184]:41119) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tb1Xy-0005L7-8q for 12911@debbugs.gnu.org; Tue, 20 Nov 2012 23:04:23 -0500 Received: from c-76-22-66-162.hsd1.wa.comcast.net ([76.22.66.162] helo=[0.0.0.0]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tb1Wl-0001Et-Io; Tue, 20 Nov 2012 20:03:07 -0800 Message-ID: <50AC5276.60406@dancol.org> Date: Tue, 20 Nov 2012 20:03:02 -0800 From: Daniel Colascione User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' files are written References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> <83r4now6jk.fsf@gnu.org> <50ABBFA4.6080402@dancol.org> <83haokw3ss.fsf@gnu.org> <5CBDAE291F7447E8834BD7E61FF36B8A@us.oracle.com> <836250vyfo.fsf@gnu.org> <83vcczvcqj.fsf@gnu.org> In-Reply-To: <83vcczvcqj.fsf@gnu.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3F6F23AAE1C99BF71AFF995A" X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.4 (/) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3F6F23AAE1C99BF71AFF995A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/20/2012 7:47 PM, Eli Zaretskii wrote: >> Store program-internal data where other programs do (on Windows). >=20 > Which is everywhere and nowhere. All my other programs store program-generated files under AppData. None w= rites indiscriminately to the current directory in the event of a crash. --------------enig3F6F23AAE1C99BF71AFF995A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Cygwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCsUnkACgkQ17c2LVA10VtwfQCgt/+D7pEYezNMg2tgt0lDqmst 6OsAnjSjC09ohv5ad+G37pF4JDGHF2jH =ndtZ -----END PGP SIGNATURE----- --------------enig3F6F23AAE1C99BF71AFF995A-- From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 21 10:45:20 2012 Received: (at 12911) by debbugs.gnu.org; 21 Nov 2012 15:45:20 +0000 Received: from localhost ([127.0.0.1]:59297 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbCUK-0004ox-Am for submit@debbugs.gnu.org; Wed, 21 Nov 2012 10:45:20 -0500 Received: from mail-bk0-f44.google.com ([209.85.214.44]:35294) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbCUH-0004op-G5 for 12911@debbugs.gnu.org; Wed, 21 Nov 2012 10:45:18 -0500 Received: by mail-bk0-f44.google.com with SMTP id w11so3243313bku.3 for <12911@debbugs.gnu.org>; Wed, 21 Nov 2012 07:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6Rhv/k95dBUNQswB+ENkIKAGBUx6hy2KXXZn0vPN56A=; b=wU1G6e7V2Hrq/iET6bYobDuyxwNzugXNmdAVrFKtYFxXB2aZy6RyHlbHBhVnbYUSYJ 5mMqnUqJAICjYPpzqDVcHlqbpDUy8/JOOiIITaq4LXUUxGixeaLjzhCd2oX908iTi85D o/QDfEUryBpjOCoU6ZBMswYBwa64hc13kiD4JlmWyuF5jRYrgsv1384LIKUyhbbjVpfx ompMWRwRbIFz6LyXZER6bOXUV4JuGuloD9rjWdId19M2tFGYjNfngqX/d5ChiyRbD7Ks 5z/s3r2HMjR7Opq0ukL5U3KxIUX4oG2NK5kLQM5FpKYfo8/JvZQKspBN/binisJqWMYH 4CpA== Received: by 10.204.147.207 with SMTP id m15mr7130443bkv.54.1353512640998; Wed, 21 Nov 2012 07:44:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.34.70 with HTTP; Wed, 21 Nov 2012 07:43:19 -0800 (PST) In-Reply-To: <50AC5276.60406@dancol.org> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> <83r4now6jk.fsf@gnu.org> <50ABBFA4.6080402@dancol.org> <83haokw3ss.fsf@gnu.org> <5CBDAE291F7447E8834BD7E61FF36B8A@us.oracle.com> <836250vyfo.fsf@gnu.org> <83vcczvcqj.fsf@gnu.org> <50AC5276.60406@dancol.org> From: Juanma Barranquero Date: Wed, 21 Nov 2012 16:43:19 +0100 Message-ID: Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' files are written To: Daniel Colascione Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12911 Cc: Eli Zaretskii , 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On Wed, Nov 21, 2012 at 5:03 AM, Daniel Colascione wrote: > All my other programs store program-generated files under AppData. None writes > indiscriminately to the current directory in the event of a crash. Do you have many Windows programs that do generate a backtrace file in the event of failure? And do they all write to %APPDATA%? If the answer to both questions is "yes", are these Cygwin programs? Juanma From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 21 11:26:20 2012 Received: (at 12911) by debbugs.gnu.org; 21 Nov 2012 16:26:20 +0000 Received: from localhost ([127.0.0.1]:59359 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbD7y-0005jP-OS for submit@debbugs.gnu.org; Wed, 21 Nov 2012 11:26:19 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:50223) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbD7v-0005jH-NO for 12911@debbugs.gnu.org; Wed, 21 Nov 2012 11:26:16 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qALGOqk7006876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Nov 2012 16:24:53 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qALGOp0s002230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2012 16:24:52 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qALGOplE003423; Wed, 21 Nov 2012 10:24:51 -0600 Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Nov 2012 08:24:51 -0800 From: "Drew Adams" To: "'Juanma Barranquero'" , "'Daniel Colascione'" References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org><83r4now6jk.fsf@gnu.org> <50ABBFA4.6080402@dancol.org><83haokw3ss.fsf@gnu.org><5CBDAE291F7447E8834BD7E61FF36B8A@us.oracle.com><836250vyfo.fsf@gnu.org><83vcczvcqj.fsf@gnu.org> <50AC5276.60406@dancol.org> Subject: RE: bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' filesare written Date: Wed, 21 Nov 2012 08:24:49 -0800 Message-ID: <58D82C28C53E4499B15C57A4FE2687F1@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac3H/yl5B0//y58OS+u3Tf/fkQblxgABKu+Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 12911 Cc: 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.8 (-) > > All my other programs store program-generated files under > > AppData. None writes indiscriminately to the current directory > > in the event of a crash. > > Do you have many Windows programs that do generate a backtrace file in > the event of failure? And do they all write to %APPDATA%? > > If the answer to both questions is "yes", are these Cygwin programs? Why not add "and whose name is `Emacs'" while you're at it? Seriously, this is not only about applications that generate a backtrace file. It's about the etiquette that applications generally respect on Windows, in order to respect the user and user data. Why narrow it to applications that write backtrace files? Is there something particular about that case which should exclude it from respecting of the normal etiquette? Sure, if a program absolutely CANNOT respect the expected behavior because of some hard constraint, then maybe that's a reason to make it an exception. So far, we haven't seen such a reason, AFAICT. It might not be super simple for Emacs to DTRT here, but that's not the same thing as saying that it CANNOT do so. And of course we have several decades of Emacs use without this new feature, in which Emacs has not found it necessary to go beyond the pale. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 21 11:47:29 2012 Received: (at 12911) by debbugs.gnu.org; 21 Nov 2012 16:47:29 +0000 Received: from localhost ([127.0.0.1]:59366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbDSS-0006Cf-KL for submit@debbugs.gnu.org; Wed, 21 Nov 2012 11:47:29 -0500 Received: from mail-ea0-f172.google.com ([209.85.215.172]:64500) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbDSR-0006CY-G2 for 12911@debbugs.gnu.org; Wed, 21 Nov 2012 11:47:28 -0500 Received: by mail-ea0-f172.google.com with SMTP id a1so2320187eaa.3 for <12911@debbugs.gnu.org>; Wed, 21 Nov 2012 08:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=e4RLP48yWMdAuhb6RuEHfZy4NBN6smd9XcC6umaITdk=; b=GQJpzvE4HXwHQZxVP/62c1RDMlqvUnucCq6og46sJ0RBFtghGpftgYJr2QHHxLtanB Bc1sxFwFW2q/TbAVS8LxZGM2egXeXq4FP22samozxqZFAKpbb60ZdKxo3KVsez+GlcJH RLQfYlXEegrcffUlesy8gcN7nQCnMKSm7zPGA1X9tzA/wjJUw8OvzJIhXBRGiOtcrqhM r2Bip6yZoMCZ1/w4Fm1pL78pqsdXn7O1gmuYd+rdNngbmRhvAb98Ga+AyypK79bZAZie xDjYWpOF4CKBYWLn61gHu4Wo97zZEHl81sZ5rvklhDl5/cvNkjvg43ojTLDkC5iZHbgI BfIA== Received: by 10.14.176.68 with SMTP id a44mr47518740eem.1.1353516370992; Wed, 21 Nov 2012 08:46:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.4.209 with HTTP; Wed, 21 Nov 2012 08:45:30 -0800 (PST) In-Reply-To: <58D82C28C53E4499B15C57A4FE2687F1@us.oracle.com> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> <83r4now6jk.fsf@gnu.org> <50ABBFA4.6080402@dancol.org> <83haokw3ss.fsf@gnu.org> <5CBDAE291F7447E8834BD7E61FF36B8A@us.oracle.com> <836250vyfo.fsf@gnu.org> <83vcczvcqj.fsf@gnu.org> <50AC5276.60406@dancol.org> <58D82C28C53E4499B15C57A4FE2687F1@us.oracle.com> From: Juanma Barranquero Date: Wed, 21 Nov 2012 17:45:30 +0100 Message-ID: Subject: Re: bug#12911: 24.3.50;let users decide where (& perhaps whether)`emacs_backtrace.txt' filesare written To: Drew Adams Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12911 Cc: Daniel Colascione , 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On Wed, Nov 21, 2012 at 5:24 PM, Drew Adams wrote: > Why not add "and whose name is `Emacs'" while you're at it? Because that would not make sense. > Seriously, this is not only about applications that generate a backtrace file. Yes, it is, because David said "[n]one writes indiscriminately to the current directory in the event of a crash", and... > It's about the etiquette that applications generally respect on Windows, in > order to respect the user and user data. ...Emacs does NOT write files at random here and there. We're specifically talking about a situation where Emacs is going down in flames, and Eli choose a simple answer that does not require checking remote accesses or environment variables. I would agree with you if Emacs were prone to writing files in unexpected places, but a crash backtrace is an exceptional circumstance. Again: I understand that you're worried because you've said that crashes are almost a daily occurrence for you. But I use the trunk [Stefan: not really, I'm using emacs-24, I swear] and I cannot remember the last time I had a crash other than assertion failures after some sweeping "cleanup". Juanma From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 21 12:41:36 2012 Received: (at 12911) by debbugs.gnu.org; 21 Nov 2012 17:41:36 +0000 Received: from localhost ([127.0.0.1]:59447 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbEIq-0008Jq-AF for submit@debbugs.gnu.org; Wed, 21 Nov 2012 12:41:36 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:32948) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbEIi-0008Jc-Qt for 12911@debbugs.gnu.org; Wed, 21 Nov 2012 12:41:31 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qALHe4NT026065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Nov 2012 17:40:05 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qALHe4hW017678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2012 17:40:04 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qALHe3Zp000945; Wed, 21 Nov 2012 11:40:04 -0600 Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Nov 2012 09:40:03 -0800 From: "Drew Adams" To: "'Juanma Barranquero'" References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> <83r4now6jk.fsf@gnu.org> <50ABBFA4.6080402@dancol.org> <83haokw3ss.fsf@gnu.org> <5CBDAE291F7447E8834BD7E61FF36B8A@us.oracle.com> <836250vyfo.fsf@gnu.org> <83vcczvcqj.fsf@gnu.org> <50AC5276.60406@dancol.org> <58D82C28C53E4499B15C57A4FE2687F1@us.oracle.com> Subject: RE: bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' filesare written Date: Wed, 21 Nov 2012 09:40:02 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac3IB7dYqaj1eQoSQCu3/ad8QNwqKAAA0btw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 12911 Cc: 'Daniel Colascione' , 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.5 (----) > Again: I understand that you're worried because you've said that > crashes are almost a daily occurrence for you. But I use the trunk > [Stefan: not really, I'm using emacs-24, I swear] and I cannot > remember the last time I had a crash other than assertion failures > after some sweeping "cleanup". NOT AT ALL. Totally irrelevant. This has nothing to do with me or my setup or the frequency with which I experience crashes with Emacs 24. I think you will find no mention by me in the bug report I filed for this, or in any of my correspondence in the bug thread, of my daily crashes with Emacs 24 or my concern for my own sake. Red herring - you are apparently grasping at straws. My concern is that Emacs be respectful of users (not particularly me). For my personal use I could not care less where Emacs sticks backtrace files. As to your argument that this is exceptional because Emacs is going down in flames: I think Stefan has already spoken to that. We have a choice in that context regarding how polite Emacs should try to be. I would say very polite - as polite as Emacs has always been. You seem to be saying that we cannot afford to be so polite when Rome is burning. And I'm guessing you might also say that we cannot even give users the choice as to how polite Emacs needs to be here, because when you're going down in flames you cannot be checking user options (we've heard that wrt env vars). We can agree to disagree about this. To me, it is more important that Emacs respect users than it is that Emacs save (and hopefully later send to Emacs Dev) each and every backtrace. We've gotten by OK for decades now without such an annoyance. And we can apparently (IIUC) find ways to get at least some such backtrace feedback (i.e, sometimes) without the annoyance. IIUC, Stefan and Eli have both said that it is only in some cases that Emacs would not be able to save the backtrace data, if we required Emacs to respect users and stay out of their folders. (However, I'm no expert on the implementation question, and it's quite possible I have misunderstood.) I say that if that is the case then Emacs Dev should pay the (small) price and forego those particular backtraces. Not a big deal, IMHO. Not as big a deal as, in effect, telling users that Emacs does not care about their data. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 21 12:45:29 2012 Received: (at 12911) by debbugs.gnu.org; 21 Nov 2012 17:45:29 +0000 Received: from localhost ([127.0.0.1]:59451 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbEMa-0008PL-V4 for submit@debbugs.gnu.org; Wed, 21 Nov 2012 12:45:29 -0500 Received: from mail-ee0-f44.google.com ([74.125.83.44]:44310) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbEMY-0008PC-LH for 12911@debbugs.gnu.org; Wed, 21 Nov 2012 12:45:27 -0500 Received: by mail-ee0-f44.google.com with SMTP id b47so4597716eek.3 for <12911@debbugs.gnu.org>; Wed, 21 Nov 2012 09:44:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=h3u/wx24P6NKN0Enprb6O8BcXtZ9429rMlO0cHUzVVc=; b=NpY5jxYb3bAiI3PU/7wSapluPgUSdRmjZWueesSXSLsMufzpPPS8JA1s2rgy4DtUUN ObiKWkdEcRpRRlFRs0st0kwBVdAx2/Z/idaRdRDgWw+llIisoDV08NBzDlIdulUgT4wn VE5JgQU/5IYa7/222w0apMK43m+64RF8UMwOEAl5QK9w6psysMZkDBD9loh1LnhjKzoO rBzoO1oD8vgGXEeQeHnqPXgip1BGp4+gw9+DEXmZtdPu69elIesbedOPcM4ip5Vs2HM0 Rs1q0Axn/wCfo2v1PdW4IVHjVBUCTYWBqSbZUZAOun1cfEp4ZovvuiioXy8AZeQQR5ss Itqw== Received: by 10.14.205.198 with SMTP id j46mr47993025eeo.27.1353519850227; Wed, 21 Nov 2012 09:44:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.4.209 with HTTP; Wed, 21 Nov 2012 09:43:28 -0800 (PST) In-Reply-To: References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> <83r4now6jk.fsf@gnu.org> <50ABBFA4.6080402@dancol.org> <83haokw3ss.fsf@gnu.org> <5CBDAE291F7447E8834BD7E61FF36B8A@us.oracle.com> <836250vyfo.fsf@gnu.org> <83vcczvcqj.fsf@gnu.org> <50AC5276.60406@dancol.org> <58D82C28C53E4499B15C57A4FE2687F1@us.oracle.com> From: Juanma Barranquero Date: Wed, 21 Nov 2012 18:43:28 +0100 Message-ID: Subject: Re: bug#12911: 24.3.50;let users decide where (& perhaps whether)`emacs_backtrace.txt' filesare written To: Drew Adams Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12911 Cc: Daniel Colascione , 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On Wed, Nov 21, 2012 at 6:40 PM, Drew Adams wrote: > Red herring - you are apparently grasping at straws. Thanks, it is always great to be read in such a favorable light. > You seem to be > saying that we cannot afford to be so polite when Rome is burning. No, I'm saying that this is much ado about almost nothing. Juanma From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 21 13:02:38 2012 Received: (at 12911) by debbugs.gnu.org; 21 Nov 2012 18:02:38 +0000 Received: from localhost ([127.0.0.1]:59461 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbEdB-0000MM-PW for submit@debbugs.gnu.org; Wed, 21 Nov 2012 13:02:38 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:25369) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbEd7-0000MC-NU for 12911@debbugs.gnu.org; Wed, 21 Nov 2012 13:02:35 -0500 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qALI1AtS015610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Nov 2012 18:01:11 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qALI19oJ003208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2012 18:01:10 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qALI19fl001906; Wed, 21 Nov 2012 12:01:09 -0600 Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Nov 2012 10:01:09 -0800 From: "Drew Adams" To: "'Juanma Barranquero'" References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> <83r4now6jk.fsf@gnu.org> <50ABBFA4.6080402@dancol.org> <83haokw3ss.fsf@gnu.org> <5CBDAE291F7447E8834BD7E61FF36B8A@us.oracle.com> <836250vyfo.fsf@gnu.org> <83vcczvcqj.fsf@gnu.org> <50AC5276.60406@dancol.org> <58D82C28C53E4499B15C57A4FE2687F1@us.oracle.com> Subject: RE: bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' filesare written Date: Wed, 21 Nov 2012 10:01:08 -0800 Message-ID: <71125AE486F54427AD17522CB6B03280@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac3ID9GWLhjTL3YBRnWFEBh90kdjxQAAS8zw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 12911 Cc: 'Daniel Colascione' , 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.8 (-) > > Red herring - you are apparently grasping at straws. > > Thanks, it is always great to be read in such a favorable light. Sorry if I hurt your feelings somehow. But what would you call it, bringing my personal use of Emacs into the discussion as if it were the motivation behind my filing the bug report and arguing for a fix? It is not, at all. To me, that red herring (which it is) was an ad hominem turn in the road - let's look at Drew, not Drew's message. Irrelevant to the discussion. And far removed from any argument I have made here. Don't get me wrong. I do not say that it was an ad hominem attack in any way; it was not an attack. It was just an irrelevant distraction. But let me know if I'm missing something in your argument. And again, sorry if something I said caused hard feelings - none were intended. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 21 13:15:48 2012 Received: (at 12911) by debbugs.gnu.org; 21 Nov 2012 18:15:48 +0000 Received: from localhost ([127.0.0.1]:59474 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbEpv-0000eB-EN for submit@debbugs.gnu.org; Wed, 21 Nov 2012 13:15:48 -0500 Received: from mail-ee0-f44.google.com ([74.125.83.44]:60489) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbEpt-0000e4-B1 for 12911@debbugs.gnu.org; Wed, 21 Nov 2012 13:15:46 -0500 Received: by mail-ee0-f44.google.com with SMTP id b47so4614742eek.3 for <12911@debbugs.gnu.org>; Wed, 21 Nov 2012 10:14:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9cvYX117yqIlaNYdLz7ZEen1wy24thhlWgs/dz3Ok1w=; b=BjaY2vf5Zp/hV5nWtGz41c+HYScrY+M+tNUtn7MAzWLZkI/3vRHN4xnEI1q8MAcA9H XvtMTseDdmb6ImJXeZb6mFFqGa+t8ztMOP8Lpl56O/TFe5/XejMvncUFesLTC/j90NP9 rGz7am/zm+yN9Ho/9mI74/LW4wd+Ii1bLKSpUQtJMYl6R00hwb0CYtoeMeWpQD/O+1pn DNax3xb+fFB4emOYPnhQaCeleRmFVeVOaVdTNrQ3Y5X/NfTzcxbU1LGmIE1S2hEmNOFm cadXLvmCpxanaBMwvtwUk7hkU60isRvRM5MZvAI+SzEkEdLe2xD3iJA90cAm4pIQUVg8 bf8w== Received: by 10.14.203.2 with SMTP id e2mr25290223eeo.20.1353521668764; Wed, 21 Nov 2012 10:14:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.4.209 with HTTP; Wed, 21 Nov 2012 10:13:48 -0800 (PST) In-Reply-To: <71125AE486F54427AD17522CB6B03280@us.oracle.com> References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> <83r4now6jk.fsf@gnu.org> <50ABBFA4.6080402@dancol.org> <83haokw3ss.fsf@gnu.org> <5CBDAE291F7447E8834BD7E61FF36B8A@us.oracle.com> <836250vyfo.fsf@gnu.org> <83vcczvcqj.fsf@gnu.org> <50AC5276.60406@dancol.org> <58D82C28C53E4499B15C57A4FE2687F1@us.oracle.com> <71125AE486F54427AD17522CB6B03280@us.oracle.com> From: Juanma Barranquero Date: Wed, 21 Nov 2012 19:13:48 +0100 Message-ID: Subject: Re: bug#12911: 24.3.50;let users decide where (& perhaps whether)`emacs_backtrace.txt' filesare written To: Drew Adams Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12911 Cc: Daniel Colascione , 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On Wed, Nov 21, 2012 at 7:01 PM, Drew Adams wrote: > To me, that red herring (which it is) was an ad hominem turn in the road - let's > look at Drew, not Drew's message. Mine wasn't an ad hominem, because I haven't said that your arguments are wrong because they are yours. I think they are wrong because they put emphasis in something that happens very rarely, and suggest adding complexity to something that is very simple. AND I've *pointed out* that the relative importance of that problem is greater for you than for me, because you are more likely to get affected by it. That could affect your judgment (it would likely affect mine; I get angry when people who doesn't ever use line-by-line scrolling start suggesting changes to scroll-conservatively and Emacs recentering, or when non-Windows users suggest that some changes won't affect the Windows port, or that if they do affect it, is all Microsoft's fault). > Don't get me wrong. I do not say that it was an ad hominem attack in any way; > it was not an attack. It was just an irrelevant distraction. I find an irrelevant distraction that you're discussing "[...] the etiquette that applications generally respect on Windows, in order to respect the user and user data" when the thread is specifically about *one* file, in *one* specific situation, which is a crash backtrace. Juanma From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 21 13:43:31 2012 Received: (at 12911) by debbugs.gnu.org; 21 Nov 2012 18:43:31 +0000 Received: from localhost ([127.0.0.1]:59527 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbFGk-0001Gz-5I for submit@debbugs.gnu.org; Wed, 21 Nov 2012 13:43:30 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:47265) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TbFGi-0001Gs-0e for 12911@debbugs.gnu.org; Wed, 21 Nov 2012 13:43:28 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qALIg3ot009942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Nov 2012 18:42:04 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qALIg3UN008275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2012 18:42:03 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qALIg2f7008427; Wed, 21 Nov 2012 12:42:02 -0600 Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Nov 2012 10:42:02 -0800 From: "Drew Adams" To: "'Juanma Barranquero'" References: <83wqxk3d1z.fsf@gnu.org> <83y5hyxnb1.fsf@gnu.org> <83wqxhy4ha.fsf@gnu.org> <83fw45xxzk.fsf@gnu.org> <83ehjpxwqd.fsf@gnu.org> <838v9xxss8.fsf@gnu.org> <83zk2dvsba.fsf@gnu.org> <50AB0EDE.40109@dancol.org> <83r4now6jk.fsf@gnu.org> <50ABBFA4.6080402@dancol.org> <83haokw3ss.fsf@gnu.org> <5CBDAE291F7447E8834BD7E61FF36B8A@us.oracle.com> <836250vyfo.fsf@gnu.org> <83vcczvcqj.fsf@gnu.org> <50AC5276.60406@dancol.org> <58D82C28C53E4499B15C57A4FE2687F1@us.oracle.com> <71125AE486F54427AD17522CB6B03280@us.oracle.com> Subject: RE: bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' filesare written Date: Wed, 21 Nov 2012 10:42:01 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac3IFA3MlJQsgXKuQdaKzMlXyMGdAwAAkwcA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 12911 Cc: 'Daniel Colascione' , 12911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.8 (-) > I find an irrelevant distraction that you're discussing "[...] the > etiquette that applications generally respect on Windows, in order to > respect the user and user data" when the thread is specifically about > *one* file, in *one* specific situation, which is a crash backtrace. It's in fact as far as you can get from irrelevant. That's precisely what this bug report is about: the placement by Emacs of that "*one* file, in *one* specific situation, which is a crash backtrace", into a user folder. So perhaps this bug report is altogether irrelevant and a distraction to you. Fair enough. What can I say, in that case? We're back to agreeing to disagree. I think that that *one* case of disrespecting users should be removed; you think that that regression should stay, because it is an improvement. We apparently do not disagree about the other cases for this new feature: the cases where user folders are not written into. We both are in favor of the new feature in those cases. We apparently disagree only about that *one* corner case, where Emacs apparently cannot do otherwise than to write its backtrace into a user folder. That's the case this bug report is about. From unknown Sun Jun 22 03:58:20 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 20 Dec 2012 12: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