Parse (** ... *) and /// comments as Markdown about ionide-fsgrammar HOT 3 CLOSED

Note that #6 uses text.md as the Markdown syntax. That may or may not be the best choice in the long run, so if something else is better for the sake of VS Code users, that can be adjusted.

from ionide-fsgrammar.

I'm not sure if I want to go with it. There is lot of assumptions done for this PR to make it work

1. It assumes Atom and grammar it's reused in both Atom and VSCode.
2. It assumes specific grammar for Atom (when other can be also used)
3. It assumes using markdown for comments (and you can't turn on-off grammar parts dynamically)

I will leave it open, and think a bit more about it. But for now I'm not sure if it's good idea.

from ionide-fsgrammar.

Yes, all those are issues that I thought of, and may be good reasons to say "no" to this feature. I have had a few ideas for fixing some of these, but haven't tested them yet:

1. What happens if you include more than one syntax grammar? I.e., if you include both the text.md and the source.gfm syntaxes? If the two syntax grammars would end up "fighting" over Markdown syntax, that would be less than ideal -- but if they wouldn't interfere with each other, then you could do:

"include": "atom-markdown-syntax-name",
"include": "vscode-markdown-syntax-name"

As for the "assumes using markdown for comments" objection, that was something I was willing to assume. The F# way seems to be to nudge people towards the "right" way to do things in a "pit of success" style, and Markdown is much better than XML for comment documentation. But if there is a significant amount of code out there using XML in /// comments, and people actively dislike finding it Markdown-highlighted, that would be a good reason to reject this idea.

I'll try installing both Atom's language-markdown and language-gfm plugins, to see if they end up "fighting" over Markdown-in-comments, and report my results.

from ionide-fsgrammar.