Ralf Angeli <[EMAIL PROTECTED]> writes:
> * Christian Faulhammer (2006-01-13) writes:
>
>> This is pdfeTeXk, Version 3.141592-1.30.4-2.2 (Web2C 7.5.5) (INITEX)
> [...]
>> [2 <./1-1.png (PNG copy)>]
> ^^^^^^^^^^
>
> Your version of PDFTeX injects strings in its output which
> preview-latex cannot cope with yet.
Didn't we actually fix this particular one yet? Hmm. Seemingly not.
A sort of "least invasive" change would be:
--- preview.el 24 Sep 2005 23:21:48 +0200 1.262
+++ preview.el 13 Jan 2006 22:56:25 +0100
@@ -2619,7 +2619,7 @@
(re-search-forward "\
\\(^! \\)\\|\
\(\\([^()\r\n{ ]+\\))*\\(?:{[^}\n]*}\\)?\\(?: \\|\r?$\\)\\|\
-)+\\( \\|\r?$\\)\\|\
+)+\\([ >]\\|\r?$\\)\\|\
!\\(?:offset(\\([---0-9]+\\))\\|\
name(\\([^)]+\\))\\)\\|\
^Preview: \\([a-zA-Z]+\\) \\([^\n\r]*\\)\r?$" nil t)
Butt-ugly. What we probably should do instead is to keep a list of
every (xxx combination and every ) in any context, and then whenever
we actually match with source lines, we try to figure out which of the
( and ) actually made sense. Yes, this does not sound like too much
fun.
Which reminds me: we should have the error/line style error messages
work out as well. And fold this with AUCTeX's error line matching.
Sigh.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
_______________________________________________
bug-auctex mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-auctex