auctex
[Top][All Lists]
Advanced

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

Re: [AUCTeX] Re: TeX-next-error takes me to the supp-pdf.tex buffer


From: Ralf Angeli
Subject: Re: [AUCTeX] Re: TeX-next-error takes me to the supp-pdf.tex buffer
Date: Sun, 01 Apr 2007 17:33:56 +0200
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.96 (gnu/linux)

* Ralf Angeli (2007-03-31) writes:

> * mirko vukovic (2007-03-30) writes:
>
>>> > When I try to go to the next error, I end up in the supp-pdf.tex 
>>> > buffer.  I have not seen this discussed in the archive.
> [...]
>> It is the tikz package that causes the problem when compiling with
>> pdflatex.  If I compile it with latex, C-c ` works fine.
>
> I don't even come as far as having supp-pdf.tex being displayed since
> error parsing cannot handle a quoted file name with spaces. )c:
>
> The output buffer contains stuff like
>
> tex"))) (tikz-test.aux) ("C:\Programme\MiKTeX 
> 2.5\tex\context\base\supp-pdf.tex
> "
> [Loading MPS to PDF converter (version 2006.09.02).]
> ) [1{psfonts.map}]
> ! Misplaced alignment tab character &.
> l.15 *&
>        ^*
> ! Missing $ inserted.
> <inserted text> 
>                 $
>
> and when parsing the file name after the second opening paren it stops
> after "MiKTeX".  That means something like "\"C:\\Programme\\MiKTeX"
> is pushed onto `TeX-error-file'.  That means the file in question will
> be found as "MiKTeX" and the directory part will be ""C:\Programme".
> Ouch.

The following patch fixes the bug for me:

--- tex-buf.el  04 Mar 2007 19:38:47 +0100      1.258
+++ tex-buf.el  01 Apr 2007 17:17:13 +0200      
@@ -1347,12 +1347,7 @@
         ((null (re-search-forward
                 "\
 ^\\(!\\|\\(.*?\\):[0-9]+:\\) \\|\
-\(\\(/*\
-\\(?:\\.+[^()\r\n{} /]*\\|[^()\r\n{} ./]+\
-\\(?: [^()\r\n{} ./]+\\)*\\(?:\\.[-0-9a-zA-Z_.]*\\)?\\)\
-\\(?:/+\\(?:\\.+[^()\r\n{} /]*\\|[^()\r\n{} ./]+\
-\\(?: [^()\r\n{} ./]+\\)*\\(?:\\.[-0-9a-zA-Z_.]*\\)?\\)?\\)*\\)\
-)*\\(?: \\|\r?$\\)\\|\
+\\((\\)\\|\
 \\()\\))*\\(?:[ >]\\|\r?$\\)\\|\
  !\\(?:offset(\\([---0-9]+\\))\\|\
 name(\\([^)]+\\))\\)\\|\
@@ -1396,9 +1391,18 @@
 
         ;; New file -- Push on stack
         ((match-beginning 3)
-         (push (TeX-match-buffer 3) TeX-error-file)
+         (let ((quoted (= (syntax-class (syntax-after (point))) 7)))
+           (push (buffer-substring-no-properties
+                  (if quoted (1+ (point)) (point))
+                  (progn
+                    (if quoted
+                        (progn
+                          (forward-sexp)
+                          (skip-syntax-backward "\" "))
+                      (skip-syntax-forward "w._\\"))
+                    (point)))
+                 TeX-error-file))
          (push nil TeX-error-offset)
-         (goto-char (match-end 3))
          t)
         
         ;; End of file -- Pop from stack
With the patch applied the end of a file name is not determined
anymore by a regexp but by functions, and the quoted case is
distinguished from the non-quoted one.

This is just proof-of-concept code.  I'll have to check if it makes
more sense to use a special syntax table instead of skipping over
characters with various syntax classes.  And perhaps the preview-latex
error parser should be merged before doing all that.

That leaves us with the wrong file being found.  In the output shown
above the closing paren in "(version 2006.09.02)." is not found
because the regexp for matching closing parens requires it to be
followed by ">" or by a space.  If we match any opening paren we might
also want to match any closing paren.  So perhaps the mentioned
restriction should be removed from the regexp.

Mail-Followup-To: address@hidden

-- 
Ralf

reply via email to

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