[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.
-Ivan
[1]
http://stackoverflow.com/questions/7885853/emacs-latexmk-function-throws-me-into-an-empty-buffer