Tweaks to variable syntax about ecmarkdown

[domenic]

%Math_pow%(_base_, _exponent_)

showed up in https://github.com/rwaldron/exponentiation-operator/blob/master/spec/index.html

Can we do this better via some heuristic? E.g. variables are not allowed to contain % and (? I like that idea.

[jmdyck]

You could say that % is yet another format-delimiter, so %Math_pow% is recognized as a percent-format, preventing _pow%(_ from being mis-recognized as an underscore-format.

[jmdyck]

Mind you, it is a good idea to restrict the characters allowed in an underscore-format. In the ES spec, I think the only characters in metavariable names are [A-Za-z12].

[bterlson]

Should I only accept [\w\d] inside var maybe?

[jmdyck]

Careful: \w includes underscore, which you don't want to allow.

[bterlson]

Lol. Good point. But I want to allow word-like Unicode characters... what's the best way to do this?

[jmdyck]

In a JavaScript RegExp? I think the only way to do it is to enumerate the code-point ranges, which I imagine would be a pain.

But why would you need anything other than [A-Za-z0-9]? Is someone going to write ES proposal pseudocode in a language other than English?

[bterlson]

Maybe? :P But I'll go with your suggested ranges for now.

[domenic]

tc39/ecmarkup#27 implies we should allow < and > in the set as well. (I assume ecmarkup passes ecmarkdown <key>, not <key>.)

[bterlson]

Currently Emu passes <key> but it needs to pass <key> if that's what was written in the source document. Reason being that <key> is clearly an element when the author clearly did not intend that when they wrote the escape characters.

But what is this <key> convention anyway, @caridy?

[domenic]

Currently Emu passes <key> but it needs to pass <key> if that's what was written in the source document.

Yeah I guess this comes down to what level EMD operates at. And we're moving away from it operating on small slices of textContent, instead toward it operating on larger chunks of HTML/EMU. So I agree with you. I guess the allowed set then includes & and ; (and maybe #); good times.

It would be nicer to eliminate variables with < and > in them though.

[bterlson]

Thoughts on the following:

_foo_bar_ ==> <var>foo_bar</var> or _foo_bar_

[domenic]

I would have thought <var>foo</var>bar_. The first five characters parse great as a variable.

[bterlson]

The middle _ is not a valid format end since it is followed by alpha-numeric characters. But is what you suggest desirable? I can do that too.

[domenic]

I think it is... We specifically want to allow intra-word variables like _SIMD_Constructor, so this seems to follow automatically.

[bterlson]

Hmmmm, ok. I had thought SIMD was a sigil they wanted to emit as-is in the output doc (rather than wrapping in var and removing underscores).