unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Eli Zaretskii'" <eliz@gnu.org>
Cc: 12911@debbugs.gnu.org
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	[thread overview]
Message-ID: <C2E916368FFB45DE92017416F145F7B3@us.oracle.com> (raw)
In-Reply-To: <836250vyfo.fsf@gnu.org>

> "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\<username>\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.






  reply	other threads:[~2012-11-20 21:47 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-16 20:48 bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Drew Adams
2012-11-16 21:05 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files " Drew Adams
2012-11-16 21:19 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files " Stefan Monnier
2012-11-17  7:26   ` Eli Zaretskii
2012-11-17 17:38     ` Drew Adams
2012-11-17 17:55       ` Eli Zaretskii
2012-11-17 18:24         ` Drew Adams
2012-11-19  1:52     ` Stefan Monnier
2012-11-19  3:51       ` Eli Zaretskii
2012-11-19  4:07         ` Stefan Monnier
2012-11-19 15:52           ` Eli Zaretskii
2012-11-19 18:04             ` Stefan Monnier
2012-11-19 18:13               ` Eli Zaretskii
2012-11-19 18:35                 ` Stefan Monnier
2012-11-19 18:40                   ` Eli Zaretskii
2012-11-19 19:47                     ` Stefan Monnier
2012-11-19 20:05                       ` Eli Zaretskii
2012-11-19 21:15                         ` Stefan Monnier
2012-11-20  3:58                           ` Eli Zaretskii
2012-11-20  4:59                             ` Stefan Monnier
2012-11-20  5:02                               ` Daniel Colascione
2012-11-20 13:16                                 ` Andy Moreton
2012-11-20 16:27                                   ` Eli Zaretskii
2012-11-20 17:03                                 ` Eli Zaretskii
2012-11-20 17:36                                   ` Daniel Colascione
2012-11-20 18:02                                     ` Eli Zaretskii
2012-11-20 18:57                                       ` bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' " Drew Adams
2012-11-20 19:58                                         ` Eli Zaretskii
2012-11-20 21:47                                           ` Drew Adams [this message]
2012-11-21  3:47                                             ` Eli Zaretskii
2012-11-21  4:03                                               ` Daniel Colascione
2012-11-21 15:43                                                 ` Juanma Barranquero
2012-11-21 16:24                                                   ` bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' filesare written Drew Adams
     [not found]                                                     ` <E86D7DFBD2BD4C3394E5316EF0321A! 95@us.oracle.com>
2012-11-21 16:45                                                     ` Juanma Barranquero
2012-11-21 17:40                                                       ` Drew Adams
2012-11-21 17:43                                                         ` Juanma Barranquero
2012-11-21 18:01                                                           ` Drew Adams
2012-11-21 18:13                                                             ` Juanma Barranquero
2012-11-21 18:42                                                               ` Drew Adams
2012-11-20 18:30                                   ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Stefan Monnier
2012-11-20 18:37                                     ` Eli Zaretskii
2012-11-20 20:15                                       ` Stefan Monnier
2012-11-20 16:36                               ` Juanma Barranquero
2012-11-20 17:11                                 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files " Drew Adams
2012-11-20 17:53                                   ` Eli Zaretskii
2012-11-20 18:10                                     ` Drew Adams
2012-11-20 18:27                                       ` Eli Zaretskii
2012-11-20 19:15                                         ` Dani Moncayo
2012-11-20 19:41                                           ` Eli Zaretskii
2012-11-20 20:11                                             ` Dani Moncayo
2012-11-20 17:49                                 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files " Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2012-11-16 18:30 bug#12908: 24.3.50; file `emacs_backtrace.txt'? Drew Adams
2012-11-17 18:45 ` Paul Eggert
2012-11-17 19:09   ` Eli Zaretskii
2012-11-17 19:29     ` Paul Eggert
2012-11-17 19:42       ` Eli Zaretskii
2012-11-17 21:25         ` Paul Eggert
2012-11-18  4:04           ` Eli Zaretskii
2012-11-18  5:19             ` Paul Eggert
2012-11-18 17:16               ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Eli Zaretskii
2012-11-18 19:18                 ` Paul Eggert
2012-11-18 21:10                   ` Eli Zaretskii
2012-11-19  1:44                     ` Stefan Monnier
2012-11-19  3:50                       ` Eli Zaretskii
2012-11-17 23:01     ` bug#12908: 24.3.50; file `emacs_backtrace.txt'? Drew Adams
2012-11-18  3:58       ` Eli Zaretskii
2012-11-18  4:40         ` Drew Adams
2012-11-18 17:53           ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Eli Zaretskii
2012-11-18 18:42             ` Drew Adams
2012-11-18  5:19         ` bug#12908: 24.3.50; file `emacs_backtrace.txt'? Paul Eggert
2012-11-18 17:08           ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C2E916368FFB45DE92017416F145F7B3@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=12911@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).