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.