Comment fixes; Various updates

[kylebarron]

I would have opened this on pschumm/Stata.tmbundle, but issues aren't enabled on that.

I don't use TextMate, but Github uses pschumm/Stata.tmbundle for its syntax highlighting on Markdown documents on the site.

I'm the author of the Stata syntax highlighting package for Atom, and Atom happens to use the same syntax highlighting as TextMate, so the rules are transferrable to this package (I would just have to convert cson to plist format).

There are some errors with this package, for example, I just fixed comments syntax highlighting in Atom, so that it's more accurate than the do file editor. See this document to see Atom, the do file editor, and Github Markdown's highlighting (i.e. this package) side by side. The Github syntax highlighting could be improved in this regard.

Would you accept some PRs in this regard? I think that Github's highlighting will update automatically if the master branch on pschumm/Stata.tmbundle is updated.

[kylebarron]

@pschumm

[pschumm]

Would definitely welcome involvement of any kind, as the TextMate mode could certainly use some attention/improvement. And I'd be keen to have some consistency between what is available with TextMate and what is available with Atom (and VS Code), for cross-platform compatibility. Will take a look at the differences in comment highlighting you reference above.

UPDATE: I've just looked at your examples, which perhaps demonstrate a bit of ambiguity between Stata's documentation of its commenting syntax and the way its parser actually behaves. Moreover, IMO it is inconsistent for line continuation (///) to continue comment lines beginning with * but not with // (which is the more common behavior, e.g., in bash and python), which I presume is due to the unique way in which * is handled (e.g., it can be used interactively, while // cannot). Personally, I think use of * should be discouraged in do-files, in part because it cannot be used in Mata. That said, I agree that the syntax highlighting should reflect the actual behavior of the parser, so if you want to suggest changes to the language file to ensure that this is the case, please do.