Trying to add apostrophe to title text turns inputs into title text!

[brianharvey]

I tried to prepend the word "Brian's" to the title of this block. The apostrophe was filtered out, but now I see percent signs as title text instead of seeing inputs.

Worse, when I click "Apply," the block instance in the scripting area turns into just

[cycomachead]

Yes, can be please get rid of this 'power feature' that allows creating multi-word variable names? (It happens because of the %'my long input name' feature.

I'm removing the 'good student project' tag, because although this is simple, this one piece of code that needs to be re-written! There have been multiple issues (and at least a couple that are still open) related to parsing of inputs.

IMO, the '%' shortcut is useful, but beyond that, we really need to simplify what happens because there are too many oddities in creating block inputs. (Try messing with adding an input after the fact and things get very confusing.)

[cycomachead]

OH, the filtering is also due to the fact that apostrophes break XML serialization..., so that one was a no-go.

[jmoenig]

Well, this is tricky. To me, allowing multi-word variables - including formal parameters - is a critical feature and it has absolute priority, even over allowing apostrophes in block labels. But I guess one is as exotic as the other. I don't know any programming language that allows multi-word formal parameters, but then again I don't know any programming language that allows apostrophes inside function names :-)

[cycomachead]

I never said we remove the feature! I only said we remove the user shortcut. The '%' is, after all, a shortcut, time-saver feature. Edit: And I mean, only for multi-word names, single words are easy enough to deal with.

I agree that we should keep multi-word input names!

We can have both by having a XML encode / decode function for block specs. It really shouldn't be super hard. We just \-escape anything special, right?

[jmoenig]

that could work, you're right.

[brianharvey]

I'm not even insisting that apostrophe should work. But if not, I should get an error message, not a disaster! (Such as losing all my formal parameters, or losing everything when I hit OK.)

Also let me point out that this problem didn't arise in the initial make-a-block dialog. I was already in the Block Editor when I tried prepending the word "Brian's" to the title text.

In my humble opinion the root of the problem is using the same representation for internal storage of the prototype and for user I/O. The internal form should really be a list, not a text string, but with text strings as some of its elements. Or, if that's too slow to parse, at least use an invisible character (unicode < 32) to flag parameters. Then you can have any arbitrarily complicated translation from what the user types to the internal form. You can even let the user type % for parameters. And you can allow the two-character sequence %' for the beginning of a multi-word parameter, while still treating ' as an ordinary character in other contexts.

[cycomachead]

Yeah. It seems like we have two problems here:

• the inconsistency between the make a block screen and editor dialogues
• serialization vs internal representation. This one is pretty straightforward. We just need to clean up the internal methods. but this should be fixable.

Michael Ball
From my iPhone
michaelball.co

On Jul 12, 2016, at 12:45 PM, Brian Harvey notifications@github.com wrote:

I'm not even insisting that apostrophe should work. But if not, I should get an error message, not a disaster! (Such as losing all my formal parameters, or losing everything when I hit OK.)

Also let me point out that this problem didn't arise in the initial make-a-block dialog. I was already in the Block Editor when I tried prepending the word "Brian's" to the title text.

In my humble opinion the root of the problem is using the same representation for internal storage of the prototype and for user I/O. The internal form should really be a list, not a text string, but with text strings as some of its elements. Or, if that's too slow to parse, at least use an invisible character (unicode < 32) to flag parameters. Then you can have any arbitrarily complicated translation from what the user types to the internal form. You can even let the user type % for parameters. And you can allow the two-character sequence %' for the beginning of a multi-word parameter, while still treating ' as an ordinary character in other contexts.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[maryfries]

I've run into this too...

[maryfries]

If you add an apostrophe to a block name, it doesn't work (ok, fine), and instead it seems to merge the word with the next one (what?!), but it doesn't even show you that that's happened when you edit label, so you just lose part of your block name (not fine).

[maryfries]

Also, it's weird that I can have an apostrophe in a variable name, but not in a block name. This is yet another apostrophe inconsistency for the user.

[bromagosa]

Can we revisit this? In some languages (like mine) apostrophes are super important for meaning.

D'any → Of year
Dany → Harm
L'oli → The oil
Loli → Woman's name
M'és → It is to me
Més → More

Still low priority, but please don't let it be forgotten ^^

[brianharvey]

I'm with Michael, only more so. No %' in the make-a-block dialog. In fact, I wouldn't even mind no % in make-a-block! Or rather, % should just be a regular character with no special meaning.

Use some nonprinting character in internal specs, and if you have to have a power-user feature, use the same nonprinting character in the dialog! You can echo it as ◊ or something.

[cycomachead]

Imo the % shortcut is too valuable to lose entirely. But I do think we can have that and fix this issue — it’s just that I think it’s easier to create parameters as you are creating the block. Otherwise you’re more likely to just stick them at the end, which of course works but is nowhere near as pleasant. :)

[ghost]

Workaround: use the ’ character (the typesetter's apostrophe).