[Top][All Lists]

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

Re: [AUCTeX-devel] AUC-TeX and TeXLive banners

From: Ivan Andrus
Subject: Re: [AUCTeX-devel] AUC-TeX and TeXLive banners
Date: Fri, 18 Jan 2013 00:19:21 +0100

On Jan 17, 2013, at 4:43 PM, Fabrice Popineau <address@hidden> wrote:

> Hi all,
> I wonder why the following has not been reported yet.
> I'm working with emacs (trunk) and AUC-TeX (CVS)
> and TeXLive (latest version) under Windows.
> The TeXLive banners read like this :
> Running `LaTeX' on `parametric-agents' with ``pdflatex  --synctex=1 
> -interaction=nonstopmode "\input" "parametric-agents.tex"''
> This is pdfTeX, Version 3.1415926-2.4-1.40.13 (TeX Live 2012/W32TeX)
> (for the W32 version). Whenever I ask for TeX-next-error, AUC-TeX tries
> to parse an error on the banner because of the '(TeX Live 2012/W32TeX)'
> part.

Depending on what you mean, this has been seen before.  If you mean that AUCTeX 
thinks that line is an error, then I have no idea.  It doesn't do that for me.

If there is a real error in your file, but it opens up a *TeX Live 2012* buffer 
instead of the actual file then this has been observed by me and many other 
people (e.g. on Stack Overflow [1]).  It's due to misparsing the output of TeX 
(or the output itself being misleading), and can be largely (though not wholly) 
eliminated by using the -file-line-error-style flag to latex.  Some day I hope 
to add this as a "mode" to AUCTeX like pdf-mode, and hopefully make it the 
default since it makes errors much more reliable (though still not 100%).  

I also have some other ideas for how to change TeX-next-error to parse more 
reliably.  But since there are several reasons why it can misparse (some 
pathological), I won't be able to fix it in all cases.  Nevertheless, it would 
be nice to have the logs from some cases where it misparses to see if they can 
be fixed.  I have a version of TeX-parse-error which puts some formatting in 
the buffer to make it easier to find things which don't parse correctly. It 
basically consists of adding statements like

  (put-text-property (match-beginning 0) (match-end 0)
                               'face 'font-lock-warning-face)

in certain spots.  If you are interested I can send it.  Otherwise, I would be 
interested in log files that exhibit the error for you.  I don't have plans to 
work on it right away, because changing TeX-parse-error scares me.

> I have found only one quick and dirty way to avoid it by applying this patch:
> diff -u -r1.292 tex-buf.el
> --- tex-buf.el  26 Nov 2012 19:56:21 -0000      1.292
> +++ tex-buf.el  17 Jan 2013 15:42:06 -0000
> @@ -1537,7 +1537,10 @@
>             t))
>          ;; New file -- Push on stack
> -        ((match-beginning 3)
> +        ((and (match-beginning 3)
> +              (string-match "\\(Web2C 20\\|TeX Live 20\\)" (TeX-match-buffer 
> 3)
> ))
> +         t)
> +        ((match-beginning 3)
>           (let ((file (TeX-match-buffer 3))
>                 (end (match-end 3)))
>             ;; Strip quotation marks and remove newlines if necessary
> If you know of a better way, please let me know.

This is slightly papering over the issue, but I think it would eliminate the 
symptoms of the problem a large fraction of the time.  It's probably a good 
idea for general users since they are clearly not real files, but it seems like 
there should be a better way to determine if they should be skipped other than 
just a string-match.  I don't know what that would be though.  Hopefully 
someone else has a better idea.



reply via email to

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