When adding a new feature, perhaps rather than xxxx it would be nice to have a dropdown of possible feature names? Sometimes it’s hard to remember the correct abbreviation for each feature.
When adding Languagesystems, a list of registered ones could pop up? (But also make sure the user can add their own)
When adding # Automatic Code End, no error is generated. It should be # Automatic code end (this took me a while to debug)
Do you mean in G3? In G2 it’s only adding DFLT dflt automatically; Perhaps that’s because I’m using custom naming in this particular file (the glyph properties are set correctly with script=myanmar)
If you use the script and language keywords anywhere in your code, they should be reflected in Languagesystems automatically. Can you send me the .glyphs file?
I was thinking of something like you have for Unicode ranges, would that be possible? Some scripts have tags that are not immediately guessable, and I’m always having to check the casing for ‘languagesystem’ vs ‘languageSystem’ vs ‘LanguageSystem’. I also believe that three-letter codes need to be appended with a space, which is very easy to miss.
Both script and language tags work with autocompletion, just like glyph names. Doesn’t matter what letter case you start with: accepting the chosen completion from the popup will make the whole thing the right case, just like you see it on the list. You can also invoke the autocompletion popup even without typing anything. Just press the Esc key before typing a tag (or just anything that is supported with autocompletion).
No need to worry about that, not in the feature code at least (the space is appended automatically by the compiler).
Bear in mind that it’s pretty common for the fonts to be compiled in different workflows, it’s not always Glyphs that does the exporting. It would be safer if a quick autocorrect could manage syntax errors of that kind.
As far as the spec is concerned, tags are nor required to end with spaces (emphasis mine):
Tags are four-letter identifiers. These are denoted simply by tag name, without any final spaces, and are distinguished from glyph names by context. For example:
DEU
Note that the final space in the example is implicit.
So, in theory, no matter the tool reading/writing/manipulating the feature code, you shouldn’t worry about it. In practice, though, this might not be the case, of course. Do you have any examples where the final spaces are not handled automatically?
In the feature file syntax, whitespace is insignificant in general: no special meaning is applied to it except to separate tokens, and you can format your code however you like. In a language like this, it wouldn’t make much sense to expect or enforce any extra spaces. That is all by design. But again, if you have any examples that the lack of those final spaces is causing trouble in some other tool or workflow, please let us know!