Template talk:Tmath
Behavior of parser functions [either extensions or not] when the parameter is not provided
editThe #tag parser function extension returns 1 instead of {{{1}}} when the parameter is not provided. Do all the parser functions and/or parser function extensions behave in this way? Just asking. — TentaclesTalk or ✉ mailto:Tentacles 15:26, 30 March 2016 (UTC)
Using magic words, parser functions [either extensions or not] and/or templates inside the tmath template
editShould I mention (or not) on the doc page that one may use magic words, parser functions [either extensions or not] and/or templates inside the {{tmath}} template, with an example such as:
The code
{{tmath| \frac{1}{\zeta(2)} {{=}} \frac{6}{\pi^2} {{=}} {{#expr: 6 / (pi^2) }}\ldots }}
yields
-
Or is this discouraged? — TentaclesTalk or ✉ mailto:Tentacles 15:43, 30 March 2016 (UTC)
- You may see that parser functions are ignored ans stripped. So there is no point in using them.
-- [[User:Edokter]] {{talk}}21:13, 30 March 2016 (UTC)
- The parser function [extension]
{{#expr: 6 / (pi^2) }}used in the {{tmath}} example above yielded0.60792710185402so it did work. — TentaclesTalk or ✉ mailto:Tentacles 23:31, 30 March 2016 (UTC)
- The parser function [extension]
Improving the template
editThis template documentation as the users above noted is downplaying its potential quite a bit in my opinion. Compared to using <math></math> there's plenty of positives such as
- Allowing templates and semantic mediawiki properties inside it is a VERY strong feature. Example:
<math>{{#expr:{{CURRENTYEAR}} + 1}}</math>yields Failed to parse (syntax error): {\displaystyle {{#expr:{{CURRENTYEAR}} + 1}}} , it should of course show which{{Tmath}}successfully did. As the calculations imply; supporting templates, parser functions and SMW properties allows creating advanced math examples that will stay synchronized with the wiki even if the variables changes. - Controlling styles and background colors can easily be done in templates. Maybe not that useful for this wiki in particular.
The issue with equal signs isn't that big of a deal with named parameters, if it allowed the named parameter "formula":
{{TMath|formula=
{{CURRENTYEAR}} + 1 = {{#expr: {{CURRENTYEAR}} + 1}}
}}
And if you expand the template a bit to include {{NumBlk}} and {{EquationRef}} you can create numbered equations by just adding "nr=1" as a named parameter and then reference them with {{EquationNote}}. Here's the code suggestion, taken from here:
{{#vardefine:math|
{{#tag:math
| \pagecolor[RGB]{15,15,15} \color[RGB]{163,141,109} {{{1|{{{formula|{\color{Red}error} }}}}}}
| display="{{{display|}}}"
| style="background-color:transparent; padding:0;"
}}
}}
{{#if: {{{nr|}}}
| {{NumBlk|1=:|2={{#var:math}}|3={{EquationRef|{{{nr}}}}}}}
| {{#var:math}}
}}
Remove \pagecolor[RGB]{15,15,15} \color[RGB]{163,141,109} if it's not needed.--Illviljan (talk) 20:46, 22 January 2017 (UTC)
Not to print "1" in the case of empty argument
editI think it is not necessary to print "1" in the case of empty argument for this template, so I add "|" in the end of it.
But it is reverted. What other friends think about this change (adding "|") in this template?
Thanks, Hooman Mallahzadeh (talk) 16:44, 27 September 2020 (UTC)
Oops
edit@Quondum: Oops. I mean, saying that it sprinkles |display= everywhere is not exactly how I would describe it (sure it makes sense on the #tag: level, but the real issue is <math display>). Turns out that is not equivalent to <math>: the original thing feeds {\displaystyle blah} to the render, while the new thing feeds just "blah".
I thought it's going to be okay because I only visually checked that it looked taller than the \textstyle version. Welp.
Anyways. I would still appreciate if this template can forward every attribute that <math> accepts as a named parameter, but the sheer number of #if: requried is starting to scare me. Or perhaps I should just open a ticket on Phab so they simply do this nobreak thing on the output from the extension itself. --Artoria2e5 🌉 16:43, 21 June 2025 (UTC)
- Apologies for undoing multiple edits on the doc page. I thought I'd checked that it was only the specific part on the
|display=parameter, but the other parts of the diff were off the bottom of my screen and I failed to scroll. Thanks for restoring your wrapping illustration. - Maybe we should see what it is that you're trying to do. My familiarity with
<math>attributes admittedly does not extend beyond<math display="block">and<math display="inline">, so it seemed that the only real use would be optionally adding the\textstyle, which can be done just as easily explicitly. You mention "every attribute that<math>accepts as a named parameter" – what are these? - Getting the nobreak thing fixed properly makes sense to me; it is a pain that a workaround is needed. But that is orthogonal to this change, as I see it. —Quondum 17:06, 21 June 2025 (UTC)
Punctuation doesn't seem to stay attached anymore
editPreviously my impression was that this template kept following punctuation attached to mathematical expressions, so if I used it immediately before a (plain text) comma, period, semicolon, closing parenthesis, quotation mark, or the like (for example, , where , , , and are elements of ) it would prevent punctuation symbols from moving onto the next line by themselves.
That doesn't seem to happen anymore. Instead, if the line ends at an inopportune spot, I end up with a bit of bare punctuation at the start of a line. Can anyone try to experiment and figure out how to fix this? @Quondum any ideas? –jacobolus (t) 00:10, 29 July 2025 (UTC)
- I found that wrapping behaviour can be highly browser-dependent. I still find that it is working properly on the six different browser–OS combinations that I have set up, with the trailing punctuation remaining attached. What browser are you using? —Quondum 00:56, 29 July 2025 (UTC)
- I'm on Mac Safari v. 18.2. But I'm fairly certain that this worked previously on Mac Safari. I wonder what might have changed. –jacobolus (t) 04:39, 29 July 2025 (UTC)
- After fiddling for 20 minutes, I can't figure out any way of fixing this from the template or user CSS. :(. –jacobolus (t) 05:37, 29 July 2025 (UTC)
- Not sure what changed. Likely I was not methodical enough last time. I am now seeing the same as you (macOS 15.5, Safari 18.5). A two-sided test: ((((( ))))) ((((( ))))) ((((( ))))) ((((( ))))) ((((( ))))) —Quondum 13:08, 29 July 2025 (UTC)
- I find that the left side is fine (stays stuck), right side wraps separately. Argh! —Quondum 13:13, 29 July 2025 (UTC)
- Safari is just whacko. With one of my sandbox tests, as I progressively reduce the window width, it can go from wrapping to not wrapping to wrapping again of the same line. —Quondum 14:23, 29 July 2025 (UTC)
- There's been a bunch of new CSS rules about wrapping in the past few years, because CJK wraps differently from alphabetic scripts, so there's been addition of new rules for picking between various possibilities. It's possible in implementing those the Safari folks accidentally changed something about wrapping of punctuation that appears after (but not in) an explicitly no-wrapped span. –jacobolus (t) 16:55, 29 July 2025 (UTC)
- The wrapping that I'm seeing is between things that are both inside the nowrap span. There is not any wrapping between the characters inside and outside the nowrap span. —Quondum 18:45, 29 July 2025 (UTC)
- Are you sure? What happens here is the closing parentheses (as a group) break to the next line, with so we get «nowrap span»[break]«parentheses». –jacobolus (t) 19:24, 29 July 2025 (UTC)
- What seems to be happening is that the wrap point is happening immediately after the closing math tag before the
⁠, which is staying stuck to the characters after the span. When I replaced it with one or printing characters, the visible printing characters wrapped along with the characters that followed the nowrap span. —Quondum 19:52, 29 July 2025 (UTC)
- What seems to be happening is that the wrap point is happening immediately after the closing math tag before the
- Are you sure? What happens here is the closing parentheses (as a group) break to the next line, with so we get «nowrap span»[break]«parentheses». –jacobolus (t) 19:24, 29 July 2025 (UTC)
- The wrapping that I'm seeing is between things that are both inside the nowrap span. There is not any wrapping between the characters inside and outside the nowrap span. —Quondum 18:45, 29 July 2025 (UTC)
- There's been a bunch of new CSS rules about wrapping in the past few years, because CJK wraps differently from alphabetic scripts, so there's been addition of new rules for picking between various possibilities. It's possible in implementing those the Safari folks accidentally changed something about wrapping of punctuation that appears after (but not in) an explicitly no-wrapped span. –jacobolus (t) 16:55, 29 July 2025 (UTC)
- Safari is just whacko. With one of my sandbox tests, as I progressively reduce the window width, it can go from wrapping to not wrapping to wrapping again of the same line. —Quondum 14:23, 29 July 2025 (UTC)
