bug#12908: 24.3.50; file `emacs_backtrace.txt'?

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Drew Adams]

Still getting many crashes (every session), but now I notice that Emacs
is creating a file `emacs_backtrace.txt' in the current directory (or
perhaps it is in the dir in which Emacs was started?).
 
I looked in the Emacs manual, the Elisp manual, and NEWS for some
information about this file, but found nothing (so there is a doc bug,
at least).
 
What is the file for, how are users to use it and control whether and
where it is written, etc.?
 
Here is the content of one such file, in case it helps in some way
(which I doubt):
 

Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01021A07
0x012072B8
0x012080B9
0x0103B54F
0x0104F14B
0x01038878
0x01010EDE
0x0103800B
0x0101093B
0x01037FC5
0x0103757F
0x010378AC
0x010029AB
0x010010F9
0x7C817073
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01021A07
0x01063E40
0x010030FF
0x01001411
0x01021A07
0x01208B6F
0x01206FA0
0x01203D74
0x0103B556
0x0104F14B
0x01038878
0x01010EDE
0x0103800B
0x0101093B
0x01037FC5
0x0103757F
0x010378AC
0x010029AB
0x010010F9
0x7C817073
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01144D4F
0x01144D2A
0x01144D83
0x010011E6
0x7C8438F6
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01144D4F
0x01144D2A
0x01144D83
0x010011E6
0x7C8438F6
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01021A07
0x01063E40
0x010030FF
0x01001411
0x01021A07
0x01271987
0x012753CF
0x01201334
0x01202410
0x0121160D
0x01208C14
0x01010FC6
0x01208BA1
0x01206FA0
0x01203D74
0x0103B556
0x0104F14B
0x01038878
0x01010EDE
0x0103800B
0x0101093B
0x01037FC5
0x0103757F
0x010378AC
0x010029AB
0x010010F9
0x7C817073
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01021A07
0x010EFEEA
0x010F6A68
0x010F5208
0x010F48F4
0x010F4616
0x0120710E
0x01203D74
0x0103B556
0x0104F14B
0x01038878
0x01010EDE
0x0103800B
0x0101093B
0x01037FC5
0x0103757F
0x010378AC
0x010029AB
0x010010F9
0x7C817073
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01144D4F
0x01144D2A
0x01144D83
0x010011E6
0x7C8438F6
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01021A07
0x012D32D3
0x01014F64
0x010E117F
0x01015E7E
0x01015317
0x010E117F
0x01015E7E
0x01015317
0x010E117F
0x01015E7E
0x01015317
0x010E117F
0x01015E7E
0x01015317
0x010E6C1C
0x01014FD5
0x01014733
0x01052C55
0x010390C7
0x01010EDE
0x0103800B
0x0101093B
0x01037FC5
0x0103757F
0x010378AC
0x010029AB
0x010010F9
0x7C817073
 
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'
 

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Juanma Barranquero]

On Fri, Nov 16, 2012 at 7:30 PM, Drew Adams <drew.adams@oracle.com> wrote:

> I looked in the Emacs manual, the Elisp manual, and NEWS for some
> information about this file, but found nothing (so there is a doc bug,
> at least).

Yes.

> What is the file for, how are users to use it and control whether and
> where it is written, etc.?

2012-11-02  Eli Zaretskii  <eliz@gnu.org>

        Implement backtrace output for fatal errors on MS-Windows.
        * w32fns.c (CaptureStackBackTrace_proc): New typedef.
        (BACKTRACE_LIMIT_MAX): New macro.
        (w32_backtrace): New function.
        (emacs_abort): Use w32_backtrace when the user chooses not to
        attach a debugger.  Update the text of the abort dialog.

Currently you cannot control where it is written.

As for how to use it, if you have MinGW installed you can use addr2line:

addr2line -e /path/to/emacs.exe < emacs_backtrace.txt

    Juanma

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Drew Adams]

> > What is the file for, how are users to use it and control 
> > whether and where it is written, etc.?
> 
>         Implement backtrace output for fatal errors on MS-Windows.
>         * w32fns.c (CaptureStackBackTrace_proc): New typedef.
>         (BACKTRACE_LIMIT_MAX): New macro.
>         (w32_backtrace): New function.
>         (emacs_abort): Use w32_backtrace when the user chooses not to
>         attach a debugger.  Update the text of the abort dialog.
> 
> Currently you cannot control where it is written.

Thanks for the info.

Can you at least control _whether_ it is written?

> As for how to use it, if you have MinGW installed you can use 
> addr2line: addr2line -e /path/to/emacs.exe < emacs_backtrace.txt

(Which does what?)

If you do *not* have MinGW installed then is it the case that you can do nothing
with the file?  If so then, in that case at least, users should have an easy way
to turn off writing the file (which no one can use).

Is there some way (e.g. an env var to check?) that Emacs can itself know whether
MinGW is installed, so that at least in the case where it is not it can inhibit
writing the file (by default - obviously to be overridable by users)?

The file is not big (at least it wasn't in the case I had), so I don't mind
Emacs writing it, even though I cannot use it.  But I think users should be able
to control whether and where it gets written.

And I'm thinking that the default location should perhaps be somewhere under
.emacs.d, perhaps with the dir that is currently used as the default recorded
somehow.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 16 Nov 2012 11:08:16 -0800
> Cc: 12908@debbugs.gnu.org
> 
> Can you at least control _whether_ it is written?

No.  But you can set up a scheduled task to delete it every day, if
you wish.  You can even do this in Emacs, using the midnight.el
package.

> And I'm thinking that the default location should perhaps be somewhere under
> .emacs.d, perhaps with the dir that is currently used as the default recorded
> somehow.

This is dangerous, because accessing the home directory may involve
Lisp evaluation, e.g. if that directory is remote.  This facility must
be as simple and close to the bare metal as possible, or else it will
be more trouble than help.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Drew Adams]

> > And I'm thinking that the default location should perhaps 
> > be somewhere under .emacs.d, perhaps with the dir that is
> > currently used as the default recorded somehow.
> 
> This is dangerous, because accessing the home directory may involve
> Lisp evaluation, e.g. if that directory is remote.  This facility must
> be as simple and close to the bare metal as possible, or else it will
> be more trouble than help.

Then put it under the Emacs installation directory.

The point is to get it away from user files.  Please use your imagination.  If
there are good reasons why you cannot easily put it here or there, then try
somewhere else - but aim for somewhere that does not interfere with user data.

A users looking in her folder of recipes should not find an Emacs debugging
file.  That should be a no-brainer, at least in terms of goal.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <lekktu@gmail.com>, <12908@debbugs.gnu.org>
> Date: Fri, 16 Nov 2012 13:02:27 -0800
> 
> > > And I'm thinking that the default location should perhaps 
> > > be somewhere under .emacs.d, perhaps with the dir that is
> > > currently used as the default recorded somehow.
> > 
> > This is dangerous, because accessing the home directory may involve
> > Lisp evaluation, e.g. if that directory is remote.  This facility must
> > be as simple and close to the bare metal as possible, or else it will
> > be more trouble than help.
> 
> Then put it under the Emacs installation directory.
> 
> The point is to get it away from user files.

Again, I just mimicked the behavior on Unix, as best as possible.
Please read the manual to learn where this information is put on Unix.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Drew Adams]

> > Then put it under the Emacs installation directory.
> > The point is to get it away from user files.
> 
> Again, I just mimicked the behavior on Unix, as best as possible.
> Please read the manual to learn where this information is put on Unix.

No one is blaming you, and certainly not for making things consistent with what
is done on Unix.  You have pointed out that the bug (annoyance) exists on Unix
also.  Fine.  So let's correct it everywhere.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Stefan Monnier]

>> And I'm thinking that the default location should perhaps be
>> somewhere under .emacs.d, perhaps with the dir that is currently used
>> as the default recorded somehow.
> This is dangerous, because accessing the home directory may involve
> Lisp evaluation, e.g. if that directory is remote.

If the ~/.emacs.d is under some file-handler like Tramp, then we're out
of luck, but I wouldn't worry about it.  Just pass the file names to the
OS's functions and if it can't handle them, then you'll get a write
error and that's that (we have to handle that case anyway).


        Stefan

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Drew Adams <drew.adams@oracle.com>,  lekktu@gmail.com,  12908@debbugs.gnu.org
> Date: Fri, 16 Nov 2012 16:49:22 -0500
> 
> >> And I'm thinking that the default location should perhaps be
> >> somewhere under .emacs.d, perhaps with the dir that is currently used
> >> as the default recorded somehow.
> > This is dangerous, because accessing the home directory may involve
> > Lisp evaluation, e.g. if that directory is remote.
> 
> If the ~/.emacs.d is under some file-handler like Tramp, then we're out
> of luck, but I wouldn't worry about it.  Just pass the file names to the
> OS's functions and if it can't handle them, then you'll get a write
> error and that's that (we have to handle that case anyway).

Fine with me.  I will change the Windows code when the Unix code is
changed along these lines.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 16 Nov 2012 10:30:34 -0800
> 
> Still getting many crashes (every session), but now I notice that Emacs
> is creating a file `emacs_backtrace.txt' in the current directory (or
> perhaps it is in the dir in which Emacs was started?).

It's written in the current directory of the Emacs process, and only
if you click NO on the abort dialog.

> I looked in the Emacs manual, the Elisp manual, and NEWS for some
> information about this file, but found nothing (so there is a doc bug,
> at least).

Right, now fixed (revision 110913 on the trunk).

> What is the file for

It contains the call-stack backtrace, which could be used to find the
sequence of function calls that led to the crash.  Similar to what GDB
produces when you type "bt".

> how are users to use it

Users should include it with their bug reports.  If you have the
addr2line.exe program on your disk, you can produce a more readable
backtrace from these numbers, see the Emacs user manual for details.

> and control whether and where it is written

You can't.  It's always written in the current directory of the Emacs
process, which is normally a single directory determined by what your
desktop shortcut says.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Drew Adams]

> It's written in the current directory of the Emacs process, and only
> if you click NO on the abort dialog.

I don't understand.  If you click NO then you are saying that you do NOT want to
participate in debugging the crash.  Why would Emacs insist in that case in
writing a backtrace file for debugging to your hard drive?

That does not seem very friendly (or useful) on the part of Emacs.

> > I looked in the Emacs manual, the Elisp manual, and NEWS for some
> > information about this file, but found nothing (so there is 
> > a doc bug, at least).
> 
> Right, now fixed (revision 110913 on the trunk).
> 
> > What is the file for
> 
> It contains the call-stack backtrace, which could be used to find the
> sequence of function calls that led to the crash.  Similar to what GDB
> produces when you type "bt".

So it could be used for debugging.  But it is written only if a user says that
s?he does NOT want to debug the crash.

I understand that such a NO means, in particular, that s?he does not want to use
gdb, but it can also mean that s?he does not want to bother with any debugging
etc.  Why assume that s?he wants a backtrace file written?

> > how are users to use it
> 
> Users should include it with their bug reports.

Does my having included it in this bug report help in some way?
I'm guessing no, but would love to be shown wrong.

> If you have the addr2line.exe program on your disk, you can
> produce a more readable backtrace from these numbers, see
> the Emacs user manual for details.

And if you do not have addr2line?  Is the backtrace really useful for anyone in
that case?  Did the backtrace I included here help at all?
(Not rhetorical questions.)

> > and control whether and where it is written
> 
> You can't.  It's always written in the current directory of the Emacs
> process, which is normally a single directory determined by what your
> desktop shortcut says.

Why not let users decide where the file is written, and record that directory
(of the process) as part of the file content (or record it elsewhere)?

Sounds like shades of Unix .core files.  At least there are ways for users to
turn off writing such coredumps (and even ways to turn that off selectively, for
given directories).

You've closed the bug, considering, I imagine, that it is only a doc bug and
that you have now documented it, so end of story.

I don't see it that way.  Emacs is now writing something to arbitrary user
directories.  That is something new and not necessarily always welcome.  Please
consider working on this aspect some more.  Thx.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <12908@debbugs.gnu.org>, <12908-done@debbugs.gnu.org>
> Date: Fri, 16 Nov 2012 11:22:51 -0800
> 
> > It's written in the current directory of the Emacs process, and only
> > if you click NO on the abort dialog.
> 
> I don't understand.  If you click NO then you are saying that you do NOT want to
> participate in debugging the crash.

No, you say that you don't want to attach a debugger.

> Why would Emacs insist in that case in writing a backtrace file for
> debugging to your hard drive?

Don't ask me, I just implemented on Windows what Emacs does on GNU and
Unix platforms.  When this was suggested, I posted a message
describing the disadvantages of this method, see

  http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00501.html

But the feature was implemented nonetheless.  So now it's part Emacs,
on Unix and Windows alike.

> That does not seem very friendly (or useful) on the part of Emacs.

There are gobs of programs writing to your disk right now, without
asking for your permission.  What's so unfriendly in Emacs doing the
same?

> > It contains the call-stack backtrace, which could be used to find the
> > sequence of function calls that led to the crash.  Similar to what GDB
> > produces when you type "bt".
> 
> So it could be used for debugging.  But it is written only if a user says that
> s?he does NOT want to debug the crash.

Yes.  We, the Emacs maintainers, expect you to submit that file for us
to debug the problem.

> > Users should include it with their bug reports.
> 
> Does my having included it in this bug report help in some way?
> I'm guessing no, but would love to be shown wrong.

Your guess is wrong, that file includes enough information to
understand where the crash happened, and in some cases also why.

> > If you have the addr2line.exe program on your disk, you can
> > produce a more readable backtrace from these numbers, see
> > the Emacs user manual for details.
> 
> And if you do not have addr2line?

Then I do.

> Is the backtrace really useful for anyone in that case?  Did the
> backtrace I included here help at all?

Yes.  Anyone with addr2line.exe can run it and recover the source file
names and line numbers where the crash happened.

> > > and control whether and where it is written
> > 
> > You can't.  It's always written in the current directory of the Emacs
> > process, which is normally a single directory determined by what your
> > desktop shortcut says.
> 
> Why not let users decide where the file is written, and record that directory
> (of the process) as part of the file content (or record it elsewhere)?

Because (a) that's how Emacs works on other platforms, and
(b) consulting Lisp when Emacs caught a fatal error is dangerous
(could produce another fatal error).

> Sounds like shades of Unix .core files.

It is, indeed.

> At least there are ways for users to turn off writing such coredumps
> (and even ways to turn that off selectively, for given directories).

Which is bad for maintainers, because users then flood them with
worthless bug reports that cannot be acted upon.

> You've closed the bug, considering, I imagine, that it is only a doc bug and
> that you have now documented it, so end of story.

End of _this_ story, yes.

> I don't see it that way.  Emacs is now writing something to arbitrary user
> directories.  That is something new and not necessarily always welcome.  Please
> consider working on this aspect some more.  Thx.

Then please submit another bug report, which is not Windows specific
and not about the documentation of this file.  If the general Emacs
behavior changes, so will its behavior on Windows.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Drew Adams]

> > Why would Emacs insist in that case in writing a backtrace file for
> > debugging to your hard drive?
> 
> Don't ask me, I just implemented on Windows what Emacs does on GNU and
> Unix platforms.  When this was suggested, I posted a message
> describing the disadvantages of this method, see
>   http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00501.html
>
> But the feature was implemented nonetheless.  So now it's part Emacs,
> on Unix and Windows alike.

Thanks for the background.

> > That does not seem very friendly (or useful) on the part of Emacs.
> 
> There are gobs of programs writing to your disk right now, without
> asking for your permission.  What's so unfriendly in Emacs doing the
> same?

I don't have gobs of programs writing to arbitrary directories, especially
directories with user files.  AFAIK, I have NO programs doing that.

If whether such writing is done cannot be controlled by a user (not good, IMHO),
then Emacs should at least write the information to a "hidden", more or less
"internal" directory, such as .emacs.d.

Putting this stuff willy nilly in user directories is a bad idea, IMO.  Not at
all user-friendly.  (And that's regardless of whether Emacs feels free to do
this on some other platforms.  Emacs being rude elsewhere is not a good excuse
for it to be rude on Windows too.)

> We, the Emacs maintainers, expect you to submit that file for us
> to debug the problem.
> 
> > > Users should include it with their bug reports.
> > 
> > Does my having included it in this bug report help in some way?
> > I'm guessing no, but would love to be shown wrong.
> 
> Your guess is wrong, that file includes enough information to
> understand where the crash happened, and in some cases also why.

That's good news.  Let's hope it helps fix some of the crashing problems.

> > Is the backtrace really useful for anyone in that case?  Did the
> > backtrace I included here help at all?
> 
> Yes.  Anyone with addr2line.exe can run it and recover the source file
> names and line numbers where the crash happened.

Very good.

> > Why not let users decide where the file is written, and 
> > record that directory (of the process) as part of the file
> > content (or record it elsewhere)?
> 
> Because (a) that's how Emacs works on other platforms, and
> (b) consulting Lisp when Emacs caught a fatal error is dangerous
> (could produce another fatal error).

a1. It is Emacs maintainers who decide how Emacs should work - on any platform.

a2. "That's how Emacs works" is false: It is not true in any Emacs release.  It
is true only in code under development that is being _proposed_ for release.
Hardly a "that's just how it is" precedent.

b. Why would Lisp need to be consulted?  But if there is no better alternative,
a user's choice could be recorded in a file that is read before writing
emacs_backtrace.txt.  Of course, you will perhaps say the same thing wrt opening
a file...  I realize that might be problematic.  (But at least it is not rude.)

> > Sounds like shades of Unix .core files.
> 
> It is, indeed.
> 
> > At least there are ways for users to turn off writing such coredumps
> > (and even ways to turn that off selectively, for given directories).
> 
> Which is bad for maintainers, because users then flood them with
> worthless bug reports that cannot be acted upon.

Well, one of the main reasons people prevent coredumps in Unix is that they are
costly in time & space.  That of course does not apply here.

I don't see a crying need to prevent writing these backtrace files.  I do see a
need (a courtesy to users) for letting users decide where to put them.

Or barring that possibility, at least a need to confine them to someplace under
.emacs.d.

> Please submit another bug report, which is not Windows specific
> and not about the documentation of this file.  If the general Emacs
> behavior changes, so will its behavior on Windows.

Done (#12911).  But it is you, not I, who chooses to characterizes this bug as
being about only doc and only MS Windows.  Please reread the subject line.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <12908@debbugs.gnu.org>, <12908-done@debbugs.gnu.org>
> Date: Fri, 16 Nov 2012 12:56:55 -0800
> 
> > > That does not seem very friendly (or useful) on the part of Emacs.
> > 
> > There are gobs of programs writing to your disk right now, without
> > asking for your permission.  What's so unfriendly in Emacs doing the
> > same?
> 
> I don't have gobs of programs writing to arbitrary directories, especially
> directories with user files.  AFAIK, I have NO programs doing that.

Yes, you do.  You just don't know that.  If you are really interested,
you could try walking the process tree with Process Explorer and
looking at the files they have open and amount of I/O on those files.

> > Please submit another bug report, which is not Windows specific
> > and not about the documentation of this file.  If the general Emacs
> > behavior changes, so will its behavior on Windows.
> 
> Done (#12911).  But it is you, not I, who chooses to characterizes this bug as
> being about only doc and only MS Windows.  Please reread the subject line.

The details of the same feature on Unix were already in NEWS and in
the manual, and emacs_backtrace.txt is a Windows-only file name (it
has different names on Unix, as documented in the manual).  So I don't
see how your original report could have been interpreted in any other
way than I did.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Drew Adams]

> > > > That does not seem very friendly (or useful) on the 
> > > > part of Emacs.
> > > 
> > > There are gobs of programs writing to your disk right now,
> > > without asking for your permission.  What's so unfriendly
> > > in Emacs doing the same?
> > 
> > I don't have gobs of programs writing to arbitrary 
> > directories, especially directories with user files.
> > AFAIK, I have NO programs doing that.
> 
> Yes, you do.  You just don't know that.  If you are really interested,
> you could try walking the process tree with Process Explorer and
> looking at the files they have open and amount of I/O on those files.

Let me put it this way, since I haven't been able to make it clear enough so
far: I do not _se+_ files created in my user folders.  If there are such files
created, whether temporarily or permanently, I am unaware of it.  Not so with
emacs_backtrace.txt files.

That is the point: the behavior that users witness - the user experience.  I
will not argue with you that there no such files are ever created by other
programs.  I will say that I don't see any such.

Nothing about what other programs are doing is annoying in this respect.  If you
want to make Emacs not be annoying in the same way, please do.

It is the user-level annoyance that this bug report is about.  Users do not know
or care about the implementation level at which you are examining the issue.

Your answers do not address the issue, which is user annoyance at the _obvious_
creation of uninvited files in their folders.  You may prove that I
misunderstand this or that about what other programs do under the covers, but
you are missing the point: what users see (and will be annoyed by).

> > > Please submit another bug report, which is not Windows specific
> > > and not about the documentation of this file.  If the 
> > > general Emacs behavior changes, so will its behavior on Windows.
> > 
> > Done (#12911).  But it is you, not I, who chooses to 
> > characterizes this bug as being about only doc and only
> > MS Windows.  Please reread the subject line.
> 
> The details of the same feature on Unix were already in NEWS and in
> the manual, and emacs_backtrace.txt is a Windows-only file name (it
> has different names on Unix, as documented in the manual).  So I don't
> see how your original report could have been interpreted in any other
> way than I did.

Even when the OP informs you that your interpretation is wrong (too limited)?
Anyway, there is now another bug for the annoyance, and thank you for
documenting the annoyance.  I have no problem with splitting the bug report that
way.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Paul Eggert]

There seems to be some misunderstanding here.  The Unix code does
not write into $HOME/backtrace.txt, or into $HOME, or into anywhere
like that.  It writes to stderr.  The programs that invoke Emacs
(normally window managers) arrange for the standard error stream
to be sent to a suitable place.

The Microsoft Windows code does something different: it writes the
backtrace both to stderr and to a file emacs_backtrace.txt.

If the goal is to mimic the Unix behavior as closely as possible, then
the fix should be simple: output the backtrace just to stderr, as
the Unix code does.  Perhaps there are reasons not to do that
on Microsoft Windows, but as these reasons are specific to that
platform it would seem that any fix would be platform-specific
as well.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Eli Zaretskii]

> Date: Sat, 17 Nov 2012 10:45:00 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> There seems to be some misunderstanding here.  The Unix code does
> not write into $HOME/backtrace.txt, or into $HOME, or into anywhere
> like that.  It writes to stderr.  The programs that invoke Emacs
> (normally window managers) arrange for the standard error stream
> to be sent to a suitable place.

That suitable place is in a subdirectory of the user's home directory,
at least on the most popular systems, according to the Emacs manual.

> The Microsoft Windows code does something different: it writes the
> backtrace both to stderr and to a file emacs_backtrace.txt.

Yes.

> If the goal is to mimic the Unix behavior as closely as possible, then
> the fix should be simple: output the backtrace just to stderr, as
> the Unix code does.

This will not work: unlike Unix, a GUI program invoked on Windows
from a desktop icon normally has its standard error stream closed.  So
writing there will end up nowhere.  That is why my implementation
writes both to stderr and to the file; in the worst (or best?) case,
you have two copies of the information, but you always have at least
one.

> Perhaps there are reasons not to do that on Microsoft Windows, but
> as these reasons are specific to that platform it would seem that
> any fix would be platform-specific as well.

I don't see it that way.  If what the Unix code writes to stderr ends
up in some random location under the user's home directory, or even in
a place whose whereabouts no one knows, then I see no reason not to
write it on Windows in the current directory of the Emacs process.
(Note that unlike on Unix, Emacs on Windows doesn't change its current
directory from where it was started, so the backtrace will normally
end up in the same directory for all invocations of Emacs on that
machine by that user.)

If we want the information in .emacs.d, we need to actively write it
there on Unix.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Paul Eggert]

On 11/17/2012 11:09 AM, Eli Zaretskii wrote:

> That suitable place is in a subdirectory of the user's home directory,
> at least on the most popular systems, according to the Emacs manual.

Sure, but it's under the user's control, and it's easy to
change the default.  I'm not a typical user, but I'd guess
that about half the time I put stderr some place other
than the default, because I start up Emacs from a terminal
session or suchlike.  And when Emacs is being debugged, stderr
is almost never put into a home-directory file.

> unlike Unix, a GUI program invoked on Windows
> from a desktop icon normally has its standard error stream closed.

This is a problem not just for backtraces, but for everything that
Emacs sends to stderr.  Perhaps it would be better for Emacs, on
Microsoft Windows, to redirect stderr to a file, so that the information
does not get lost.  That file would serve the function that
emacs_backtrace.txt serves now, but it would also capture all the
other stuff that goes to stderr and currently gets lost.

Even if we continue to restrict the contents of the file to
backtraces, the name of this file is something that is specific
to the Microsoft Windows version of Emacs, so the GNU and Unix versions
don't have to worry about the file's name.

> (Note that unlike on Unix, Emacs on Windows doesn't change its current
> directory from where it was started

No, Emacs is the same on both platforms.  The main Emacs process doesn't
invoke chdir on GNU or Unix either, unless you use the --chdir option.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Eli Zaretskii]

> Date: Sat, 17 Nov 2012 11:29:47 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 12908@debbugs.gnu.org
> 
> On 11/17/2012 11:09 AM, Eli Zaretskii wrote:
> 
> > That suitable place is in a subdirectory of the user's home directory,
> > at least on the most popular systems, according to the Emacs manual.
> 
> Sure, but it's under the user's control, and it's easy to
> change the default.

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.

> > unlike Unix, a GUI program invoked on Windows
> > from a desktop icon normally has its standard error stream closed.
> 
> This is a problem not just for backtraces, but for everything that
> Emacs sends to stderr.

Which is nothing on Windows, except in debug builds with non-default
options turned on, which are used only by experts (who know how not to
lose this stuff).

> Perhaps it would be better for Emacs, on Microsoft Windows, to
> redirect stderr to a file, so that the information does not get
> lost.

It's not easy to do that, and it isn't worth the trouble, see above.
But if someone volunteers to do that, my hat's off.  Until then, we
cannot safely use stderr on Windows for information we cannot afford
losing.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Paul Eggert]

On 11/17/2012 11:42 AM, Eli Zaretskii wrote:

> 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 under the
assumption that Emacs itself redirects stderr to a file
whose name Emacs chooses.  That assumption is currently true on
Microsoft Windows for backtraces, but it's not true for GNU and Unix
where we don't have the problem.

>> Perhaps it would be better for Emacs, on Microsoft Windows, to
>> redirect stderr to a file, so that the information does not get
>> lost.
> 
> It's not easy to do that

Can Emacs use freopen?  For example, the
following code would do the job on a POSIX platform:
if stderr is closed, it redirects it to emacs-stderr.txt
in the current directory, if possible.  Would this sort of thing
work on Microsoft platform?

=== modified file 'src/emacs.c'
--- src/emacs.c	2012-11-08 19:12:23 +0000
+++ src/emacs.c	2012-11-17 21:23:46 +0000
@@ -748,6 +748,11 @@ main (int argc, char **argv)
     unexec_init_emacs_zone ();
 #endif
 
+#ifdef DOS_NT
+  if (dup2 (STDERR_FILENO, STDERR_FILENO) < 0)
+    ignore_value (freopen ("emacs-stderr.txt", "a", stderr));
+#endif
+
   atexit (close_output_streams);
 
   sort_args (argc, argv);

bug#12911: bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Drew Adams]

> > 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

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Paul Eggert]

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

Ah, OK, I'll respond there.

bug#12911: bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Paul Eggert]

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 <http://bugs.gnu.org/12911#11> 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.

bug#12911: bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Eli Zaretskii]

> Date: Sat, 17 Nov 2012 17:19:57 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Eli Zaretskii <eliz@gnu.org>, 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 <http://bugs.gnu.org/12911#11> 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.

bug#12911: bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> 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.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Eli Zaretskii]

> Date: Sat, 17 Nov 2012 13:25:17 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 12908@debbugs.gnu.org
> 
> >> Perhaps it would be better for Emacs, on Microsoft Windows, to
> >> redirect stderr to a file, so that the information does not get
> >> lost.
> > 
> > It's not easy to do that
> 
> Can Emacs use freopen?

That's not the problem.  The problem is that stderr is used when Emacs
is run in non-interactive mode, and should not be touched then.  The
problem is in detecting when stderr is closed or an invalid handle to
begin with, and do the redirection only then.  In all my readings and
tests, I was unable to find a reliable, let alone documented, way of
determining that.  I don't even know if the "invalid handle" (which is
a pointer on Windows) is NULL or an INVALID_HANDLE_VALUE.

> For example, the following code would do the job on a POSIX
> platform: if stderr is closed, it redirects it to emacs-stderr.txt
> in the current directory, if possible.  Would this sort of thing
> work on Microsoft platform?

It will surely break -batch.  And guess what happens with this
redirection when Emacs has its stderr closed or invalid in the first
place.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Paul Eggert]

On 11/17/2012 08:04 PM, Eli Zaretskii wrote:
> The
> problem is in detecting when stderr is closed or an invalid handle to
> begin with, and do the redirection only then.  In all my readings and
> tests, I was unable to find a reliable, let alone documented, way of
> determining that.

The method I gave in <http://bugs.gnu.org/12908#73>
is portable to GNU and POSIXish hosts, where you can test whether
a file descriptor FD is valid by invoking dup2 (FD, FD).
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.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> Date: Sat, 17 Nov 2012 21:19:36 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> 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.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Paul Eggert]

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.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> Date: Sun, 18 Nov 2012 11:18:29 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> 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.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Stefan Monnier]

>> 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"

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> 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.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Drew Adams]

(I see that everyone is using the original bug thread, even though I created a
new one at Eli's request, and the original one was supposedly closed (doc
fixed).)

> (Note that unlike on Unix, Emacs on Windows doesn't change its current
> directory from where it was started, so the backtrace will normally
> end up in the same directory for all invocations of Emacs on that
> machine by that user.)
> 
> If we want the information in .emacs.d, we need to actively write it
> there on Unix.

On Windows, I believe that some (many? most?) users start Emacs from a shortcut,
and that some (many? most?) of those start it in a directory that has meaning
for them, e.g., a directory of user files.

(I, for example, start it in a directory of my Emacs Lisp files, and I open it
with Dired there.)

Is the situation similar on Unix?  Do users often start Emacs in a user
directory?

It's one thing to stick the backtrace file in the startup directory if that is
the default Emacs bin directory or some such Emacs-related folder.  It's another
thing to stick the file in a user directory because the user intentionally
starts Emacs there.

That has been my point from the beginning: I don't really care where you stick
it, as long as it is in some Emacs/system internal program folder and not a user
folder.

There is a reason why programs on Windows are often installed (and started) in
an application-specific folder under `Program Files', and not in any old user
folder.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Paul Eggert]

On 11/17/2012 03:01 PM, Drew Adams wrote:
> Is the situation similar on Unix?  Do users often start Emacs in a user
> directory?

Yes, that's common.  But it doesn't lead to backtrace
files appearing in user directories, because Emacs does
not create backtrace files on Unix; it merely writes the
backtraces to stderr.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <12908@debbugs.gnu.org>
> Date: Sat, 17 Nov 2012 15:01:40 -0800
> 
> That has been my point from the beginning: I don't really care where
> you stick it, as long as it is in some Emacs/system internal program
> folder and not a user folder.

On Unix, the data winds up in some directory under user's home
directory.  See the manual.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Drew Adams]

> > That has been my point from the beginning: I don't really care where
> > you stick it, as long as it is in some Emacs/system internal program
> > folder and not a user folder.
> 
> On Unix, the data winds up in some directory under user's home
> directory.  See the manual.

I don't care what Emacs does on Unix or on Windows.  Or on Peanut Butter.  See
the manual - sheesh.  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.

My point is the same: Please do not plop such a file into a user folder.  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.

You are discussing implementation and platforms, as well you should, no doubt.
But 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.

I really don't care about the finger-pointing.  You apparently claim that there
is as much of this problem on Unix as on Windows.  Some others seem to disagree
(though that's not too clear to me).

That does not matter to me.  If there is a problem on platform XYZ, please fix
it on XYZ.  For all XYZ, preferably.  For Windows, at least.

It does not sound like a great argument to say that this will not be fixed on
Windows until someone agrees to fix it on Unix also.  Especially if those who
would presumably be the ones to fix it on Unix do not seem to agree that it is a
problem on Unix (again, I'm not sure that's what the claim is).

IOW, here we go 'round & 'round again.  Musical chairs with a bit of blame game
thrown in, it seems.

I hope the bug gets fixed.  On Windows, at least, this is a regression: Users
have never before had to put up with this Emacs pollution of user folders.
Introducing a regression and then classifying it as `wont-fix' is disingenuous.

Please just restore the state before the regression if you cannot find a good
way to fix the bug and still get the backtrace info you want.  Restore the sane
state while you go on to discuss possible ways to deal with the problem in a
ideal way.  If you never find that ideal way, then leave things as they were
before.

I really do not agree with freewheeling introduction of "improvements" that are
accompanied by regressions or other negative behavior that is then classified as
`wont-fix'.  Be less interested in your creative development than in the
possible harm/annoyance to users of its side effects.

The first rule should be not to do any harm.  The second rule should be that if
you accidentally do some harm while trying to improve something, then undo the
harm.

We have users jump through 39 questions/confirmations just to send a bug-report
message or exit without saving a buffer.  Nice and careful, respectful of user
wishes.  And yet here we are now writing crap to user folders without so much as
a "Do you really want to...?" - or even a "Hey, I just wrote some crap to your
folder XYZ - sorry about that!"

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <eggert@cs.ucla.edu>, <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.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Drew Adams]

> > 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.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Paul Eggert]

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.

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.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> 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.

bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Achim Gratz]

Eli Zaretskii writes:
> On Unix, the data winds up in some directory under user's home
> directory.  See the manual.

That happens only if STDERR is redirected to a file, which is indeed
commonly the case when a wrapper script starts Emacs on a GUI.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds