[meta] Choose and alter wildcard scope to reflect replacement length

[michaelblyons]

What do you folks think about changing the subscopes of constant.other.wildcard from the character used to the semantic meaning? This would let color schemes distinguish on what a wildcard does rather than what character it uses.

• Remove .asterisk, .questionmark, .underscore, .percent, etc.
• Replace with something like this (feel free to suggest better words)…
  • .character to indicate "This represents one char"
  • .string to indicate "This represents a variable-length string"

Possible downsides

• Is it important to distinguish wildcards that mean zero-or-more characters versus ones that mean one-or-more characters?
• Wildcards (if any) that mean a particular length of characters above one.

[deathaxe]

Given SQL currently being the only language with anything else than asterisk and question mark, what's the issue? The scope being named like the character it represent? Ignoring SQL, does any language use different wildcard chars?

I'd personally be interested in constant.other.wildcard, only. Anything else maybe be of rare interest.

Hence removing or renaming would be fine, but please just not one of those lengthy-dashed-sub-scope-names.

[deathaxe]

We just shouldn't end up with something like Python, which scopes each comma different, leaving color schemes behind with punctuation.separator being the only common scope. This probably doesn't apply here, but seems a worst-case out come of attempts to apply semantic highlighting.

[michaelblyons]

We just shouldn't end up with something like Python, which scopes each comma different, leaving color schemes behind with punctuation.separator being the only common scope.

Agreed, although I confess I did not notice Python's problem myself.

My aim is to make fewer not more options. Since constant.other.wildcard is pretty new, we have a better chance of doing that soon rather than sometime later. ¹

Footnotes

1. For example, I'm also not completely happy with constant.other.[wildcard|placeholder], but I think there is not realistically a way to get other removed at this point. ↩

[deathaxe]

Think of [constant|variable|...].lanugage vs. [constant|variable|...].other to distinguish language defined from user defined entities (constants, variables, ...). Actually asterisk would also fit under the former, but this was not agreed on, like with variable.language.anonymous for _.

variable.function already doesn't fit that concept, hence I am uncertain about adding more, especially as placeholders are primarily just tokens defined by the format-string functions, using them. Same may or may not be true for wildcards, but I don't think it's worth separating them.

variable.other.placeholder is quite old. Moving it to 2nd level may have some impact. Moving wildcard only, doesn't really make sense.

As wildcards are also just placeholders, something like constant.placeholder.[wildcard|format] might work, but the impact for placeholders would still be the same.

Which scope could replace asterisk and questionmark? single|multi? The issue is it not only denoting characters in path strings, but also being used in import statements of Java/Python/PHP. I don't want to introduce separate scopes for chars and imports, tbh.

[michaelblyons]

Which scope could replace asterisk and questionmark? single|multi? The issue is it not only denoting characters in path strings, but also being used in import statements of Java/Python/PHP. I don't want to introduce separate scopes for chars and imports, tbh.

This is a good point! My OP words also don't feel good for SELECT * or SELECT t.* in SQL.

Something feels odd to me about multi, but it's definitely better than string.

As wildcards are also just placeholders, something like constant.placeholder.[wildcard|format] might work, but the impact for placeholders would still be the same.

Agreed. This was also the best idea I have, but I didn't mean to start an argument over it here. 😅

[deathaxe]

multi is certainly not ideal. There is this keyword.operator.variadic. Does that describe * better? -> constant.other.placeholder.[single|variadic]

[michaelblyons]

"Variadic" is not a commonly used word in English. I've only seen it in the the context of parameter expansion. I guess it might be appropriate for the import statements and SQL, but I don't like it for string-likes.

Other terms I've thought of that also feel unsatisfying: sequence, collection, all, expansion.