Community
Participate
Working Groups
Orion 0.3 There should be a way for a service to participate in the editing process. This means we would supply an "edit listener" extension point that a service could register with. The service's method would then be called when events of interest are generated by the editor. A listener may also want to specify what events it cares about (eg. by limiting to one document type, event type, etc). Example use case: implementing a highlight provider inside a plugin that uses a CodeMirror mode to calculate styling information. The provider needs to receive ModelChanging events from the editor, then drive the CodeMirror mode over the changes to recalculate style info. Until now we've avoided this issue by passing the entire editor contents around to various extension points (validators, outliners, etc) when we need something from them, but I don't think that approach will cut it for much longer.
See Bug 359414#c1
I implemented a simple version of this: you can register with the "orion.edit.model" service to get notified of editor events (ModelChanged, ModelChanging, Selection, etc.). Note that it's read-only, not read/write as requested in 359414#c1. There is another use case I want to support, driven by Bug 365128 #c9. I want "Scroll" event notifications, but I need the vertical scroll position in terms of line indices, not the pixel coordinates that the TextView currently provides. I can't directly ask the TextView to give me a line index since I'm in a plugin. So I'll try annotating the events sent to orion.edit.model listeners with lineIndex information, or exposing a separate service for mapping pixels to line indices. My concern in the latter case is that I'll be doing 2 async calls for something that's supposed to be fast, but I'll see how it works.
(In reply to comment #2) > There is another use case I want to support, driven by Bug 365128 #c9. I want > "Scroll" event notifications, but I need the vertical scroll position in terms > of line indices, not the pixel coordinates that the TextView currently > provides. Andrew had a similar problem with the Selection event, see [1]. The API should provide whatever context is necessary (pixels -> line indices or character values, etc) to give meaningful information to interested plugins. What exists now is a simple forwarding of TextView-level events to the service. [1] http://dev.eclipse.org/mhonarc/lists/orion-dev/msg01484.html
As I describe in the mailing list message above, I would like to implement a mark occurrences plugin. One part of the requirement is to have access to the full text on each selection event. I will also need a way to add markup to a bit of text in the editor. I'm guessing that there will need to be a new piece of API created for this.
(In reply to comment #0) > Example use case: implementing a highlight provider inside a plugin that uses a > CodeMirror mode to calculate styling information. The provider needs to receive > ModelChanging events from the editor, then drive the CodeMirror mode over the > changes to recalculate style info. I might be a little off the road here but I have a another use case here, not related to syntax highlighting though. We will character level diff in the compare widget for 0.5. So basically the current diff block is highlighted, all the char level diffs are highlighted as well, something similar to Eclipse desktop. Lets say the char level highlighting is implemented in a plugin using jsDiff and I don't want the existing char level diff to be twisted when user edits on the left side, so I need to recalculate the style info. Mark , will this pattern be the same as you described above?
I had a brief chat with Mark and I'm starting to come up with something a bit more concrete. First, it looks like we can use editor annotations for everything I am looking to do. There just needs to be a way for plugins to add and remove annotations from the editor. For this, I'm guessing there would need to be some kind of annotation service that plugins can retrieve from the service registry. For what I see here, it would need to have 2 service methods: 1. registerAnnotationType, which adds a given AnnotationType to the AnnotationTypeList of the text model. 2. addAnnotations, which adds a list of annotations of a given type. To keep things simple for the api, this method could first remove all other annotations of that type before adding the new ones. This means taht each plugin must have a unique annotation type. I see that annotations.js assumes that each individual annotation keeps track of its own styling information. For the purposes that I see, it would be easier/nicer if registerAnnotationType would do this instead. In the future, we will need a level of indirection between the annotation type and its style so that theming could work. But, I think that is a task for later.
I have a working implementation of mark occurrences that uses an orioin.edit.annotation service. I'll clean it up a bit and then share it with you for some feedback.
(In reply to comment #7) > I have a working implementation of mark occurrences that uses an > orioin.edit.annotation service. I'll clean it up a bit and then share it with > you for some feedback. The find&replace in the editor will show all the occurrence as well. Still got something to clean up and share in the searchUtils but here is the snippet in my implementation: var searchResult = mSearchUtils.searchAllOccurrence(isRegEx, searchStr, caseSensitive, this._editor.getModel().getText(), this._editor.getModel().getLineDelimiter()); var annotationModel = this._editor.getAnnotationModel(); if(annotationModel){ annotationModel.removeAnnotations("orion.annotation.search"); } if(searchResult.m.children.length === 0){ return; } var gap = searchResult.q.searchStrLength; for(var j = 0; j < searchResult.m.children.length; j++){ var detailModel = searchResult.m.children[j]; var lineStart = this._editor.getModel().getLineStart(detailModel.lineNumber - 1); for(var i = 0; i < detailModel.matches.length; i++){ if( searchResult.q.wildCard){ gap = detailModel.matches[i].length; } var startIndex = lineStart + detailModel.matches[i].startIndex; var endIndex = startIndex + gap; if (annotationModel) { annotationModel.addAnnotation({ type: "orion.annotation.search", start: startIndex, end: endIndex, title: "Search", style: {styleClass: "annotation searchMatch"}, html: "<div class='annotationHTML searchMatch'></div>", overviewStyle: {styleClass: "annotationOverview searchMatch"}, rangeStyle: {styleClass: "annotationRange searchMatch"} }); } } }
Another thing worth mentioning and we want to make sure if it will work this way: When you select something and use CTRL+F, find&replace feature will use the selection as the default keyword and deselect it in the editor. This will cause the plugin remove the annotations and find&replace starts to highlight them. Once user types new keyword and finishes find&replace, the new keyword is selected back in the editor, if it is hit. Now this will cause the plugin to highlight the new keyword.
Here is a commit that contains the changes for mark occurrences. The commit is still a little messy and needs some changes, but hopefully this is enough to get us going with figuring out mark occurrences and being able to add the extension point to support it. https://github.com/kdvolder/orion.client/commit/7ec046b610b8cc6b4a5f20bd7f8f036888c3b1fc In the bug363387 branch. I added a file called annotationService.js. This file listens for the events "registerAnnotationType" and "addAnnotations" on the "orion.edit.annotations" service. When the first even gets triggered, the new annotation type is added to the editor, the overview ruler, and the annotation ruler. This file will need to be part of Orion itself. (Perhaps this file is not named correctly since it does not implement the annotation service, but rather consumes it, so I am open to suggestions). I also made a few changes to editor.js and setup.js so that the AnnotationService can be properly instantiated and so that the correct parts of the editor are exposed (eg- ability to add new annotation types). I also created the mark occurrences plugin, which has markOccurencesPlugin.html and markOccurrences.js. These files implement the "orion.edit.annotations" service as well as orion.edit.model service. On selection changes, the new marks are recalculated and sent back to the editor through an event raised on "orion.edit.annotations". Libing and Mark, can one of you have a look at this patch to see what you think? Thanks.
ps- currently, mark occurrences are being highlighted with a box and using the same style as the line style (perhaps this could change).
One more thing. Libing, your implementation for find and replace looks good to me. It's unfortunate that plugins have to go through an entirely different mechanism to get the same effect.
Here is the commit to mark the occurrences in the editor. https://github.com/lshanmug/orion.client/commit/774b6bb8847a33dcf1bee4b7919fa6f0cc35224f It defines the annotations for read and write occurrence and marks them in the editor. Also modified the minimalEditor example to test this.
(In reply to comment #13) > Here is the commit to mark the occurrences in the editor. > https://github.com/lshanmug/orion.client/commit/ > 774b6bb8847a33dcf1bee4b7919fa6f0cc35224f > > It defines the annotations for read and write occurrence and marks them in > the editor. > Also modified the minimalEditor example to test this. Thanks Lakshmi, pushed to git.eclipse.org http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=2b99dad62095274cd4e62e9fb45d4fa4888e68f7
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
