Community
Participate
Working Groups
Consider the following snippet: /** * @name myfunc */ function myfunc() {} If you select the function name and run Rferences > Project, the match in the comment is placed in the 'unrelated matches' group. We should improve the type-checking for a block comment to see if it is talking about the function type we are searching for. We should also be checking @see, @param, @return(s), @memberOf and @type.
New Gerrit change created: https://git.eclipse.org/r/70360
The change looks good in the refsCommand code, but I would prefer if you could move the change out of doc_comment - the reason being, doc_comment is a Tern core plugin, and we are trying to avoid making any changes in the Tern code unless absolutely necessary.
Yes, "trying to not hurt any Tern-related stuff" is the main issue I faced in last two weeks. Since the mechanism behind Tern still remained obscure to me, I hardly can find a way to ensure my change will not influence Tern's functionalities. This issue also caused a hard-time with https://bugs.eclipse.org/bugs/show_bug.cgi?id=481271 because sometimes there are just strong signs showing we have no other way rather than changing tern.js or infer.js or its plugins directly. Mike, could you elaborate Tern's mechanism (like how Tern populates its types in the fileMap)?
(In reply to Troy Tao from comment #3) > Yes, "trying to not hurt any Tern-related stuff" is the main issue I faced > in last two weeks. Since the mechanism behind Tern still remained obscure to > me, I hardly can find a way to ensure my change will not influence Tern's > functionalities. This issue also caused a hard-time with > https://bugs.eclipse.org/bugs/show_bug.cgi?id=481271 because sometimes there > are just strong signs showing we have no other way rather than changing > tern.js or infer.js or its plugins directly. Mike, could you elaborate > Tern's mechanism (like how Tern populates its types in the fileMap)? In the case of your changes, it will actually break Terns' ability to process type infos from comments, since you change what used to be a string to an object. It might make more sense to add the processing in the refs plugin (web/javascript/ternPlugins/refs.js) when we make the request to Tern. You can ask for the AST and leading / trailing comments for a given node (or node parent). There is already a section in there specifically for block comments, which might be useful.
New Gerrit change created: https://git.eclipse.org/r/70483
I have uploaded a new git commit where the Tern plugin keeps unchanged.
Created attachment 260903 [details] Trying to add other jsdoc directives like params but failed to show the result in the final panel. I tried to add other jsdoc directives like params to refs but failed because I can only see a blank clause in the final panel after adding directives to "expected.result" variable. It seems there are other steps happening outside refsCommand.js
testing the last gerrit, and I found that if you have the same name in doc in other files it is incorrectly tagged as an exact match. For example I have more than one file with an '@name myfunc' JSDoc tag in it, and they are all marked as matching - when only the doc attached to the function in-context should be a match. I'll attach a screen shot showing what I mean.
Created attachment 261051 [details] screen shot Notice also there is a 'perfect match' being reported against a name match in a globals directive...
I have uploaded a new change. The previous one failed because of a wrong understanding of several methods like Finder.findComment. It seems that in current Orion, we dont have a strict connection between a AST node (function declaration) and its doc. The interpretComments is doc_comments.js is the only place where we connect doc to a node and it is a very loose one because as long as there is more than two new lines between a function and its jsdoc, tern refuse to think them as together. Besides, for the jsdoc checking step (check things like format), my original thought is to change the jsdocInterpretComments in doc_comments.js but since tern's plugin code is better keeping unchanged, I put that step in refsCommand.js
I think we need to go for a more general approach here. We should attach the doc comment infos directly to the node they reference as well as tag the comment object with the node infos it talks about. This would allow us to very quickly find the relationship between doc and nodes without forward lookups, and could also be used for: 1. occurrences in doc 2. param hovers - show only the params doc instead of the entire function doc 3. content assist - show only param / name doc instead of root node doc
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg04114.html
