auctex
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AUCTeX] Inverse search with Emacs/AUCTeX


From: David Kastrup
Subject: Re: [AUCTeX] Inverse search with Emacs/AUCTeX
Date: Tue, 26 Sep 2006 16:04:57 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Alan Ristow <address@hidden> writes:

> A couple of us on the MiKTeX users list have been having a problem with
> Emacs/AUCTeX and inverse search from the DVI viewer Yap. We're both
> using the Emacs 22/AUCTeX 11.83 bundle.
>
> Inverse search works fine if the entire document is contained in a
> single file. That is, if I have a file called article.tex that uses no
> \input or \include commands then I have no problem with inverse
> search. However, if I use \input or \include commands I have
> problems. Suppose I say:
>
> \input{mychapter}
>
> LaTeX, of course, reads this and searches for a file called
> mychapter.tex to add to the document. If I do an inverse search on a
> piece of text from mychapter.tex, however, Emacs creates a new buffer
> called mychapter (without the .tex extension) and the inverse search
> ends in this empty buffer.
>
> We tracked the problem to the source special embedded in the DVI,
> which itself does not have the .tex extension (e.g.,
> c:\files\mychapter). Thus, the filename provided to Emacs during the
> inverse search does not have the .tex extension, and unless AUCTeX or
> Emacs adds it implicitly it seems that Emacs cannot possibly find the
> correct file.
>
> The inverse search command I am using is:
>
> gnuclientw.exe -F +%l "%f"
>
> (In the Windows version of gnuclient the -F switch pops the Emacs
> window to the top of all the other windows.) If I say:
>
> \input{mychapter.tex}
>
> inverse search works correctly with Emacs. That is, it loads the file
> mychapter.tex into a buffer and selects the correct line. While this
> is a useful workaround, it is at odds with LaTeX convention to leave
> the file extension off.
>
> By way of comparison, WinEdt opens the correct file and finds the
> appropriate line with no problem whether I use \input{mychapter} or
> \input{mychapter.tex}. FWIW, the inverse search command line for
> WinEdt is:
>
> winedt.exe "[Open(|%f|);SelPar(%l,8)]"
>
> This is exactly analogous to the gnuclient command line above, but
> WinEdt seems to compensate for the implied .tex extension.
>
> The two of us who are discussing this are both using the new MiKTeX
> 2.5 and I have no idea whether this was a problem under MiKTeX
> 2.4. The other user having this problem reported it as a MiKTeX bug,
> but was told by MiKTeX developer Christian Schenk that embedding
> source specials as written in the \input command (i.e., without the
> .tex extension unless explicitly written) is in keeping with the LaTeX
> specification and that this is therefore not a bug in MiKTeX.

This is wrong.  LaTeX itself does not specify anything like source
specials.  However, before TeX executables ever gained this capability
"natively", there was an implementation srcltx.sty that created such
specials by using TeX internal hooks.

This is the _definitive_ implementation for Source Specials, and it
goes to considerable pains to add the ".tex" extension into the
specials if it is not speciified by \input.

The change in MikTeX 2.5 therefore is a _deliberate_ deviation from
the syntax that has been established previously and that is used if
you use the srcltx package which has been the one defining the format
of Source Specials before anybody else did.

> So is this an Emacs/AUCTeX bug? Is there a setting that I've missed
> (or perhaps undone with something I've put in my .emacs file)?

I consider this a MikTeX bug.  I don't see a point in this deliberate
change and deviation from an established and useful standard practice
used everywhere else and in previous versions of MikTeX.

There is no sense whatsoever that other tools should start guessing
the file name expansion rules of some TeX executable (xxx. xxx
xxx.tex? xxx.tex xxx xxx.?).

This is a unilateral change for the worse in MikTeX 2.5 and nowhere
else.

Feel free to forward my opinion to Christian Schenk.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

[Prev in Thread] Current Thread [Next in Thread]