Hey @zep,

I notice you can use the double-width katakana glyphs as identifiers, but I don't think you added the new printable single-width characters below chr(32) to the "legal chars" set for identifiers.

So I could use ta/た in a variable name, but because I need the single-width dakuten at chr(30) to make da/だ, I couldn't write a variable named, e.g., だくてん.

I figure if it's not a placeholder glyph (like the first 10 or so) and not reserved for Lua, it ought to be legal for identifiers, based on how every other glyph has been. Am I right?

I'm asking specifically because I'd like to use one particular character in place of 'self' in my code, to keep my code concise on the tiny PICO-8 screen, but I can't currently use it because it's not legal.

Ooo, this is fixed too! So happy! 😀

Wait, no, it isn't fixed. I still can't use most of these as identifiers. Yes, I can use a dakuten or a handakuten now, but not any of the other 16.

Not happy after all. 🙁 I mean, it's good that full katakana works now, but that's not what I personally needed. I want to be able to use something like the single-width block character, or the mid-dot, or even just the yen symbol. It would be nice if the whole 16-character set in chr(16 thru 31) were valid identifier characters.

I mean, if I can use a double-width block as an identifier, why not a single-width block, or a triangle, or a little circle?

If I were zep I'd be reserving some chars for future operators.

Hm, I'd like to think zep wouldn't try to use non-ascii characters, which you can only type in katakana mode, for operators.

Also, even if it's only ever going to be extended to make kana variable names viable, it think it should probably have the mid-dot character added, since that's something you might use in Japanese the way we use an underscore in English identifiers:

フリース・エネッレン = "my name in katakana"
print(フリース・エネッレン)

But maybe a native Japanese speaker could comment on this with more insight as to usability.

Ah fair enough, yeah, I misunderstood which characters you were referring to. And mildly agree that middot could maybe be an underscore but mine is not an informed opinion.

@zep

I'm gonna necro this for three reasons of varying importance to you:

First is that pasting a mid-dot from outside PICO-8 is broken.

If I copy this example code from above:

フリース・エネッレン = "my name in katakana"
print(フリース・エネッレン)

...and paste it into PICO-8, I get this in the editor:

フリネ⬇️もスネ⬇️めエネッレン = "my name in katakana"
print(フリネ⬇️もスネ⬇️めエネッレン)

Seems like it's converting ・ to ⬇️もスネ⬇️め, presumably the utf-8 escape sequence for mid-dot.

I can manually type a mid-dot inside PICO-8 with (^K)ana mode using the '/' key, I just can't paste one in from outside.

Oddly, I can copy from inside PICO-8 and paste externally, so I'm assuming this is a bug and not an oversight.

Second, I'm just gonna emphasize that I still think the mid-dot character should valid for function/variable names, since, as I said above, it's sometimes used as a sort of space or apostrophe between unconnected katakana words, and katakana is valid for variable names, so it should be available for the sake of readability.

Third, I'm going to mutter something about my original request that all of chr(16..31) also be valid for var names, but I'm not gonna hold out much hope, since this didn't seem to go over the first time. Or maybe you just didn't read this post, Iunno. 😜 You do you. But it'd be cool to be able to use them.