{{ message }}

# etoolbox.sty support #978

Merged
merged 35 commits into from Jul 11, 2018
Merged

# etoolbox.sty support#978

merged 35 commits into from Jul 11, 2018

## Conversation

### dginev commented Apr 29, 2018

 Addresses #478 After a long time staring, there were only minor tweaks needed to get latexml to properly interpret the etoolbox.sty tex code and pass a basic test. I have not tested on complex examples yet, and there are 4 warnings that indicate the begin/end hooks from etoolbox can't attach yet. But at the very least we're past the Fatal failures. I need to find myself a good torture test for etoolbox next.
reviewed

#### dginev Jun 23, 2018 Author Collaborator

Something I would like to understand better is whether this behavior of skipping spaces after the conditional test is something that should be done for all conditional types.

In other words, while patching \ifnum was all it took to get the etoolbox machinery to work, I wonder if it isn't better to patch DefConditional itself centrally, so that you can never declare a conditional that doesn't skip spaces after its test.

Would like to read up on this in the texbook possibly... Just a note for now.

### brucemiller commented Jul 8, 2018

 I've just pushed a commit that fixes \numexpr (and friends) so that they ignore spaces after expansion; I think this is the reason you were tempted to add the SkipSpaces to some of the \if commands; you should be able to revert that change. I'm also bugged by the change to object::Equals; Without this change, it seems that the only affect this has on the test cases is that pdflatex considers \begin to be "patchable" (apparently that \patchcmd should succeed?), whereas LaTeXML does not. However, I have to wonder: is \begin patchable in LaTeXML?

### dginev commented Jul 8, 2018

 Wonderful, rebasing the branch now and checking quickly...
added 2 commits Apr 29, 2018
added 13 commits Jun 11, 2018
…ck should avoid x@protect, not used by latexml
force-pushed the dginev:etoolbox-raw branch from f80c495 to c026770 Jul 8, 2018

### dginev commented Jul 9, 2018

 Sadly this was a high difficulty rebase, but with some extra care I think I got it right - in particular the same test tex->xml pair succeeds, and reviewing the final diff looks correct. Removing the skipped spaces indeed keeps the tests passing with the latest master, which is excellent.

### dginev commented Jul 9, 2018 • edited

 As to the patchable cases, the real win are binding-defined expansions that do not take arguments, such as \stop, which the master-branch Object.pm wouldn't successfully compare via the \meaning parsing. A minimal example document is: \documentclass{article} \usepackage{etoolbox} \begin{document} \ifpatchable{\stop}{}{}{not} patchable \end{document} This type of patching will succeed with the latexml run as well, so we do in fact succeed in boosting the raw interpretation. The macros that are impossible to patch are those that have one or more arguments, as the current serialization won't show the expected pattern by the meaning parse. pdflatex prints "patchable", and so does the current etoolbox branch. However, using the Object.pm from the master branch prints the opposite "not patchable", demonstrating the issue. And my main claim is that this is solving a general discrepancy, which covers patchable macros only in the specific case of etoolbox. Other packages use \meaning-parsing for other types of techniques as well, so the upgrade could have long-term gain for raw interpretation.

### brucemiller commented Jul 9, 2018

 Maybe I'm misunderstanding, or forgot how patching was handled; Are you saying that \begin is patchable by \patchcmd?

### dginev commented Jul 9, 2018

 I did not say that, no, I did not discuss the \begin case at all.

### dginev commented Jul 9, 2018

 If I was to rephrase, I would prefer that Object.pm was capable of noticing a "tokenized" CODE(...) pointer returned by \meaning, as a general point of enhancing the technique I dubbed "\meaning-parsing", that is common in raw tex bindings. If, separately from that, you would prefer that \ifpatchable should be reimplemented in a way that is completely accurate with the latexml implementation of patching, rather than aim for pdflatex-proximity, I can do that as well. But I see it as a higher level concern that is specific to etoolbox. My perspective from the start was to try and get as much as possible of etoolbox.sty operational as raw tex, and I'm quite happy I stumbled on a couple of generic sticking points that will improve the raw interpretation for a potential number of additional packages.

### brucemiller commented Jul 9, 2018

 It's always a dilemma; sometimes pretending to be (say) pdflatex is best, but we can't do everything pdflatex can. Likewise depends on what \ifpatchable might be used for; if it's used to check whether to use \patchcmd, then \ifpatchable should do false when we can't patch.

### dginev commented Jul 9, 2018 • edited

 Great, I'm on the same page w.r.t the dilemma between following pdflatex behavior and being honest about what latexml can do. For the binding, I had - and just slightly enhanced - the \patchcmd macro, which is the user-facing feature in question, honestly produce Info messages that it can not patch non-expandable, as well as CODE-expandable, definitions. And return the false case. Since \patchcmd is the user-facing macro, I am hoping this is both honest and provides the right messages to avoid confusion. Meanwhile, the \ifpatchable macro is a bit lower-level, and has no further uses in etoolbox itself, which is why I leaned towards keeping it with its "raw tex" interpretation. Let me know if that is acceptable, for now, or if I can add any further upgrades. I also added a lint pass to my last commit, so it is best seen with the ?w=1 flag on, as in the following link: ce62b29?w=1

### brucemiller commented Jul 10, 2018

 Great, cause now I'm having second thoughts! :> Basically, I'm still inclined to think that we should claim something's patchable, but I'm also guessing that somewhere below here is effectively asking "are these two things the same definition". And even if one's been mangled by \meaning, one might expect LaTeXML to recognize them as still the "same", right?

### dginev commented Jul 10, 2018

 And even if one's been mangled by \meaning, one might expect LaTeXML to recognize them as still the "same", right? That's it! Exactly my point, yes. Could you be implying you're coming closer to liking the Object patch?

### brucemiller commented Jul 10, 2018

 On 07/09/2018 08:54 PM, Deyan Ginev wrote: Could you be implying you're coming closer to liking the Object patch? Accepting, but *not* liking!
merged commit 4e718de into brucemiller:master Jul 11, 2018
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
This was referenced Jul 11, 2018
deleted the dginev:etoolbox-raw branch Mar 20, 2019