# Support for expandable environment names #1024

Merged
merged 1 commit into from Jul 27, 2018

## Conversation

Projects
None yet
3 participants
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.
 f234ff4 

### dginev reviewed Jul 27, 2018

 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));

#### dginev Jul 27, 2018 • edited

Collaborator

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

#### dginev Jul 27, 2018

Collaborator

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

#### 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"...

#### 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

#### 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 merged commit cd35a13 into brucemiller:master Jul 27, 2018 1 check passed

#### 1 check passed

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