Re: [AUCTeX-devel] bug and fix for problem in style/pdfsync.el

[Matan Ninio]

Ralf Angeli <address@hidden> writes:

> * Matan Ninio (2008-02-24) writes:
>
>> There seems to be a bug with pdfsync.wl (from 2005-12-28, which was my
>> 35th birthday BTW).  When using files "\input"-ed from the master file,
>> but which happen to be in a different directory, the search of the
>> relevant section of the MASTER.pdfsync file fails.  This is due to
>> pdfsync.sty writing the inputed filenames with a path relevant to the
>> location of the master file, while pdfsync.el-s
>> LaTeX-pdfsync-output-page searches for the file name only (without
>> either the relative path of the extension).  Here is my version of the
>> function, which seems to fix this problem and works well when the
>> inputed files are either in the same directory or in subdirectories.
>
> Can you please prepare and send a test case for reproducing the error as
> well as a diff against the current CVS version accompanied by a
> ChangeLog entry?
>
> -- 
> Ralf

Test case:

pdfsyncProblem.tgz
Description: GNU Unix tar archive

Latex document in two directories - kkk.tex in top directory, inputing
subdir/kkk2.tex and subdir/kkk3.tex from the "subdir" subdirectory.

When compiled with pdfsync.sty and pdflatex, kkk.pdfsync is created
(attached in the tar).  TeX-view works fine within kkk.tex, but brings
page number 1 in any line of kkk2.tex or kkk3.tex.

Three distinct problems have been identified.
1: filenames in the .pdfsync file are relative to the directory of the
master file, while pdfsync.el assumes they are sans-directory.  (file$
is therefor not found.  See line marked "problem no1" in kkk2.tex.

2. when searching for a line at the end of an inputed file (or in a
short input file), there may be no "p" or "s" lines generated yet. The
"l" line is therefor found, but search of the corresponding "p" and "s"
lines is done within the output from the inputed file (from "^(file$" to
"^)$"), where no such lines exist.  Causes the view to jump to the first
page of the full file.  See line marked "problem no2" in kkk2.tex

3. the "\input{}" line in latex may be in one of two forms -
"\input{subdir/kkk2}" or "\input{subdir/kkk3.tex}".  Both work fine in
latex, but the latter fails in pdfsync, as the filenames in the .pdfsync
are assumed to be sans extension. See line marked "problem no3" in
kkk3.tex.

diff to version is CVS (1.5):

35c35,37
<   (let* ((line (TeX-line-number-at-pos))
---
>   (let* ((file (file-name-sans-extension
>               (file-name-nondirectory (buffer-file-name))))
>        (line (TeX-line-number-at-pos))
37d38
<        (file (file-name-sans-extension (file-relative-name (buffer-file-name) 
(file-name-directory master))))
49c50
<           (re-search-forward (concat "^(" file "\\(.tex\\)?$") nil t)
---
>           (re-search-forward (concat "^(" file "$") nil t)
69d69
<         (widen)

Changelog:
* "file" is now relative to the location of the master file, in case the
inputed tex file is in a different directory.
* Searching for the file entry in the .pdfsync file allows for an
optional ".tex" extension in the filename, in case the file was included
using "\input{dir/filename.tex}".
* narrow-to-region is canceled by (widen) prior to searching for
corresponding "p" lines, as lines in the very bottom of included files
may produce "p" lines only after the file was closed.  In such cases,
the "p" and "s" lines will appear outside the scope of the "(file..)" we
narrowed to earlier.
Changes by Matan Ninio <address@hidden>


My version:

pdfsync.el
Description: application/emacs-lisp

-- 
Matan Ninio                                                       
--------------------------------+----------------------------------
Contrary to popular belief, Unix is user friendly.  It just happens
to be selective about who it makes friends with.  -- Dave Parnas