Ralf Angeli <[EMAIL PROTECTED]> writes: > * 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.
Ah, but the overall goal is not to maximize your private level of happiness. > 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. "With a general solution"? What's that supposed to mean? >> 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"? Have you taken a look at file/line error messages? They don't replace the standard messages but sneak in an _additional_ line. We just need to make our error message patterns skip this additional line. Except that this additional line also provides the file information that we constantly get tripped up trying to fish out among all the junk output. So a second step would be to make use of those messages (a third step would be to recommend configuring your TeX appropriately, and a fourth step would do so automatically when possible). But as a first step, it would be nice if we could skip them without tripping up. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ bug-auctex mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-auctex
