Small fixes to schema docs #2214
Conversation
| @@ -105,7 +105,7 @@ sub filterNames { | |||
| && ((($name =~ /^!(.*)$/) && !(defined $$hash{$1})) # Negated name, but name not present? | |||
| || (!defined $$hash{ '!' . $name }))) { # Or negation of name not present | |||
| $filtered{$name} = 1; } } | |||
| return sort keys %filtered; } | |||
| return (sort keys %filtered); } | |||
There was a problem hiding this comment.
the new parens around sort were motivated by Perl Critic complaining loudly that sort should not follow a return (severity 5, docs)
| # careful, if $prev is a triple [$op,$name,@stuff] and we flatten it, | ||
| # we should not treat $op and $name as @stuff. | ||
| # We should either drop them, or not flatten at all. Drop for now. | ||
| ($prev ? @$prev[2 .. $#{$prev}] : ()), @xargs]); |
There was a problem hiding this comment.
I think the idea is that simplifyCombination is supposed to evolve to give a "good" description, but it clearly isn't there yet. I expect that probably $prev would have been more correct than @$prev and better than throwing away the operator. OTOH, that leaves simplifyCombination to deal with the initial case where the extra items are empty (that puts a "()" into the summary). And none of the variants are generating sensible descriptions for the tricky cases svg, xhtml:* and such; that ought to be our goal, I think.
| @@ -708,7 +711,6 @@ sub getSymbolUses { | |||
| my @uses = sort keys %$uses; | |||
| @uses = grep { !/\bSVG./ } @uses if $SKIP_SVG; # !!! | |||
| return join(', ', | |||
| (map { /^pattern:[^:]*:(.*)$/ ? ('\patternref{' . cleanTeX($1) . '}') : () } @uses), | |||
|
actually, a good start... thanks! |
To use an example, say the LaTeXML-common schema docs page has two visible issues today:
I think I have identified the causes for the two mishaps. For "used by" a line of code was duplicated, so just removing that.
For the expansion case, it seems more subtle, as it is hard for me to follow the various cases of data structure management for the "combination" cases. I think I traced the source of the issue to a peculiar call to
simplifyCombinationwhich flattens a triple to an array, and then mistreats theopandnamekeywords as data, leading to them showing up in the docs page. Dropping them early when preparing the arguments for that method call avoids the issue - but one should double-check if$previs reliably a triple of this kind, as I am not 100% sure.