Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(Typescript) highlight obvious user defined type names (interface, etc) #3269

Open
amirqasemi74 opened this issue Jul 12, 2021 · 9 comments
Open
Labels
enhancement An enhancement or new feature good first issue Should be easier for first time contributors help welcome Could use help from community language

Comments

@amirqasemi74
Copy link

See this example:
image
as you can see in boudingRect params the Rect type has not been highlighted. also interface name.
I think these one should be highlighted

@amirqasemi74 amirqasemi74 added bug help welcome Could use help from community language labels Jul 12, 2021
@joshgoebel
Copy link
Member

joshgoebel commented Jul 13, 2021

This is because we are not a full TypeScript parser (nor do we desire to be), we're more of a "fancy pattern matcher". As such it's impossible to know that Rect[] there is a type... For some languages we can examine the immediate context but in this case that is also insufficient. : is used in many places in JS and ) isn't helpful.

Note: The [] in this case is strange, but even if that were a strong signal that would only allow us to detect Blah[] types, not all types in general, and therefore it'd be even more confusing - vs now where we highlight the "standard" types always, and simply do not highlight user types.


I'd love to see someone attempt a plugin/grammar pairing that hooked up an entirely different parser - with our HTML generation. https://github.com/codemirror/lang-javascript would be a good choice I think. If you're interested in a project like that, let us know.

@joshgoebel joshgoebel removed bug help welcome Could use help from community labels Jul 13, 2021
@joshgoebel
Copy link
Member

Rules could be added for the simpler cases such as interface [type]... this would be a perfect use for our new multi-class matcher support... but that doesn't help with params or types in other contexts.

@joshgoebel joshgoebel added enhancement An enhancement or new feature help welcome Could use help from community good first issue Should be easier for first time contributors labels Jul 23, 2021
@joshgoebel
Copy link
Member

Rules could be added for the simpler cases such as interface [type]...

Tagging as "good first issue" as these simple cases shouldn't be too hard and there are examples from other modern grammars, like Wren.

@joshgoebel joshgoebel changed the title (Typescript) not highlight user defined types (Typescript) highlight obvious user defined type names (interface, etc) Aug 29, 2021
@joshgoebel
Copy link
Member

Also worth exploring if this could somehow just be handled by a general CamelCaseIsAClass rule...

@deepto98
Copy link
Contributor

deepto98 commented Oct 9, 2021

@joshgoebel I can pick this up, but will need some guidance as to which existing examples/files I can refer to and how I should approach this

@joshgoebel
Copy link
Member

I dunno about samples. I think start might be just a CamelCaseIsAClass as mentioned above which we already have examples of in Ruby and JS I think?

@nbeck415
Copy link

I have a possible solution that I can link -- I noticed the CamelCaseAsAClass behavior and attempted to fix it based on looking for any titles following "interface." Right now, I only have an implementation for interfaces, but if everything looks good I can implement this for other instances of user-defined types or variables

@MohamedAli00949
Copy link
Contributor

Hi @joshgoebel,
I want to fix this issue and I have a suggested solution to this issue this is the result I have reached now.
I want to know what I should do else edit the typescript file and update the markup tests to make a valid solution.

image

Thanks in advance,

@joshgoebel
Copy link
Member

I have a suggested solution

What is your suggested solution? Just make a PR with your changes and we'll have a look.

update the markup tests to make a valid solution.

You can edit the existing tests or add new ones... if you look at the markup test js file itself you can uncomment a line to have it write the expectations for you, but you should still read the result to make sure it's correct... the developer tool in debug mode is also super helpful for this kind of thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An enhancement or new feature good first issue Should be easier for first time contributors help welcome Could use help from community language
Projects
None yet
Development

No branches or pull requests

5 participants