From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: 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: 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1353448136 9450 80.91.229.3 (20 Nov 2012 21:48:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Nov 2012 21:48:56 +0000 (UTC) Cc: 12911@debbugs.gnu.org To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 20 22:49:06 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Tavgo-0002qv-J1 for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Nov 2012 22:49:06 +0100 Original-Received: from localhost ([::1]:43974 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tavge-0003tH-Az for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Nov 2012 16:48:56 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41842) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tavga-0003sl-Sr for bug-gnu-emacs@gnu.org; Tue, 20 Nov 2012 16:48:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TavgZ-0008Nt-Mh for bug-gnu-emacs@gnu.org; Tue, 20 Nov 2012 16:48:52 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47221) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TavgZ-0008No-JE for bug-gnu-emacs@gnu.org; Tue, 20 Nov 2012 16:48:51 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Tavhi-0005Ks-65 for bug-gnu-emacs@gnu.org; Tue, 20 Nov 2012 16:50:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 20 Nov 2012 21:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12911 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 12911-submit@debbugs.gnu.org id=B12911.135344814720442 (code B ref 12911); Tue, 20 Nov 2012 21:50:02 +0000 Original-Received: (at 12911) by debbugs.gnu.org; 20 Nov 2012 21:49:07 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 Original-Received: from dradamslap1 (/10.159.225.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Nov 2012 13:47:43 -0800 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:67252 Archived-At: > "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.