Community
Participate
Working Groups
We need an extension point to allow contributing syntax highlighting support for new languages/filetypes (eg. PHP, diff). This is part of the M7 plan: http://wiki.eclipse.org/Orion/Milestone_Plan#M7_-_April_29.2C_2011
I am interested in the way how this extension point will work. Currently in compare editor , I am adding a style listener after the styler.js(ediotr/sample/styler.js , which is used by editorContainer) is constructed. The current implementation of the listener will override some style that was made previously so I think the way it works now is awkward. Not sure if the extension point stuff will help on this but I am hoping so.
There is bunch of syntax highlighters in js out there: SHJS - Syntax Highlighting in JavaScript (http://shjs.sourceforge.net/) SyntaxHighlighter (http://alexgorbatchev.com/SyntaxHighlighter/) google-code-prettify (http://code.google.com/p/google-code-prettify/) jquery What feature do you have in mind: themeable language auto-detection bracket matching nested language (like js embed in html) ? Also worth checking out: http://pcwalton.blogspot.com/2010/11/syntax-highlighting-specification.html and: http://manual.macromates.com/en/themes I hoped we could use some language grammar collection, theme files, and backend from another project and just implement the fontend for the orion editor. I think Andrew did that in the past using the highlighters from dojo (so did the guys from davinci), but the problem was that he had to parse the entire file every text changed event what made it very slow.
(In reply to comment #1) > I am interested in the way how this extension point will work. > Currently in compare editor , I am adding a style listener after the > styler.js(ediotr/sample/styler.js , which is used by editorContainer) is > constructed. > The current implementation of the listener will override some style that was > made previously so I think the way it works now is awkward. > Not sure if the extension point stuff will help on this but I am hoping so. You talking of Bug 341141, where you need to merge styles from two different line style listener into one view. Maybe we could use Bug 341141 for that ? What we could do is close Bug 334212 in favor of this one (and make sure the new highligther is themeable).
(In reply to comment #3) > (In reply to comment #1) > > I am interested in the way how this extension point will work. > > Currently in compare editor , I am adding a style listener after the > > styler.js(ediotr/sample/styler.js , which is used by editorContainer) is > > constructed. > > The current implementation of the listener will override some style that was > > made previously so I think the way it works now is awkward. > > Not sure if the extension point stuff will help on this but I am hoping so. > > You talking of Bug 341141, where you need to merge styles from two different > line style listener into one view. Maybe we could use Bug 341141 for that ? > > What we could do is close Bug 334212 in favor of this one (and make sure the > new highligther is themeable). Some clarifications , please correct if any 1.bug 334212 resolves syntax highlighting without touching back ground. 2.By default , the editor has some back ground highlighting (e.g. current line , selection). 3.Compare editor will extend the background highlighter.(by "themeable" , I take that as extend-able ) 4.There will be no need to merge the back ground style.If "current line" or "selected line" happens inside a diff block , the editor's style should take over.
Are there any plans for supporting different highlighting modes in one file? For example, highlighting JS code in HTML.
(In reply to comment #5) > Are there any plans for supporting different highlighting modes in one file? > For example, highlighting JS code in HTML. Yes definitely. For the moment we're focusing more on the mechanisms to allow arbitrary language support however we're not doing anything to restrict parsing style so what you describe is not a problem and in fact something we're looking for help on right now.
There is now an extension point "ISyntaxHighlight" for contributing syntax highlighting rules. The rules are expressed using a (currently quite limited) subset of the TextMate grammar format. You can define an extension that provides grammar rules for a certain file type (eg. "html") and the coding page will apply your rules when you edit a file of that type. Note that Orion's existing TextStyler is still used for .js, .java, and .css files. I added a sample implementation which provides rough syntax highlighting for HTML. See: - org.eclipse.orion.client.core/static/plugins/htmlSyntaxHighlightPlugin.html - org.eclipse.orion.client.core/static/js/styler/htmlSyntaxHighlight.js - org.eclipse.orion.client.core/static/default-theme.css
Mark, can this bug be closed? As far as I can see we now have extensible syntax highlighting. I suggest closing this one and using more specific bugs for further enhancements.
(In reply to comment #8) > Mark, can this bug be closed? As far as I can see we now have extensible syntax > highlighting. I suggest closing this one and using more specific bugs for > further enhancements. Didn't realize this one was still open. Closing...
