[Top][All Lists]

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

Re: [AUCTeX-devel] New error parsing

From: Mosè Giordano
Subject: Re: [AUCTeX-devel] New error parsing
Date: Tue, 29 Mar 2016 15:56:56 +0200

Hi Tassilo,

is there a particular reason why you used `memql' in
`TeX-format-filter', file tex-buf.el line 1766 in current git HEAD?
XEmacs doesn't have it and I think that both memq and member would
work (with the former probably being a bit faster than the latter).


2016-02-25 21:04 GMT+01:00 Tassilo Horn <address@hidden>:
> Mosè Giordano <address@hidden> writes:
>>>> where [7] is the page where the bad box occurred, if I got it right.
>>>> Ok, this message is pretty useless as it is because it doesn't
>>>> provide the offending file and line, but nevertheless I think we
>>>> should catch it.
>>> And where would we jump to if there's no information on the location?
>> It jumps in the referenced file but point is not moved, see
>> `TeX-find-display-help'.  I think users should be aware there are bad
>> boxes even if the log isn't helpful in telling them where to look.
>> This is exactly what editors do, like TeXstudio.
> Ok, I see.  Then lets do that, too.
>>>> In addition, in a document of mine I have some bad horizontal boxes
>>>> with messages like
>>>>   Overfull \hbox (0.93071pt too wide) detected at line 29
>>>> but the regexp expects it to end with "at lines 12--34".
>>> I've checked some log files of mine, and I didn't find a singular
>>> version ("at line X").  But if you have them, the surely are possible.
>> The offending lines are in the table of contents and the list of
>> figures (*.toc and *.lof files).
> Hm, ok, I can't find such a warning in any toc/lof file here but that's
> surely possible.
>>> I'd start with the stricter version for now, i.e., the first version
>>> with additional trailing $.
>> Ok, I'll do that, thanks!
> Great, thanks.
> Bye,
> Tassilo

reply via email to

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