[Top][All Lists]

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

Re: [AUCTeX-devel] The parsing algorithm

From: David Kastrup
Subject: Re: [AUCTeX-devel] The parsing algorithm
Date: Sun, 08 Jun 2008 11:35:59 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

Ralf Angeli <address@hidden> writes:

> At <URL:>
> one can find a bug report for Emacs' TeX mode about an error not being
> handled correctly.  AUCTeX's parser fails as well in this exercise
> because of opening parens coming from math in the LaTeX file which do
> not have matching closing parens.
> Anyway, what I found interesting when investigating the bug is that the
> parser in tex-mode.el uses a different approach than AUCTeX's parser.
> It first searches for an error position and then tries to find the file
> associated with the error.  In course of that it checks for every
> interesting position (opening parens) if the the string at the position
> is a readable file.
> Although the approach fails at the example mentioned above i looks more
> robust to me than what AUCTeX does, namely walking through the whole
> output and maintaining a stack of strings where some are file names and
> some are not.  I thought about checking for file readability as well
> when pushing elements onto the stack but this would make deciding which
> names to pop from the stack much more difficult when a closing paren is
> found.
> Working on the parser is not my number one priority at the moment but
> perhaps looking at what tex-mode.el does might prove useful when we get
> the next bug report about it or in case somebody will have a shot at
> merging the parsers of AUCTeX and preview-latex at some time.

My take on that is that we should not pop at all but rather record the
nesting level.  And when trying to match, we go through the list, weed
out non-existing files and try matching on the existing ones, starting
with those that are "topologically close" in the nesting until we match
the actual error in question.

Or recommend using -file-line-error instead.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

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