PTX Parser - #46
Conversation
|
@MichaelHatherly Does my comment about the longer match make sense ? Is this something we can apply to this package ? Here's the GNU Docs for flex
|
Yes, so long as it doesn't end up breaking the existing interface that would be fine to add I think. |
MichaelHatherly
left a comment
There was a problem hiding this comment.
Adding some tests to the test suit for this lexer would be great.
| PTXLexer, | ||
| RLexer, | ||
| TOMLLexer | ||
| TOMLLexer, |
|
#64 has been merged which now requires the grammars for languages to be treesitter grammars. Those are relatively easy to write, or perhaps one already exists for PTX, in which case a JLL package would be needed that wraps it. After that you'd be able to easily highlight PTX with the upcoming version of Highlights. In that light, I'll close this since it is now not applicable to the codebase. |
I don't think it looks too bad.

Looks like
Using the theme:
My main annoyance is that the lexer isn't greedy. Given some regex like
(is)|(island), the lexer will happily matchiswhereas I would prefer that it matches the longest possible string. Lex/GNU flex is greedy and I like that approach. Another I want to match a word:\w+it will happily keep matching a single letter at a time, it evade this behaviour we can capture an anchor too, like\w+[ \t,\.]. However it would be more comfortable to not capture this anchor and deal with it via another rule.