etoolbox.sty support - #978
Conversation
| my $message = "Input is empty"; | ||
| if (my $token = $self->readToken) { | ||
| $message = "Next token is " . Stringify($token); | ||
| unshift(@{ $$self{pushback} }, $token); |
There was a problem hiding this comment.
I reworked this since it felt weird to unread an undef value in the empty input case.
| my @args = (); | ||
| foreach my $parameter (@$self) { | ||
| my $value = $parameter->read($gullet); | ||
| my $value = $parameter->read($gullet, $fordefn); |
There was a problem hiding this comment.
strange oversight, adding fordefn back in makes the parameter read errors much saner (as opposed to wrong argument of undef)
| elsif ($meaning->isExpandable) { | ||
| my $gullet = $$self{gullet}; | ||
| $gullet->unread(@{ $meaning->invoke($gullet) }); | ||
| $gullet->unread(@{ $meaning->invoke($gullet) || [] }); |
There was a problem hiding this comment.
I hit a Perl die here while playing around, patched it.
|
|
||
| DefMacro('\@tabacckludge {}', '\csname\string#1\endcsname'); | ||
|
|
||
| DefMacro('\@argdef', '\newcommand'); # stopgap? |
There was a problem hiding this comment.
Technically, newcommand is defined in terms of argdef, not the other way around. etoolbox uses argdef directly, and I was surprised to see a simple aliasing to (latexml's) newcommand had great results.
| Let('\protect', '\string'); | ||
| my $message = join("\n", map { ToString(Expand($_)) } @args); | ||
| Let('\MessageBreak','\ltx@hard@MessageBreak'); # tricky, we need Expand() to execute it | ||
| my $message = join("", map { ToString(Expand($_,T_CS('\MessageBreak'))) } @args); |
There was a problem hiding this comment.
This is a bit of a perverse change. The warning messages of etoolbox have a trailing \@gobble that seems to intend to remove the trailing line break. So to avoid an argument error, I had to add the trailing newlines in. Meanwhile I also noticed \MessageBreak had to be locally bound to ^^J (and expandable), but wasn't, so fixed that too.
|
Awesome! Looks like we're working on this from both ends :> I'd given up (quite easily) reading in etoolbox.sty, but started writing (w/o testing) bindings for it. A lot of macros and similar patterns. If we can interpret the sty, some will still be useful, I think. The document & environment hooks will need special attention. |
|
Nice! This PR certainly reads in the native package successfully, but whether it does it correctly - I'm not so sure! Especially when it comes to the extra hooks etoolbox introduces. So your work may definitely be the key to get things working in full 👍 I'm having trouble locating a great test case "for free" though, maybe I'll write my own - but perfectly happy to borrow yours if you have one? :> |
|
Ha! That's the thing, I wrote no tests at all, just coding, coding, coding :> |
|
Pushing incremental changes here, as I expand the test coverage. |
|
|
||
| DefMacro('\value{}', sub { | ||
| ExplodeText(CounterValue(ToString(Expand($_[1])))->valueOf); }); | ||
| T_CS("\\c@".ToString(Expand($_[1]))) }); |
There was a problem hiding this comment.
A side-remark here in passing - I've seen a number of errors due to "No more Input" that have to do with the Expand technique of using a standalone Mouth for the expansion. Some of the low-level tricks in the sty files end up reaching beyond the argument, so Expand may need an upgrade that can grab the next Mouth from the gullet when its sandbox is not enough?
There was a problem hiding this comment.
Not something to address now, I will eventually have a perfect example that shows this, which we can use to upgrade. But bookkeeping to remember.
|
@brucemiller I got to the hooks section of the documentation, but your bindings may be called for here. Here is a simple test that should get you a document that says "hello world" \documentclass{article}
\usepackage{etoolbox}
% --- preamble/postamble document hooks
\AfterPreamble{\secret\newline\renewcommand{\secret}{world}}
\AfterEndPreamble{\secret\newline}
\AtEndPreamble{\def\secret{hello}}
\AfterEndDocument{never printed}
\begin{document}
\end{document}The |
|
Note from exploring the showcase examples - turns out babel's |
bc5941b to
66fc74e
Compare
8b68f4e to
afd862c
Compare
|
A summary comment in the PR on the status of this binding:
At this point I am going through the documentation and writing as many tests as I can, at which point this PR should be good to go. |
|
I now consider this PR with sufficient testing coverage, and welcome review and corrections. CC @brucemiller |
| DefConditional('\ifodd Number', sub { $_[1]->valueOf % 2; }); | ||
| DefConditional('\ifnum Number Token Number SkipSpaces', sub { compare($_[1], $_[2], $_[3]); }); | ||
| DefConditional('\ifdim Dimension Token Dimension SkipSpaces', sub { compare($_[1], $_[2], $_[3]); }); | ||
| DefConditional('\ifodd Number SkipSpaces', sub { $_[1]->valueOf % 2; }); |
There was a problem hiding this comment.
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.
|
I've just pushed a commit that fixes 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 |
|
Wonderful, rebasing the branch now and checking quickly... |
…ck should avoid x@protect, not used by latexml
|
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. |
|
As to the patchable cases, the real win are binding-defined expansions that do not take arguments, such as 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 |
|
Maybe I'm misunderstanding, or forgot how patching was handled;
Are you saying that \begin is patchable by \patchcmd?
|
|
I did not say that, no, I did not discuss the |
|
If I was to rephrase, I would prefer that Object.pm was capable of noticing a "tokenized" CODE(...) pointer returned by If, separately from that, you would prefer that 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. |
|
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 |
|
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 Since Meanwhile, the I also added a lint pass to my last commit, so it is best seen with the |
|
Great, cause now I'm having second thoughts! :> |
That's it! Exactly my point, yes. Could you be implying you're coming closer to liking the Object patch? |
|
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!
|
2 participants
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.