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

Reply via email to