https://github.com/bitRAKE/fasmg_syntax

There is much nuance to fasmg syntax to account for when trying to integrate the language into various systems. For better or worse I've collected much of the details into one place with scripts that create syntax configurations for: NPP (UDL), TextMate, ...

Some success has been seen in present work, but testing every editor is beyond my ability. Tomasz might even be shocked by some valid syntax, but at least it's covered explicitly.

If you're trying to implement fasmg syntax this is probably a good place to continue after the manuals, imho.

Excellent work! I skimmed through the notes and they seem well-researched and correct. I noticed one that requires clarification, though: The "#" does not reset anything, the other parts of identifier still have the context info they had. Think of it a kind of rich text, with invisible "color" applied to some of the tokens. The snippets of text you carry around in variables/parameters keep the "color" corresponding to their context and the only way to remove it is with RAWMATCH (which gives a result similar as if you converted the tokens to string and then passed the string through EVAL again).

However, for symbol identification purposes the assembler only uses the context that applies to the first token of the identifier. The coloring of the subsequent tokens does not matter. This is why inserting "#" right at the start of the identifier forces it to be interpreted in context valid for this "#" character, which is usually the current context. It is the color of "#" character itself that matters.

BTW, the whitespace-sensitivity of identifiers is there to provide compatibility with fasm 1, which had "." and "?" as non-special characters that could be used in names. Thus fasmg's identifiers, even though they may consist of multiple tokens, correspond to fasm's single-token names. And whitespace-sensitivity is crucial to distinguish things like "db?" and "db ?" in fasm-compatible way. And the concatenation operator forbidding the whitespace allows things like #-prefixed literals that some assembly dialects use, with an important distinction being "db#1" vs "db #1".

Thank you.

Ideally, I'd start with the first version of fasmg and gather test cases through the versions. Then the python script would execute the tests applicable for the version. I don't have time for that curation at the moment nor do I think it that useful. The better approach is probably to make the version commit based, but that ties the information to git.

Most highlighting is quite "surface" - something like Tree-Sitter would be need to express the dynamics of potential fasmg source -- to get the kind of intellisense that some people desire.

I also see your notes as an alternative reference material for fasmg syntax, and this is a very valuable resource. It is great to have high-quality alternatives to the official manual, even if they just rephrase the same information. If anyone has doubts when reading what I wrote, if they find something not explained enough, they can cross-check with alternative references like the one you made, and having the same information expressed differently by different authors allows for more clarity.

Old versions often mean dealing with bugs and personally I think it would be a waste of resources. Especially since fasm2 requires features that were added relatively recently.

In the extreme this might be an irreducible problem. That is, you would probably need to reproduce the entire assembly process to see exactly how the portions of the text end up interpreted. I would not chase the perfection here, a simple ruleset already covers the usual cases.