-
Notifications
You must be signed in to change notification settings - Fork 0
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
[CLOSED] Expose code inspection providers for the extensions. #4714
Comments
Comment by zaggino
|
Comment by zaggino
|
Comment by peterflynn What would you think of changing the API to something like: One thing I have in mind is the possibility of providers becoming async (#5137). An |
Comment by peterflynn
|
Comment by zaggino
|
Comment by peterflynn
|
Comment by zaggino Done, with a bit of optimization. Original code was multiplying event handlers on the results table with every render. That should be solved now. Please review |
Comment by peterflynn
But from my quick glance, I'm a little concerned about possible race conditions in run(), e.g. if you switch files before the provider has returned results. Since we're getting close to the end of the sprint and thus a bit more risk-averse, I wonder if the best thing for now would be to take out the support for async providers. That makes it easier to land the API you need before the sprint ends -- and we could introduce async providers next sprint without breaking API compatibility. What do you think? |
Comment by zaggino
|
Comment by zaggino and right now - unless someone installs an extension with async provider, it won't be used anyway... |
Comment by peterflynn
|
Comment by zaggino ok |
Comment by zaggino Done, |
Comment by zaggino
|
Comment by peterflynn
|
Comment by peterflynn Actually two other thoughts:
|
Comment by zaggino Fixed the comments. About the FileEntry vs FullPath thing, currently in my extension I have this piece of code to call the method, so fullPath would be easier in my situation but might not be better for others. |
Comment by peterflynn Oops, actually one more thing, now that I've been running on this branch: the built-in JSLint provider returns null anytime there are no errors, so the console winds up littered with warnings. I wonder if we should actually get rid of the warning and just continue to allow null as a return value? Now that run() uses getProvider() as a helper, we don't really need non-null results to help disambiguate no-provider vs. no-errors... |
Comment by zaggino Ok, I've removed the warning. |
Comment by peterflynn Great! I'll wait until tomorrow morning to see if Also had one other suggestion, if we're going to make one more commit anyway: I think the docs for |
Comment by zaggino Ok, will fix that comments ... also I can squash these commits into one before merging, so the history of the main repo is not polluted unnecessarily with too many commits. |
Comment by gruehle Yeah, I prefer using a pathname for I had another thought: why not store the code inspection provider on the language object? This way you can just use |
Comment by zaggino Did the One more thought, currently there is only one possible file inspector for one language but in the future, there might be desired feature to support multiple code inspectors who check for different things. Like I can use jshint on my JavaScript files but I also want an extension that checks for patterns that are forbidden in a specific framework like dojo or yui. |
Comment by peterflynn
|
Comment by peterflynn
|
Comment by zaggino I've removed Currently if there's no default provider for the given file type, |
Comment by gruehle
Making |
Comment by peterflynn
|
Comment by zaggino Yes, that'll be better. Squashed now. |
Comment by zaggino
|
Issue by zaggino
Sunday Sep 08, 2013 at 04:20 GMT
Originally opened as adobe/brackets#5125
As mentioned in adobe/brackets#4588 (comment)
API that fetches the active linting provider for a given file entry.
zaggino included the following code: https://github.com/adobe/brackets/pull/5125/commits
The text was updated successfully, but these errors were encountered: