Bugzilla – Full Text Bug Listing
| Summary: | Content assist API should not include selection | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Mark Macdonald <mamacdon> |
| Component: | Client | Assignee: | Mark Macdonald <mamacdon> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | andrew.eisenberg, daniel_megert, john.arthorne, marcel.bruch, proksch, sebastian, simon_kaegi |
| Version: | 0.4 | ||
| Target Milestone: | 6.0 M1 | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
What happens if a user selects a block of code and then invokes content assist? In my opinion, the interesting pieces of information are these: invocationOffset: the caret position of where content assist is happening replaceStart: the start of the editor selection replaceEnd: the end of the editor selection prefix: the prefix of the content assist invocation replaceStart and replaceEnd correspond to the editor selection and designate what will be replaced. invocationOffset will be where the caret is and will be either replaceStart or replaceEnd depending on where the caret is at the start or the end of the selection. It may be the case that replaceStart and replaceEnd are not really needed by clients, but I can imagine that some clients may need to do something with this information. I was just making a similar comment. The only value I can think of is that the entire selection should be replaced by the inserted proposal. Since the insertion is done on the editor side after the proposals are computed, this isn't really a concern for the client writing the proposals. It's true that IContentAssistProcessor only provides the offset, but on the other hand it also provides ITextViewer from which the client can obtain the selection, and many other things. CCing Marcel Bruch and Daniel Megert for some expert opinions on what kind of context information a content assist processor might need. (In reply to comment #2) > CCing Marcel Bruch and Daniel Megert for some expert opinions on what kind of > context information a content assist processor might need. In the case you are asking for potential future extensions to Orion: There is a PhD student (Sebastian, CCed) who is supposed to port some concepts of Code Recommenders for Java to JavaScript and to develop new code completion concepts for dynamic languages like probabilistic type systems for JavaScript etc. Please note that it's by far too early for timetables or any estimation when this will happen. But when CCed... If this is something you'd like to support in future versions, it would be great to provide a completion context similar to JDT that gives fast access to the latest AST, all accessible variables, methods etc. You may also reconsider your proposal scoring and filtering. For instance, there are approaches for Java in the pipe that make use of quite different techniques. See http://vimeo.com/11664433 for an example. To enable such systems, the completion system needs to be very flexible in terms of dynamic re-ranking as well as dynamic addition of proposals. Implementing such tools on top of JDT is quite challenging but if considered in the beginning... Thanks Marcel. Any and all comments welcome. To give some context, currently Orion just exposes a simple "proposal" extension point where a contributor is given information about the current editor state, and is expected to return a set of proposals. The question here is what context information those "proposal engines" need to generate their lists of proposals, and particularly whether they need to know the current editor selection. I guess my concrete question is whether you know of any completion proposals that would use the current editor selection to decide what kinds of proposals to return. It sounds like you are talking about some kind of filtering or post-processing on the raw proposals that come back. We currently simplistically sort the proposals and have no filtering mechanism, but that is definitely something we can explore adding if there is interest. Because Orion is still incubating it's a good time to get involved - there is currently very little constraint such as maintaining compatibility or API shape so we can really change all aspects of the system to suit requirements. And thanks for sharing the demo video - cool stuff! There are some assumptions in the Orion engine right now that would make some of those completions difficult, but I think they are quite easy to change at this point. For example we currently assume that the returned proposals will start with the prefix currently in the editor, so we couldn't replace for example "opn" with "showOpenDialog" but that is a simple fix. (In reply to comment #4) > The question here is what context information those "proposal > engines" need to generate their lists of proposals, and particularly whether > they need to know the current editor selection. I guess my concrete question is > whether you know of any completion proposals that would use the current editor > selection to decide what kinds of proposals to return. As far as I know, none of JDT's nor any of our existing or planned completion engines leverages the current editor's selection to compute proposals. It's simply a matter of usability. No one wants to select some text in the editor before triggering code completion. There are some tricky aspects of proposal *insertion* that may make use of the selection. But Dani's knows that better than I do. FWIW, we have a code search engine that leverages the current editor's selection to find best matching code examples. But that's a bit far away from a usual use case. > It sounds like you are talking about some kind of filtering or post-processing > on the raw proposals that come back. In most case, yes. > Because Orion is still incubating it's a good time to get involved. We'll get back to Orion when plans get little bit more concrete. (In reply to comment #3) > http://vimeo.com/11664433 for an example. Nice stuff. I'll have to try that out for Java development. JS in Orion will be a bit more challenging for two reasons: 1. JavaScript is dynamic and therefore less is known about the current code snippet being completed on. We might be able to solve this with some reasonable static analysis, but it's hard to know how far we can go while still remaining responsive. 2. It's unclear to me how Orion will churn away at making intelligent content assist choices since much of the program model resides on the server. And, if we want content assist to be responsive, I can't see how we can make xhr requests as part of a content assist invocation. The solution may be to keep a cached version of the program model locally that content assist uses, but that opens up a whole new world of problems. I've already talked a bit about type inferencing in Bug 368489. I also have a few specific improvements to the API suggested in Bug 372364. My personal opinion is that we should give priority to responsiveness over fanciness, even if that means we can't do all that we want. One of the draws to Orion is that it is supposed to be light-weight. And it won't feel light-weight if content assist is sluggish. That being said, we should still try for really, really smart content assist, and there is a lot of low hanging fruit, but we just need to be careful not to make things sluggish. (In reply to comment #6) > JS in Orion will be a bit more challenging for two reasons: Granted ;) > 1. JavaScript is dynamic and therefore less is known about the current code > snippet being completed on. We might be able to solve this with some > reasonable static analysis, but it's hard to know how far we can go while still > remaining responsive. [...] > 2. It's unclear to me how Orion will churn away at making intelligent content > assist choices since much of the program model resides on the server. And, if I've read Bug 368489 and this comes close to what I had in mind (runtime tracking + static analysis). I'm far away from being a JS developer, and thus will shy away when it comes to the details. But Seb is, and you are... Let me express my idea a little blue-eyed: On server-side, some more or less complex static analyses can be run to determine a set of potential runtime types of a variable and it's members. Same data could be achieved by tracking the runtime information (both approaches have their flaws; I don't mind yet). I assume that in many cases the set of potential types for method parameters, or method return values, or fields is stable (e.g., when working with a library, then it probably returns almost always the same type with identical members). Given that this information is stored on server side (which type a variable _typically_ has) in a fast index, a simple and fast completion engine could be created that, given a list of potential types for a variable name, narrows down the proposals to a set of likely ones. More features can be added on top of this index but that goes to far at the moment. Is anything obvious wrong with this sketch? I just noticed that we are getting a bit off-topic now... sorry. As Marcel already mentioned, I'm a PhD student working on possible recommender systems for dynamic languages like Javascript. I'm at the very beginning of my research, but I think the Orion Javascript editor is a perfect use case for such a recommendation system. Therefore I'm very interested in working on the Orion code completion. I'm not in the depth of the Orion codebase yet, but I will change this in the near future. Until then I can not estimate if an approach as proposed by Marcel could work. I already read Bug 368489 and had a look at the current completion engine that was referenced there. Is it possible that you provide me some hints to the documentation or to locations in the source code where I should start to read? I'm a bit short of time this week, but I will definitely come back to this next week. (In reply to comment #8) > I'm not in the depth of the Orion codebase yet, but I will change this in the > near future. Until then I can not estimate if an approach as proposed by Marcel > could work. I already read Bug 368489 and had a look at the current completion > engine that was referenced there. Is it possible that you provide me some hints > to the documentation or to locations in the source code where I should start to > read? A good starting point to get an overview: http://planetorion.org/news/2012/01/writing-a-content-assist-plugin-for-orion/ The implementation of the content assist engine is in a file called contentAssist.js: https://github.com/eclipse/orion.client/blob/master/bundles/org.eclipse.orion.client.editor/web/orion/editor/contentAssist.js You are welcome to ask more detailed questions on orion-dev mailing list, or #eclipse-orion on IRC. Sebastian, The content assist work for Orion that I've been doing is located on a github fork, here: https://github.com/kdvolder/orion.client More specifically, the esprima content assist work is located on the esprimaAssist branch, here: https://github.com/kdvolder/orion.client/tree/esprimaassist/bundles/org.eclipse.orion.client.core/web/plugins/esprimaPlugin Have a look at what I did so far. There's plenty of room for improvement, so comments are appreciated. Also, on a slightly unrelated note to this bug report, but it is related to your phd research, you may be interested in some of the work that we have been doing for content assist on Groovy-Eclipse. Here was our first attempt at type inferencing in Groovy-Eclipse: http://contraptionsforprogramming.blogspot.com/2009/11/how-type-inferencing-for-groovy-in.html But that wasn't sufficient because it required DSL creators to be proficient in writing Eclipse plugins. So, later, we implemented this: http://blog.springsource.org/2011/05/08/better-dsl-support-in-groovy-eclipse/ Let me know if you have any questions. > As far as I know, none of JDT's nor any of our existing or planned completion > engines leverages the current editor's selection to compute proposals. s > simply a matter of usability. No one wants to select some text in the editor > before triggering code completion. There are some tricky aspects of proposal > *insertion* that may make use of the selection. But Dani's knows that better > than I do. You did quite well ;-). The content assistant should be able to report proposals for a given offset in the document (or viewer) no matter where the caret or the selection is. The proposal will contain the information mentioned in comment 1. The caller of the content assist API can then decide what it does with a possible selection (replace, ignore, ...). Mark, please re-target as appropriate. 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/msg03444.html |
The Content Assist API [1] currently includes a 'selection' parameter that providers can use to determine where in the buffer the editing caret is, and also what text is selected. The selection has this shape: selection {Number} start {Number} end {Number} offset When Content Assist is first activated (and no text is selected in the editor), you'll have start == end == offset. However, if the user continues typing to narrow down the list of proposals, 'start' and 'end' keep their initial values, and only 'offset' is updated. So really 'offset' always has the correct value for the caret position, while 'start' and 'end' are just misleading. Moreover, I can't think of a use case where the selected text should matter to a content assist provider. Thus rather than fixing 'start' and 'end', the whole 'selection' object should be removed and replaced with just an 'offset' parameter. This would more closely resemble the IContentAssistProcessor interface from Eclipse desktop. [1] http://wiki.eclipse.org/Orion/Documentation/Developer_Guide/Plugging_into_the_editor#Service_methods_2