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.