Attempt to use tex-file crashes Emacs, etc. (Was: Is this the place to see if a bug has been fixed?)

[Joe Fineman]

On 15 March, Eli Zaretskii replied to my inquiry:

> > Newsgroups: gnu.emacs.bug
> > From: Joe Fineman <jcf@TheWorld.com>
> > Date: Thu, 14 Mar 2002 22:20:32 GMT
> > 
> > Some months ago, after an inquiry on gnu.emacs.help, I was
> > encouraged to file a bug report.  I did so, was asked for
> > clarification, and provided it.  I now wonder how I find out if &
> > when the bug has been fixed.  Harrassing the person I communicated
> > with is presumably not in order.  On the other hand, I see no
> > announcements of that kind here, or any mention in the manual of
> > where to look.  What am I missing?

> We don't always announce bugfixes.  If you submitted a patch, you
> can see if the patch was applied via anonymous CVS access to the
> Emacs development sources (go to
> http://savannah.gnu.org/projects/emacs and follow the link to
> "CVS").  You can also download and build the current CVS version,
> and see if the bug is still there.

I'm afraid I don't belong anywhere on the continuum "from individual
developers to large distributed teams".  I can only vaguely guess what
a version control system is.

> Finally, you can ask here (but please provide the necessary details
> about the original bug report, so that we could find it in the
> records).

Thank you.

I sent the original bug report, under the title "Attempt to use
tex-file crashes Emacs", to bug-gnu-emacs@gnu.org on 14 December 2001.
I sent the requested clarification, plus additional information, to Mr
Zaretskii on 27 January.  Here it is again:

----------------------------------------------------------------------

On 16 Dec 2001, Eli Zaretskii wrote:

> On 14 Dec 2001, Joe Fineman wrote:

> > When I attempt to use tex-buffer in latex mode, Emacs freezes
> > (goes into an infinite loop).

> ``Freezes'' and ``goes into an infinite loop'' are two different
> things.  Please tell which one is it, and how did you verify that
> it's not the other.

I am sorry that this sentence did not adequately summarize the
information given in the rest of the report.  In Emacs 20.4.1 (as
reported by Bas Michelsen) and in Emacs 20.7.1 (as experienced by me),
it froze; that is, nothing I did with the keyboard or mouse had any
effect.  In Emacs 21.1, it went into an infinite loop, which could be
interrupted with ctrl-G and examined with the debugger as described.

> Does C-g still produce a backtrace you reported a few months ago,
> similar to this:

> > * sleep-for(1)
> > * tex-start-shell()
> > * tex-region(1 77)

> ?  If you see a different backtrace, please post it.

Yes.  More specifically,

  Debugger entered--entering a function:
  * sleep-for(1)
  * tex-start-shell()
  * tex-region(1 113)
  * byte-code("ž�ž��ed\"ž�" [tex-region] 3)
  * tex-buffer()
  * call-interactively(tex-buffer)

> > If you need the actual .tex file that I was trying to run, let me
> > know.

> Does it happen with any TeX file, or just with this specific one.

Any TeX file.  In my recent tests I have been using the following one:

  \documentclass[10pt]{article}
  \begin{document}
  This is a test.

  $$A=\pi r^2.$$

  This is the end.
  \end{document}

> > I am not a programmer.  Does this behavior suggest anything to
> > anyone who is?  Is the fact that my Emacs quasi shell is Cygwin
> > perhaps relevant?

> Yes, it is relevant: there are known problems with running async
> subprocesses when the Cygwin port of Bash is involved; see
> etc/PROBLEMS for more details.

As suggested there, I tried

 (setq ange-ftp-ftp-program-args '("-i" "-n" "-g" "-v" "--prompt" ""))

The results were as follows:

----------------------------------------------------------------------
Running on the file ~/tex/Test.tex, tex-buffer causes the EMACS icon
in the toolbar at the bottom to turn dark blue and flash several
times.  There is a message in the minibuffer:

Wrote c:/usr/own/f/Tex/_TZ_870401-OEMCOMPUTER.tex

The icon stays blue and seems to be selected.  Selecting the Emacs
buffer again with the mouse, I find Emacs hung (no keys do anything).
Ctrl-G interrupts the hang.  The above-created file consists of
Test.tex plus a newline plus an extra \end{document}.  TeX has not
run.

This experiment made a mess of Emacs: it had a long fill prefix (69
spaces) that I couldn't get rid of.  Killed & restarted Emacs.  The
next trial of TeX-buffer yielded the old behavior: it hung (cursor
disappeared), but responded to ctrl-G with no other action.  However,
when I reevaled the new setq in .emacs, it went back to the blinking
behavior, this time creating _TZ_862677-OEMCOMPUTER.tex, which
consisted of Test.tex plus a newline plus the line "\bye".  This
behavior was stable.

Tried the program-name reset instead.  Same behavior.  N.B. Neither
variable existed previously.
----------------------------------------------------------------------

I did not pursue this remedy further.

> Could you try a different shell?

A friend of mine temporarily substituted mks toolkit for cygwin.  The
behavior was the same.

> Also, what port of TeX do you use?  Is it also a Cygwin port?  If
> so, I'd suggest a native Windows port, like fpTeX.
 
I'm sorry; I don't understand this.

However, I did some further exploration and discovered that the above
behavior (going into an infinite loop) occurs only the first time that
tex-buffer is invoked in an Emacs session.  If, after interrupting the
loop with ctrl-G, I try ctrl-C ctrl-B again, the result is that LaTeX
runs.  The appropriate files are created, and the buffer *tex-shell*
is displayed.  At that point, once again, the keyboard is inactivated.
However, clicking on the Emacs window with the mouse restores the
keyboard.  Thereupon, I can do ctrl-C ctrl-B, and LaTeX runs again,
adding a new report to the *TeX-shell* buffer.

Pushing my luck, I tried ctrl-C ctrl-P (TeX-print).  This resulted in
the appearance of "lpr -d" in the *tex-shell* buffer, but not in any
actual printing.  However, an informative but not interactive popup
window appeared, beginning

  winlpr  -S<servername>
          -P<printername>
          [-N]UserName
  [...]

I do not know what to do with that.  However, I tried ctrl-C ctrl-Q
(TeX-show-print-queue).  That merely inactivated the keyboard again.
The mouse did not restore it, but ctrl-G did.

A dribble file for such an experiment follows:

~/tex/Test.tex<return>  
<backspace><backspace><help-echo><down-mouse-1><mouse-1><help-echo><down-mouse-1><mouse-1><help-echo><down-mouse-1><mouse-1>
 

At this point it seems reasonable to ask what would be worth trying
next.

------------------------------------------------------------------------ 

Thank you for your attention.
-- 
---  Joe Fineman    jcf@TheWorld.com

||:  First you go to hell, then your body rots, and then you die.  :||