bug-auctex
[Top][All Lists]
Advanced

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

Re: [Bug-AUCTeX] 11.82; image inclusion prevents following previews from


From: David Kastrup
Subject: Re: [Bug-AUCTeX] 11.82; image inclusion prevents following previews from being displayed
Date: Sat, 14 Jan 2006 16:34:21 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Ralf Angeli <address@hidden> writes:

> * David Kastrup (2006-01-14) writes:
>
>> Ralf Angeli <address@hidden> writes:
>>
>>> * David Kastrup (2006-01-13) writes:
>>>
>>>> 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.
>
> Yeah, but mine is.  Now please hand me a stick.

No fun for me.

>>> 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?
>
> That's how I understood your change in preview.el.  Doesn't it prevent
> preview-latex from choking on "(PNG copy)"?  (As I've mentioned
> before, I cannot check it.)

No, it prevents preview-latex from choking on "(PNG copy)>" by letting
it misunderstand "(PNG " and letting it recover by misunderstanding
"copy)>" again.

The problem is what kind of opening parens and what kind of closing
parens we are going to take as gospel.  I don't see a sane way around
accepting "(PNG ", so I have to accept ")>" as well given that we have
to deal with the [expletive deleted] new output ideas from PDFTeX.  It
is not like AUCTeX is the only TeX shell with that problem, so I
consider this a bit of an inconsideration on part of the PDFTeX
developers.

>>>> 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.
>
> Ah, now I got it.  Besides the stick you may hand me a pair of
> scissors for shortening my long line.  (You need me not to say that
> the outprint "a long line to have" not in English exists.)

I am afraid that this play on German will be incomprehensible to most
readers of this group.  Including myself, by the way.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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