Re: [AUCTeX] TeX error parsing: request for testing
David Kastrup d...@gnu.org writes: As a note aside: preview-latex also does error message matching on its own, and it apparently does a better job at it. Maybe it would make sense to port the respective code over and/or try making a common interface both use. It does not seem to make much sense getting this problem tackled independently. Sounds very reasonable. I'll have a look. Bye, Tassilo ___ auctex mailing list auctex@gnu.org https://lists.gnu.org/mailman/listinfo/auctex
Re: [AUCTeX] TeX error parsing: request for testing
Mosè Giordano giordano.m...@libero.it writes:
Hi Mosè,
2014-04-25 13:08 GMT+02:00 Tassilo Horn t...@gnu.org:
Great, please keep on testing (also with the latest change).
I'm having some trouble with multifile documents. Attached you can
find two files, foo.tex being the master one: if you compile the files
as they are (i.e. with all content inside foo.tex) `TeX-next-error`
finds the Undefined control sequence \command, while if you
uncomment the
% \input{bar}
line and comment the
\command
line in foo.tex `TeX-next-error` won't be able to find the error anymore.
Thanks, I was able to reproduce that. It's been caused by my new-file
regex matching multi-line input which it shouldn't. I've pushed a fix
that makes it working for me.
In addition, in a quite large document I have, split in multiple
secondary source files, `TeX-next-error' tries to open a file names
/path/to/a/secondary/file.tex [31] [32]Chapter 2.[33] [34] which is
clearly wrong.
The patch also fixes your second set of test docs (at least for me), but
that's probably more by accident. Spaces, periods, and [] are legal in
file names, so that could indeed be a file name. Well, at least [] in
file names is not really that common, but who knows.
Maybe a good approach was to keep the regex that lax which would still
cause a (wrong) file name
/path/to/a/secondary/file.tex [31] [32]Chapter 2.[33] [34]
be pushed onto the stack, but then have loops in `TeX-error' and
`TeX-warning' that cut the file name at spaces (from right to left)
until `file-exists-p'.
I don't have time for this today, but let's keep that in mind.
Bye,
Tassilo
___
auctex mailing list
auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex
Re: [AUCTeX] TeX error parsing: request for testing
Tassilo Horn t...@gnu.org writes:
Mosè Giordano giordano.m...@libero.it writes:
Hi Mosè,
2014-04-25 13:08 GMT+02:00 Tassilo Horn t...@gnu.org:
Great, please keep on testing (also with the latest change).
I'm having some trouble with multifile documents. Attached you can
find two files, foo.tex being the master one: if you compile the files
as they are (i.e. with all content inside foo.tex) `TeX-next-error`
finds the Undefined control sequence \command, while if you
uncomment the
% \input{bar}
line and comment the
\command
line in foo.tex `TeX-next-error` won't be able to find the error anymore.
Thanks, I was able to reproduce that. It's been caused by my new-file
regex matching multi-line input which it shouldn't. I've pushed a fix
that makes it working for me.
As a note aside: preview-latex also does error message matching on its
own, and it apparently does a better job at it. Maybe it would make
sense to port the respective code over and/or try making a common
interface both use. It does not seem to make much sense getting this
problem tackled independently.
This code duplication would also explain my recurring eerie didn't
I fix this already feeling.
--
David Kastrup
___
auctex mailing list
auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex
Re: [AUCTeX] TeX error parsing: request for testing
Hi Tassilo,
2014-04-25 13:08 GMT+02:00 Tassilo Horn t...@gnu.org:
Great, please keep on testing (also with the latest change).
I'm having some trouble with multifile documents. Attached you can
find two files, foo.tex being the master one: if you compile the files
as they are (i.e. with all content inside foo.tex) `TeX-next-error`
finds the Undefined control sequence \command, while if you
uncomment the
% \input{bar}
line and comment the
\command
line in foo.tex `TeX-next-error` won't be able to find the error anymore.
I'm wondering if this new error parsing takes into account
`file:line:error' messages: I use them, through the `-file-line-error'
switch in `LaTeX-command-style', but they seem to be of no help.
In addition, in a quite large document I have, split in multiple
secondary source files, `TeX-next-error' tries to open a file names
/path/to/a/secondary/file.tex [31] [32]Chapter 2.[33] [34] which is
clearly wrong. Unfortunately, I cannot give you a minimal test file
reproducing this bug.
Bye,
Mosè
bar.tex
Description: TeX document
foo.tex
Description: TeX document
___
auctex mailing list
auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex
Re: [AUCTeX] TeX error parsing: request for testing
Mosè Giordano giordano.m...@libero.it writes: Great, please keep on testing (also with the latest change). In GNU Emacs = 24.3 the `split-string' function doesn't have the fourth argument, `trim'. You used it inside `TeX-parse-error'. Thanks for the heads-up. I've exchanged it with a more traditional way of trimming. :-) Bye, Tassilo ___ auctex mailing list auctex@gnu.org https://lists.gnu.org/mailman/listinfo/auctex
Re: [AUCTeX] TeX error parsing: request for testing
Hi Tassilo, 2014-04-25 13:08 GMT+02:00 Tassilo Horn t...@gnu.org: Great, please keep on testing (also with the latest change). In GNU Emacs = 24.3 the `split-string' function doesn't have the fourth argument, `trim'. You used it inside `TeX-parse-error'. Bye, Mosè ___ auctex mailing list auctex@gnu.org https://lists.gnu.org/mailman/listinfo/auctex
Re: [AUCTeX] TeX error parsing: request for testing
* Tassilo Horn (2014-04-24) writes: The problem is that the TeX compile output gets hard-wrapped at column 80, and with the new TL install and LuaTeX, I get tons of files in the compile output whose paths are all about 80 columns wide. AUCTeX contains code to undo those line wraps. Maybe it fails in your case? Look for the number 79 in tex-buf.el to find the code. -- Ralf Followup-To: auctex-de...@gnu.org ___ auctex mailing list auctex@gnu.org https://lists.gnu.org/mailman/listinfo/auctex
Re: [AUCTeX] TeX error parsing: request for testing
Ralf Angeli ang...@caeruleus.net writes: Hi Ralf, The problem is that the TeX compile output gets hard-wrapped at column 80, and with the new TL install and LuaTeX, I get tons of files in the compile output whose paths are all about 80 columns wide. AUCTeX contains code to undo those line wraps. Maybe it fails in your case? Look for the number 79 in tex-buf.el to find the code. Indeed, it does remove about 90% of the wraps but fails at others. Bye, Tassilo ___ auctex mailing list auctex@gnu.org https://lists.gnu.org/mailman/listinfo/auctex
Re: [AUCTeX] TeX error parsing: request for testing
Tassilo Horn t...@gnu.org writes: The problem is that the TeX compile output gets hard-wrapped at column 80, and with the new TL install and LuaTeX, I get tons of files in the compile output whose paths are all about 80 columns wide. AUCTeX contains code to undo those line wraps. Maybe it fails in your case? Look for the number 79 in tex-buf.el to find the code. Indeed, it does remove about 90% of the wraps but fails at others. Ah, now I've figured out what's wrong with the wraps that don't get removed; they are wrapped at column 80, not column 79. Also, the heuristic in `TeX-format-filter' forbids removing newlines if they follow a period. Thus, lines like (/usr/local/texlive/2013/texmf-dist/tex/luatex/luaotfload/luaotfload-fontloader. lua) don't get joined. If I remove that restriction and consider newlines both at column 79 and 80, it seems to catch all of them (but of course it might then catch too much)... Bye, Tassilo ___ auctex mailing list auctex@gnu.org https://lists.gnu.org/mailman/listinfo/auctex
Re: [AUCTeX] TeX error parsing: request for testing
Hi Tassilo, 2014-04-24 21:15 GMT+02:00 Tassilo Horn t...@gnu.org: If you find a problem, i.e., `TeX-next-error' jumps to the wrong file, it tells you the erroneous file doesn't exist, or it tells you the error occured after the last file closed, please poste the compile log (C-c C-l) here in this thread. Otherwise, it'd be nice if you could drop a quick works-for-me message here, too. Luckily, I don't usually get the errors you reported, but I use `pdflatex` to compile my documents, if that matters. So I guess I should say works for me. Bye, Mosè ___ auctex mailing list auctex@gnu.org https://lists.gnu.org/mailman/listinfo/auctex
Re: [AUCTeX] TeX error parsing: request for testing
Tassilo Horn t...@gnu.org writes: If I remove that restriction and consider newlines both at column 79 and 80, it seems to catch all of them (but of course it might then catch too much)... Ok, now I've pushed a change d4059b8 which implements the above. Now wraps at columns 79 and 80 are removed under certain conditions, and the period-condition now allows removal only if the char following the newline is a word char. so ...bla/bla/bla. tex) would be unwrapped whereas this is just a sentence. And here goes the next one. Bla bla... is not. Bye, Tassilo ___ auctex mailing list auctex@gnu.org https://lists.gnu.org/mailman/listinfo/auctex
Re: [AUCTeX] TeX error parsing: request for testing
Mosè Giordano giordano.m...@libero.it writes: Hi Mosè, If you find a problem, i.e., `TeX-next-error' jumps to the wrong file, it tells you the erroneous file doesn't exist, or it tells you the error occured after the last file closed, please poste the compile log (C-c C-l) here in this thread. Otherwise, it'd be nice if you could drop a quick works-for-me message here, too. Luckily, I don't usually get the errors you reported, but I use `pdflatex` to compile my documents, if that matters. No, not really. LuaTeX with fontspec and stuff just includes tons of files, so error parsing problems caused by losing track of opened and closed files are more likely to show up. So I guess I should say works for me. Great, please keep on testing (also with the latest change). Bye, Tassilo ___ auctex mailing list auctex@gnu.org https://lists.gnu.org/mailman/listinfo/auctex
[AUCTeX] TeX error parsing: request for testing
Hi all, lately I've switched to using LuaTeX and a TeX Live install in /usr/local with tl-install instead of my distro's TeX Live packages. That had the side-effect that AUCTeX's error parsing frequently didn't work anymore and I got those nasty Error occurred after last TeX file closed errors. The problem is that the TeX compile output gets hard-wrapped at column 80, and with the new TL install and LuaTeX, I get tons of files in the compile output whose paths are all about 80 columns wide. Here's an output snippet illustrating some of the problems: --8---cut here---start-8--- (/usr/local/texlive/2013/texmf-dist/tex/luatex/luaotfload/luaotfload.lua) (/usr/local/texlive/2013/texmf-dist/tex/luatex/luaotfload/luaotfload-fontloader. lua)(using write cache: /home/horn/.texlive2013/texmf-var/luatex-cache/generic)( using read cache: /usr/local/texlive/2013/texmf-var/luatex-cache/generic /home/h orn/.texlive2013/texmf-var/luatex-cache/generic) (/usr/local/texlive/2013/texmf-dist/tex/luatex/luaotfload/luaotfload-override.lu a) --8---cut here---end---8--- One problem is that sometimes the ( starting a file is immediately followed by a newline, and only after that the file name starts. The current new-file regexp in `TeX-parse-error' doesn't match that (although it could be easily fixed). Another problem is that the new-file regexp matches at most one file per line but for example in line 3 above, there are two files opened. The latter is not so easy to fix. Honestly, I have no clue about what all those different shy groups and alternatives are supposed to match, and its not documented. So I've just thrown away that monstrosity of a regexp and replaced it with a much much simpler one. That also allowed to simplify the end-of-file regexp. I'm sure the new one delivers more false positives but that's not really important. Important is mainly that new-files and end-of-files are balanced, and that seems to work just fine. I've pushed the simplified version to a new branch named `simplify-TeX-parse-error'. You could do me a favor and test that branch to check if AUCTeX is able to jump to the correct error location with your documents and your errors. If you find a problem, i.e., `TeX-next-error' jumps to the wrong file, it tells you the erroneous file doesn't exist, or it tells you the error occured after the last file closed, please poste the compile log (C-c C-l) here in this thread. Otherwise, it'd be nice if you could drop a quick works-for-me message here, too. Thanks, Tassilo ___ auctex mailing list auctex@gnu.org https://lists.gnu.org/mailman/listinfo/auctex
