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

Support for expandable environment names #1024

Merged
merged 1 commit into from Jul 27, 2018

Conversation

Projects
None yet
3 participants
@tkw1536
Contributor

tkw1536 commented Jul 27, 2018

Currently LaTeXML only has support for environments which are named literally, i.e. those of the form:

\begin{somename}
 content
\end{somename}

However, if an environment name is defined by an expandable token, like in either of the following, LaTeXML fails:

\def\somecs{somename}

\begin\somecs
 content
\end\somecs

\begin{\somecs}
 content
\end{\somecs}

LaTeX itself supports all three cases.

This PR resolves the problem by expanding the argument to \begin and \end. It furthermore adds appropriate test cases to t/expansion/environments.tex.

The solution implemented in this PR is to manually call Expand() on the argument. I also tried making the argument of type Digest, as well as manually Digest()ing the argument, however both of these cases caused test failures. The same goes for using the Expanded argument type.

Support for expandable environment names
Previously, LaTeXML only had support for environments which were named
literally, i.e. that stated with \begin{somename}. This meant that if an
environment name was defined by an expandable token (e.g.
\begin\somecs), then LaTeXML would fail.

This commit resolves the problem by expanding the argument to \begin and
\end. It furthermore adds an appropriate test case to
t/expansion/environments.tex.
my $name = $env && ToString($env);
my $before = LookupValue('@environment@' . ToString($_[1]) . '@beforebegin');
my $after = LookupValue('@environment@' . ToString($_[1]) . '@atbegin');
my $name = $env && ToString(Expand($env));

This comment has been minimized.

@dginev

dginev Jul 27, 2018

Collaborator

question: Shouldn't this be realized via the parameter type? E.g. replacing the \begin{} via an \begin XToken or such? cc @brucemiller

This comment has been minimized.

@dginev

dginev Jul 27, 2018

Collaborator

Also, if $name is undefined / empty we probably want to throw an error

This comment has been minimized.

@brucemiller

brucemiller Jul 27, 2018

Owner

Well, yeah, sorta, but ... No. There's an Expanded parameter type which we tried to use. It failed because it kinda expands too early(?). Well, really LaTeX gets the argument which might be balanced braces or a single token, eventually that gets expanded. Using Expanded caused latexml to only see the 1st char of the expansion instead of the whole thing; adding extra braces mucked things up differently. It's probably true that one would need (at least) two separate flavors of "expanded"...

This comment has been minimized.

@dginev

dginev Jul 27, 2018

Collaborator

Right, it looks like we need a ->readXArg rather than a ->readXToken, and since we don't have that yet, the current PR makes sense

This comment has been minimized.

@dginev

dginev Jul 27, 2018

Collaborator

But this begs the question if the Expanded parameter type is ever the correct type to use? Maybe it just needs an upgrade, even separately from the \begin case.

@brucemiller brucemiller merged commit cd35a13 into brucemiller:master Jul 27, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@tkw1536 tkw1536 deleted the tkw1536:expandable-environments branch Jul 27, 2018

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