Superscripts get stuck
While running through the syntax guide (love the support for super/sub script!), I was playing with superscripts and MMD got stuck. Unless I misunderstood the guide.
Here's a screen print. It's the second line with the long superscript I'm talking about. I took from the guide that a long superscript was both begun and ended with a ^. That means that the period and "This" following that second ^ should be regular text, not part of the superscript, but as you can see MMD is still showing them as superscripted on the left-hand side (not in the Preview, though). I assume (hope?) that's a bug.
(On an unrelated note on the guide, you might put some text in the code block example indicating that the indent is X spaces. You can't tell by looking at it how many spaces are being used. E.g., the text itself could say, "To make a longer section of code on multiple lines, indent the lines four spaces.") Or "four-to-six," if I remember something I read elsewhere about MMD.)
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
Support Staff 1 Posted by Fletcher on 19 Aug, 2017 08:03 PM
Your screenshot didn't make it through, but I figured out what you're describing.
I had changed superscripts in MMD a while back and had to tweak them again in Composer. I almost never use them myself -- this is fixed for next release.
Thanks!
Fletcher closed this discussion on 19 Aug, 2017 08:03 PM.
Vince re-opened this discussion on 19 Aug, 2017 08:09 PM
2 Posted by Vince on 19 Aug, 2017 08:09 PM
Hmmm, that's interesting (the "Attach File" section showed the file.
I continued on and ran into some more problems that may be related and fixed as well. First, subscripts can get stuck, too. Second, I had a subscript that just flat didn't work, i.e. "This is a ~s~ubscript" didn't show the ~s~ as a subscript on the input side OR the preview side.
And after all of that, the line spacing on the input side is off — I have it set to 1, but it looks like it's at least 1.5. I'm guessing it got off by the sub/super scripting I was doing above.
I'm trying again to attach a screenshot. If if doesn't work and you can't figure it out, I can email it to you.
3 Posted by Vince on 19 Aug, 2017 08:14 PM
(I did this once but it didn't show up even after I refreshed several times. I'm doing it again, so if it shows up twice you'll know why.)
Interesting; the Attach File section showed the file, don't know why it didn't make it.
I had some more problems. The first one might be the same cause and thus fixed already — I got text stuck in subscript mode as well on the input side.
But I also had a subscript that just flat didn't work — "This is a ~s~ubscript." didn't show the "s" as a subscript on the input OR the preview side.
And after all of that, my line spacing on the input side looked it was at least 1.5, even though I have it set to 1 in Preferences. I'm guessing it got messed up by the super/subscripting.
I'm trying again to attach a screen print. If it doesn't make it, I can email it to you if you need it.
Support Staff 4 Posted by Fletcher on 19 Aug, 2017 08:41 PM
Superscripts/subscripts in MMD have to come before/after something. So
~s~ubscript is not a valid MMD subscript.
And yes, in Apple's NSTextView, adding super/subscripts increases the
height of the line. I'll keep looking for a workaround, but thus far
haven't found one.
5 Posted by Vince on 19 Aug, 2017 08:52 PM
?? It was after something. It was after "This is a ". What do you mean? (And whatever it is you mean, you should also specify in the syntax guide.)
Support Staff 6 Posted by Fletcher on 19 Aug, 2017 08:53 PM
All of the examples in the guide show super/sub-scripts following a letter, not a whitespace.
Support Staff 7 Posted by Fletcher on 19 Aug, 2017 08:55 PM
Just reread my earlier message -- the "before/after" should just be "after".
8 Posted by Vince on 19 Aug, 2017 09:08 PM
Don't make people read your mind. There's no way to infer from two examples that they don't work as the first letter of a word. If you had ten examples no one would infer that. Just include an example of what doesn't work.
This ~d~oesn't work because sub/superscripts have to follow a non-whitespace letter.
Everybody wins — we know explicitly what works and what doesn't, and you don't get bothered by pesky questions.
Another example of this are the "foo bar" examples in the Linebreak section. I had to save an example file and hex dump it to see what it was causing that second foo bar to line break. Make the example explicit, don't make people guess (we can't see spaces).
This line has two spaces at the end
to make it line break.
9 Posted by Vince on 19 Aug, 2017 09:13 PM
Since this is in GitHub, I'll be glad to make these minor changes and issue a pull request. But I also understand if you'd rather keep control of it.
Support Staff 10 Posted by Fletcher on 19 Aug, 2017 09:19 PM
Happy to accept pull requests (that's why I put all my open source stuff
on GitHub), but I really want to keep it to simple examples, not
descriptions of what to do and why. That stuff belongs elsewhere.
Thanks!!
Fletcher closed this discussion on 21 Aug, 2017 05:19 AM.