[Solved] 4.8.0 dev - Textile issue(s) ?

phiw13 · 2019-01-24 01:57:33

Install the freshly released smd_babel plugin. Go to the help panel.

Under the navigation box, you’ll see a block of text which doesn’t belong there. It looks like Textile formatted ordered list items which somehow fail to parse ? From looking at the source code for the plugin, this belong to the Translations subgroup.
There is also a list that fails to parse as list under the “Group selector” heading.

I’ve never run into this sort of Textile issues when used for articles. Possibly there is something odd in the plugin, or is the parser as used for the help files having issues ?

Bloke · 2019-01-24 09:31:10

My guess is this is related if not the same issue. I’ve not figured it out yet, but looking at the diff where the fix was applied (it took many attempts of compile-install-gah! until I got it to render all list items properly) notice that git thinks the spaces immediately after the hash marks are to blame.

I thought they were just typed as normal, but I now wonder if maybe not. I might have written one entry and then copied and pasted it to the others. Does copying and pasting a hash-space combo cause the space to be treated ever so slightly differently in the cloned content? I’d be surprised if it did – it’s just ASCII 32 character, right? – but further testing might reveal oddities.

For me, this also happens in Textpattern Body text in articles. Sometimes I can type a list and its fine, other times I get sporadic list rendering. Maybe there’s some totally bizarre thing going on and the “broken” entries are those that are pasted from copies of other list entries?

If anyone finds anything repeatable or – even better – a solution, please speak up!

Last edited by Bloke (2019-01-24 09:32:18)

Bloke · 2019-01-24 09:39:07

Okay, a very quick test I made in an article in 4.8.0-dev:

Making lists:

# First item
# Second item
# Third item

New list (items 2 and 3 copied from item 1 below):

# I'm first
# I'm second
# I'm third

Fini.

This rendered the following HTML when viewing the article on the public site:

<p>Making lists:</p>

# First item
# Second item
<ol>
	<li>Third item</li>
</ol>

<p>New list (items 2 and 3 copied from item 1 below):</p>

<ol>
	<li>I&#8217;m first</li>
	<li>I&#8217;m second</li>
	<li>I&#8217;m third</li>
</ol>

<p>Fini.</p>

Whaaaaat?!

EDIT: Saving the article a second time made no change to the output, even if altering the last line that had nothing to do with the lists. However, deleting the space between the hash mark and the number in the “broken” items 1 and 2 in the first list made the rendered HTML perfect. Those two entries were typed by hand as-is, line by line with no editing or cursor movements or anything in between.

Go. Figure.

Last edited by Bloke (2019-01-24 09:42:04)

phiw13 · 2019-01-24 11:29:24

I don’t know what the issue might be – I don’t remember running into it.

When viewing the diff on GitHub, I noticed that the old entries had # then then string. That space is a non-breaking space (U+00A0), aka option+space on macOS keyboard, instead of a space (U+0020).

On the flip side the code above gives only spaces. Or did the forum software alter something when rendering the code ?

Bloke · 2019-01-24 11:43:35

phiw13 wrote #316274:

That space is a non-breaking space (U+00A0), aka option+space on macOS keyboard, instead of a space (U+0020).

Holy cripes, that might be it!

On my US-centric Mac keyboard I don’t have a hash symbol. To render one I need to hit option+3. Now, consider this: what if I’m so super fast at typing (hehe, or the keyboard isn’t as responsive as it once was) and my finger lingers on the option key a fraction too long so that when I hit the spacebar immediately afterwards I’m actually outputting a non-breaking space. It looks the damn same to me on the screen but of course to Textile it wouldn’t match.

That would certainly explain the seemingly random nature of this and why it rarely affects other people! Plus, when I go back and delete the nbsp and replace it with a regular space, I’m nowhere near the option key. If that’s it, I need to either slow the hell down or just be more careful when using my MacBook :)

I think you may have just solved this. Thank you, sir.

phiw13 · 2019-01-24 11:54:13

Fingers accidentally resting on the option / command keys… That kind of silly things happen to me regularly – more often with the iMac, depending on how far away on the table the keyboard is placed. And more often of late, as my right hand is still very unhandy.

I’m an avid user of BBEdit’s “show invisible characters” feature. Also, if you don’t have it installed. Unicode checker (comes with a bunch of Services build in).

Bloke · 2019-01-24 12:21:57

phiw13 wrote #316277:

I’m an avid user of BBEdit’s “show invisible characters” feature. Also, if you don’t have it installed. Unicode checker (comes with a bunch of Services build in).

I’ll see if Sublime Text has something similar built in. Never thought to check the underlying markup of what I typed in that detail and – as you posited – pasting it into the forum converted it into regular spaces so the evidence trail went cold right there. Perhaps if I’d thought to run the output through od I might have spotted it…

Thank you so much. Been bugging me for ages.

Textpattern CMS

Textpattern CMS support forum

#1 2019-01-24 01:57:33