Open Will-Sommers opened 1 year ago
Heyo @pokey — circling back on this. Although the PRs here are a little dated, I'm going to restart the conversation. Most people seem in favor although I guess it will likely break other plugins that rely on JS
being defined.
https://github.com/michaelgmcd/vscode-language-babel/issues/95 https://github.com/flow/flow-for-vscode/issues/187
If these changes didn't happen, I guess I could look at building a custom extension which shouldn't be a huge huge deal to keep updated.
Other options don't seem great since languageId
is so tied to which grammar is chosen. I think we'd need to get into some sort of override/configuration via CSV or something like that. There's a lot that would go into that including bundling a parser here that is never used by default, so I'll leave it here for further pondering.
I'm not sure I understand the problem from Cursorless / parse tree perspective. If the tsx parser handles flow out of the box, why can't we just merge this, and then do roughly the same thing in cursorless, like we do for sass / css? And then if necessary we can add another two lines to activate on flow language id as well
But maybe I'm missing something?
Right now the public extension doesn't expose a new languageId
, unlike the Sass/css.
I'm not sure how cursorless will determine which parser to use given this.
When you say "which parser to use", I'm confused. You mentioned earlier that the tree-sitter-tsx parser supports flow out of the box. So what are the parsers to choose from here? Is it not just one parser? Do you mean choosing between typescript and tsx parser? Or by "parser" do you mean which Cursorless patterns should be active? Maybe it's worth dropping into a meet-up to discuss; there's one tomorrow
But if not super high priority on your end no rush
Thanks for the quick response @pokey. Let me ask a question instead of making an assumption.
If there is now languageId
for flowjs files defined, will we have a problem? Right now the public flow extension treats flow files as regular javascript files and doesn't define a languageId
for htem.
If that's the case, and if the parser we use for javascript files already supports flow, then you should be able to just add any necessary patterns to our typescript patterns in cursorless and then you don't need this PR
sorry I lost track of this one. Where did we land on this and #51?
Heyo @pokey —
It looks like the
tsx
parser supports flow types. The flow and hack additions were previously one but I separated them because I think there should be some discussion here.I installed this Flow Language Support extension to see if it defined a languageId is defined using the plugin. I'm not seeing the ability to create
Flow
files which makes me think that I'm either doing something wrong or it might break thelanguageId->parser
default mapping.I'm going to play around with it a bit more and see what's up.