New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fails to parse / binding required for ltxcmds.sty #905

bfirsh opened this Issue Dec 16, 2017 · 4 comments


None yet
3 participants

bfirsh commented Dec 16, 2017

I am writing a binding for icml2017.sty. When naively trying to use InputDefinitions('icml2017', type => 'sty', noltxml => 1), it fails when trying to load ltxcmds.sty:

(Processing definitions /app/local/icml2017/icml2017.sty...
(Loading /usr/local/share/perl/5.24.1/LaTeXML/Package/fancyhdr.sty.ltxml... 0.00 sec)
(Loading /usr/local/share/perl/5.24.1/LaTeXML/Package/color.sty.ltxml... 0.01 sec)
(Processing definitions /usr/share/texlive/texmf-dist/tex/latex/eso-pic/eso-pic.sty...
(Processing definitions /usr/share/texlive/texmf-dist/tex/generic/oberdiek/atbegshi.sty...
(Processing definitions /usr/share/texlive/texmf-dist/tex/generic/oberdiek/infwarerr.sty... 0.06 sec)
(Processing definitions /usr/share/texlive/texmf-dist/tex/generic/oberdiek/ltxcmds.sty... 0.11 sec)
Error:latex:\GenericError LaTeX Error: Command \ already defined. Or name \end... illegal, see p.192 of the manual
	at /usr/share/texlive/texmf-dist/tex/generic/oberdiek/atbegshi.sty; line 188 col 47
	See the LaTeX manual or LaTeX Companion for explanation.
	In Core::Definition::Primitive[\GenericE... from LaTeX.pool.ltxml line 4192
	 <= Core::Stomach[@0x560c1d12b8e8] <= Core::Gullet[@0x560c1d12a9d0] <= Core::Definition::Constructor[\Requir... <= ...
File /usr/local/share/perl/5.24.1/LaTeXML/Package/icml2017.sty.ltxml had an error:

Fatal:unexpected:<endgroup> Attempt to pop last locked stack frame
	at /usr/share/texlive/texmf-dist/tex/generic/oberdiek/atbegshi.sty; line 188 col 47
	In Core::Stomach[@0x560c1d12b8e8] at /usr/share/texlive/texmf-dist/tex/generic/oberdiek/atbegshi.sty; line 188 col 47
	 <= Core::Definition::Primitive[End] <= Core::Stomach[@0x560c1d12b8e8] <= Core::Gullet[@0x560c1d12a9d0] <= Core::Definition::Constructor[\Requir... <= Core::Stomach[@0x560c1d12b8e8] <= Core::Gullet[@0x560c1d12a9d0] <= Core::Definition::Constructor[\Requir... <= Core::Stomach[@0x560c1d12b8e8] <= Core::Gullet[@0x560c1d12a9d0] <= Core::Definition::Constructor[\usepac... <= Core::Stomach[@0x560c1d12b8e8]
1 error; 1 fatal error

Just to better understand your process for supporting this sort of thing... Presumably the ideal situation is that ltxcmds.sty.ltxml would use InputDefinitions('ltxcmds', type => 'sty', noltxml => 1) and override things that need overriding.

But, in the meantime, a ltxcmds.sty.ltxml could be written that doesn't use InputDefinitions(...) to get round the fact it doesn't parse.

Does that sound about right?

@dginev dginev added this to the LaTeXML-0.8.4 milestone Dec 16, 2017


This comment has been minimized.


brucemiller commented Dec 19, 2017

That's a pretty good grasp of the process, but I'd start off with 1 or 2 other steps. Which, as it turns out led to a couple of surprises!

Firstly, I'd try using the --includestyles option, to let latexml interpret any raw style files, just to see what would happen. The first surprise was that nothing happened. A stoopid camel-case typo made that option completely ineffective for the last couple of years!! Argh! OK, so fixed. (thanks!).

Next step (after realizing that the error was from atbegshi.sty; ltxcmds.sty loads just fine) is not to trust LaTeXML too much; try to see if we can track the problem down to a latexml bug, before working to override the package. In this case, it was indeed a simply error with a wrong parameter type to \@ifdefinable in LaTeX.pool. Fixed!

So, 2 bugs down; This may not get you all the way through icm2017, but should get further. Thanks for the report!!


This comment has been minimized.


dginev commented Dec 19, 2017

@brucemiller I should also trust latexml less it seems - I may have been able to fix this back in October when you were reviewing my PR for this exact problem in latexmlc #873, but just assumed all was good in the classic commands. Nice to have it caught. And +1 on camelCase being dangerous in hash keys


This comment has been minimized.


bfirsh commented Dec 20, 2017

Nice! Thank you! I’ll give this another shot later.

I see I misread that error... sorry for leading you down the wrong path.


This comment has been minimized.


bfirsh commented Dec 20, 2017

Funnily I had already been playing with —includestyles and it worked because I was using latexmlc :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment