auctex-devel
[Top][All Lists]
Advanced

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

Re: [AUCTeX-devel] [AUCTeX-diffs] GNU AUCTeX branch, master, updated. 36


From: David Kastrup
Subject: Re: [AUCTeX-devel] [AUCTeX-diffs] GNU AUCTeX branch, master, updated. 363b751003c4b425b4b6c511740c95366481207c
Date: Tue, 17 Dec 2013 10:35:58 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Tassilo Horn <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> "Tassilo Horn" <address@hidden> writes:
>>
>>> commit 363b751003c4b425b4b6c511740c95366481207c
>>> Author: Luc Van Eycken <address@hidden>
>>> Date:   Tue Dec 17 09:01:29 2013 +0100
>>>
>>>     Skip comment or file in parens in output.
>>>     
>>>     * tex-buf.el (TeX-parse-error): Skip comment (or file) between
>>>     parentheses.
>>>     
>>>     Signed-off-by: Tassilo Horn <address@hidden>
>>
>> I'm confused.  I was pretty sure that at one point of time I _vastly_
>> simplified TeX-parse-error's recognition of file names to have the
>> recognition of opening and closing parens be similarly indiscriminate
>> (since detecting spurious ( ) pairings as file names is harmless, but
>> skipping some non-filename ( while still recognizing the corresponding )
>> isn't).
>>
>> Did someone "improve" the file name recognition again?  That actually
>> makes the problem worse.
>
> Hm, your last changes to `TeX-parse-error' are from 2006, and thereafter
> it's Reiner with one line change in 2007 and Ralf with some changes in
> 2009.

Huh.  My memory does not match the code.

Maybe I confused this with a check that a file actually existed,
something which obviously made matching the closing parens worse for the
same reasons.

The question is how we can improve this.  It might make sense to count
_all_ opening parens.  Or one does not even look at the closing parens
at all, but rather at the time of an error throws away bad matches until
one gets to something fitting the input.  Or one uses the paren count
difference as a tie-breaker when more than one element in the list of
file names would match the error message.

At any rate: making the match condition more selective for opening
parens does not help since we can't make the closing paren matches more
selective.

> Anyway, for the time being, I've reverted the change.
>
> Luc, could you please explain what's the problem your patch is
> actually trying to fix, preferably with a sample file?  At least with
> the current git version, I don't see a difference with or without your
> patch when using the hyperref package.  And speaking from the
> AUCTeX-date in your patch bug report, your version of
> `TeX-parse-error' should be up-to-date.

Maybe the idea was a shortcut for discarding matched parens on a single
line?  In that case, it would not matter whether what we ditch is a file
name or not.  But it's probably smarter to make a separate match for
"paren without good filename".  If we see one of those when trying to
match actual errors, it's not too late to toss it then rather than not
having it considered in the match at all.

-- 
David Kastrup



reply via email to

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