Bugzilla – Full Text Bug Listing
| Summary: | [client] how to manage the order when multiple stylers are styling text | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | libing wang <libingw> |
| Component: | Editor | Assignee: | Silenio Quarti <Silenio_Quarti> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | aclement, bokowski, eclipse.felipe, mamacdon, Silenio_Quarti, susan, Szymon.Brandys |
| Version: | 0.2 | ||
| Target Milestone: | 1.0 RC1 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
libing wang
The way the Editor works styles for a line are provided via listeners. When the Editor needs to style a line (when the HTML for the line is being create) it sends "LineStyle" events. Many listeners can handle the "LineStyle" event. The listeners are called in the order they were added, and the style set in the event by a listener can be overwritten by the next listener in the chain. Libing case he will have to stylers: js language syntax styler and a diff adorner styler. If he is not careful, the syntax styler can run second and discard the styles provided by the first listener. I think the editor container could offer a better design to manage several stylers. Each stylers would have a priority (syntax highlight, adorner, spell checker etc), the stylers would be called according to priority, conflict in the styles (*) can be merged using some context information (that is not available in the editor.js). * for example, first styler set line background to green and the second to yellow. Final note: the eclipse.TextStyler currently provides three types of style: syntax highlight bracket matching current line indication (In reply to comment #1) > The way the Editor works styles for a line are provided via listeners. > When the Editor needs to style a line (when the HTML for the line is being > create) it sends "LineStyle" events. Many listeners can handle the "LineStyle" > event. The listeners are called in the order they were added, and the style set > in the event by a listener can be overwritten by the next listener in the > chain. > > Libing case he will have to stylers: js language syntax styler and a diff > adorner styler. If he is not careful, the syntax styler can run second and > discard the styles provided by the first listener. A good first step would be to pull the line styler code out of editorContainer.js and put it into some external object in editorFeatures.js. At least then Libing can control the ordering of the stylers and how to merge. > I think the editor container could offer a better design to manage several > stylers. Each stylers would have a priority (syntax highlight, adorner, spell > checker etc), the stylers would be called according to priority, conflict in > the styles (*) can be merged using some context information (that is not > available in the editor.js). This sounds tempting, but I suspect there will always be some merging or context info that only the client adding the various stylers knows, unless we were to be very specific about what kinds of styling an "adorner" could do vs. a "spell checker." (In reply to comment #2) > A good first step would be to pull the line styler code out of > editorContainer.js and put it into some external object in editorFeatures.js. > At least then Libing can control the ordering of the stylers and how to merge. I had a quick workaround : I called editorContainer.onInputChange function , so this will instantiate a TestStyler and add the listener to the editor. Then I add another listerner to listen to the lineStyle event. This will work around the order of the listener and my listener always comes afterward. In my listener I only need to change the back ground borderand color so the merge is not that complicated yet. But in general , we still need a policy for style merging. (In reply to comment #3) > (In reply to comment #2) > > A good first step would be to pull the line styler code out of > > editorContainer.js and put it into some external object in editorFeatures.js. > > At least then Libing can control the ordering of the stylers and how to merge. > > I had a quick workaround : > I called editorContainer.onInputChange function , so this will instantiate a > TestStyler and add the listener to the editor. > Then I add another listerner to listen to the lineStyle event. > This will work around the order of the listener and my listener always comes > afterward. > In my listener I only need to change the back ground borderand color so the > merge is not that complicated yet. This seems to be causing bug 342501. So I think we need to pull the styling into the coding glue so that Libing does not have to rely on the container styling implementation. This will also help Mark's efforts with pluggable syntax highlighting. Assigning this to me for pulling the styling out of the glue. I think Mark's efforts will help push it further. (In reply to comment #2) > A good first step would be to pull the line styler code out of > editorContainer.js and put it into some external object in editorFeatures.js. > At least then Libing can control the ordering of the stylers and how to merge. This is now done. Libing, this means you will lose your "free" syntax highlighting but you can now hook up all stylers yourself and control the order as needed, without having to hack onInputChange events, etc. to force styling. Please see the new object "syntaxHighlighter" in coding.js It is called by the input manager whenever input changes. You could grab it and merge your compare-specific styles with this one. Changing the title of this bug to generalize it (since styling doesn't happen in editorContainer). Removing milestone. I suspect Mark will end up owning this bug once we sort out how pluggable syntax highlighters work. (In reply to comment #5) > (In reply to comment #2) > > > A good first step would be to pull the line styler code out of > > editorContainer.js and put it into some external object in editorFeatures.js. > > At least then Libing can control the ordering of the stylers and how to merge. > > This is now done. > Libing, this means you will lose your "free" syntax highlighting but you can > now hook up all stylers yourself and control the order as needed, without > having to hack onInputChange events, etc. to force styling. > fixed with 0d9b7da29619bc0a941d98189c12d625b4bf4fca for bug 343609 Now we have orion.DiffStyler which always listen to line style change after TextStyler. *** Bug 384880 has been marked as a duplicate of this bug. *** I have used the "pre,post" event listening support added for bug#384882 to solve the ordering problem between the syntax styler and the annotation styler. The annotation styler now runs in the "post" phase which is guaranteed to be after the syntax styler. This allowed me to cleanup editor.js and remove the highlightAnnotation() function which only existed as a hack to add the annotation styler after the syntax styler was created. http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=89cb288f1d20ddb9d968c1e1ad5467862ab539f5 |