* David Kastrup (2006-01-13) writes: > 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: [...] > -)+\\( \\|\r?$\\)\\|\ > +)+\\([ >]\\|\r?$\\)\\|\ [...] > 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.
I'd rather poke myself with a stick in the eye. I saw that you already checked in the change. If it is working like that, i.e. with a general solution, we could just keep it. Unfortunately I am short of a recent PDFTeX for testing. I thought about trying the TeXLive 2005 packages for Debian, but then I don't want to risk my currently working teTeX installation. )c: And I _really_ _don't_ want to boot into Windows in order to see what MikTeX has to offer. > Which reminds me: we should have the error/line style error messages > work out as well. "as well" like in "_both_ file/line/error _and_ normal messages should work"? > And fold this with AUCTeX's error line matching. > Sigh. Come on. What fun would there be in working on AUCTeX if it were perfect? -- Ralf _______________________________________________ bug-auctex mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-auctex
