Community
Participate
Working Groups
As it currently stands, a plugin cannot contribute to the sidebar without adding its own _create* function in the siderbar.js class. It would be nice to have a way for plugins to contribute to the sidebar (the UI and a way to activate their custom UI).
A further note: assuming plugins did contribute their own _create* functions, they would also need a way to interact with the sidebar while its work is happening. Perhaps some kind of incremental service? So for example, the JS bundle could register for this service and be called back to with a result that I could do something with and pass an answer back about it.
(In reply to Michael Rennie from comment #1) > A further note: assuming plugins did contribute their own _create* > functions, they would also need a way to interact with the sidebar while its > work is happening. Perhaps some kind of incremental service? > > So for example, the JS bundle could register for this service and be called > back to with a result that I could do something with and pass an answer back > about it. This should be the approach. We should generalize the searchPane(or whatever we will call it) and ask plugins to feed implementation of some interfaces.
First cut of the fix. http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=395f0192432ebeeacc3f84756f862a662da73cae Currently we can not support contribution to side bar directly, till we can foundamentally support UI plugin. Note that the gSearchClient.js is a global search client that serves all the searches now: file name search, content search. There are two choices for javascript plugin to consume it: 1. Javascript plugin provides the "open ref" command and consumes the gSearchClient directly and filter on the file list and attach details on each file. 2. Editor provides "open ref" command, similar to "CTRL+H" command. When search pane is up, it asks a service like "search.filterDetails" from javascript plugin and get the result back. Either way will work but I prefer to option 2.
We decided to go with option 1, which is more extensible. Put the second commit with http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=2f190f6abbc1ef036e97c08408b5ea670a220847. So now with darklaunch, you can select a keyword and use open ref command. The grep search runs inside the javascript plugin and pass the result back to the editor command. Two major things left: 1. We need to make a contract on how tern has attach the detail info into the grep search result. 2. The search pane UI is very rough now. Need to hide some controls for find ref command. 3. We also need to thin about "If user wants to stay in the search pane and find another ref without going to editor". How will we handle that?
(In reply to libing wang from comment #4) > 3. We also need to thin about "If user wants to stay in the search pane and > find another ref without going to editor". How will we handle that? I don't think we should allow this. The reason being is that I need a specific context from the editor to compute the original type graph from - if they start searching for random things in the pane how do I know what type they are wanting refs to?
(In reply to Michael Rennie from comment #5) > (In reply to libing wang from comment #4) > > > 3. We also need to thin about "If user wants to stay in the search pane and > > find another ref without going to editor". How will we handle that? > > I don't think we should allow this. The reason being is that I need a > specific context from the editor to compute the original type graph from - > if they start searching for random things in the pane how do I know what > type they are wanting refs to? OK, after the search pane is up we should hide everything from the top section, except the replace button.
Third commit with http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=7c6883c8c193a8169be3929caa429964e7c8e589. The integration code in refsCommands.js is finalized now: 1. When you call gSearchClient.search API, the second parameter is passed as true now. Means you want to generate matches on each file hit. 2. The _weighMatches function in refsCommands.js describes all the details on the match object. I just faked "confidence" property there to show something in UI. Mike, I think you can go ahead to add yoru tern thing inside _weighMatches function.
Fourth commit: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=6f9e72b89f401f1b34afbc04923f22f5a145ccf6. support multiple matches in one line, sort and highlight confidence in the search pane
5th commit: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=9e280c5a2b1785fd7d61733b2647a28c5044a28c Enabled refactor/replace UI.
6th commit: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=33a11369365fb2cf158dc44907854bb3a9db94ea 1. Removed the redundant toggle links. 2. Rename the command name "Replace..." to "Preview Replacement".
To dark launch the find reference, 1. Do localStroage.setItem("darklaunch", "true"); 2. Select something in the editor, rightl click and select tools->references->project
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/msg04002.html
