panda3d
TextProperties: Should the Tags be Changed?
Description
In order to detect property-tags and the extents thereof within a string, TextProperties looks for certain markers in the string. As things stand, these markers are escaped characters--specifically, "\1" and "\2".
I'd like to suggest that we change those tags--or, in order to not break extant code, allow for an alternative set.
(For reference, an example of a full markup with the current set might looking something like this: \1<property-name>\1<text>\2--where "<property-name>" is an id given in code to a particular set of text-properties, and "<text>" is simply whatever text the properties are to be applied to.)
As an initial possibility, what about either:
- [1], [2]
- Giving an example something like this:
[1]<property-name>[1]<text>[2] - Or a concrete example something like this:
[1]italics[1]This should be italicised![2]
- Giving an example something like this:
or
- [<property-name>], [/]
- Giving an example something like this:
[<property-name>]<text>[/] - Or a concrete example something like this:
[italics]This should be italicised![/]
- Giving an example something like this:
Use Case
In short, it seems to me that escaped characters may be treated in special ways--or even disallowed by--text-parsing modules.
For example, the "tomli" TOML parser seems to dislike the "\1", "\2" nomenclature--although it's happy with "\u0001" and "\u0002" in their stead.
Having markers that are not escaped characters could alleviate such clashes.
I don't mind an easier-to-use tagging system that can be opted into.
My preference would be for the second, if we're going to be parsing text tags anyway. Also preferably something that doesn't typically appear in regular running text. The proposal looks similar to BBCode, or to the tags used by Python's rich library, which seems okay. Using {} is an alternative, though that might clash inconveniently with Python f-strings.
We'd have to have a proper way of escaping [ and ] where they do appear in the text. And I would like this new syntax to be opt-in, so users aren't surprised when things suddenly get interpreted as tags.
Yet another proposal is a more compact lisp-like syntax like here is text [:bold this is bold] this is not, but this is also probably a bit more alien.
Regarding the first three paragraphs, agreed, on all counts! And indeed, for maximum backwards-compatibility and predictability, having the new system be opt-in seems wisest.
(At least for now; I could see a major version of the engine considering making the new system the default--but that's another matter, and can be addressed at another time, if desired.)
Regarding the lisp-like syntax, hmm... I don't hate it.
It's perhaps a little less intuitive than the BBCode-like syntax (which also has the advantage of broadly resembling HTML, I feel). But only a little less intuitive.
It's overall pretty similar, and does have the advantage of being more concise.