Changes

Jump to: navigation, search

DevTools/Features/CodeEditor

3,651 bytes added, 18:43, 12 May 2011
no edit summary
== Team ==
* '''Feature Manager''': ''Kevin Dangoor''(irc: kdangoor)* '''Devtools Developer''': ''Mihai Sucan'' (irc: msucan)* '''Built-in Editor Owner''': ''Ehsan Akhgari'' (irc: ehsan)
== Release Requirements ==
| style="font-weight: bold; background: #DDD;" | [http://ace.ajax.org Ace]
| style="font-weight: bold; background: #DDD;" | [http://eclipse.org/orion Orion]
| style="font-weight: bold; background: #DDD;" | [http://codemirror.net/ CodeMirror]
|-
| License
| Tri
| BSD
| Zlib
|-
| Syntax Highlighting (HTML, JS, CSS)
| Yes
| TBD
| Yes
|-
| Gutter with line numbers
| No
| Yes
| Yes
| Yes
| Can set/display breakpoints
| No
| Yes
| Yes
| Yes
| No
| Yes
| TBD
|-
| RTL support
| Yes
| No
| TBD
| TBD
|-
| Yes
| No
| TBD
| TBD
|-
| Yes
| Yes
| TBD
|-
|}
| style="font-weight: bold; background: #DDD;" | [http://ace.ajax.org Ace]
| style="font-weight: bold; background: #DDD;" | [http://eclipse.org/orion Orion]
| style="font-weight: bold; background: #DDD;" | [http://codemirror.net/ CodeMirror]
|-
| Code-oriented indentation(1)
| No
| Yes
| Yes
| Yes
| Bracket/brace matching
| No
| Yes
| Yes
| Yes
| Highlight current line
| No
| Yes
| Yes
| Yes
| Yes
| No
| TBD
|-
| Code folding
| No
| Yes(2)
| No
| No
|-
| No
| TBD
| Yes
|-
| JavaScript syntax checking
| Yes
| No
| TBD
|-
| Reconfigurable keybindings (vi/emacs possible)
| No
| Yes
| No
| No
|-
# code oriented indentation means maintaining the indentation level from the previous line and ideally indenting automatically when a new block is started
# "Unstructured" or "user" folding was just contributed during the week of April 25th
 
Note: CodeMirror 2 was also considered in the initial round. However, it appeared to have the same i18n and a10y downsides as Ace while lacking other desirable features.
 
== Evaluating the Options ==
 
You can read the background section for further information leading up to our current evaluation status.
 
The short form of where we stand now:
 
* The built-in editor (contentEditable) must be a part of the solution, because it appears to be the only viable way to handle i18n and a10y needs sufficiently well
* A lot of work (not quantified, but you can get an idea looking at the list above) would be required to make the built-in editor a good code editor
* Ace has a good collection of features, but does not use contentEditable and therefore falls short in a10y and i18n
* Orion has a good start on features (though fewer than Ace), but is closer to our requirements for a10y and i18n
 
From a time-to-market perspective, Orion looks like the best choice. The only work we'd need to do to get started using it is:
 
# work through differences between running in content and chrome
# ensure that our integrated editor is sufficiently accessible
 
Over time, Orion would doubtless gain other features from our wishlist. It is an active Eclipse project. However, the Orion project is trying to do quite a bit and their editor component is only a slice of that. Features like code folding, word wrap and Ace's flexible key bindings are non-trivial.
 
The other option would be to incorporate Orion's editing/rendering model into Ace. That requires some amount of up-front work, but gives us a lot of features right away.
 
Therefore, the first step is to evaluate just how much work is likely required to merge the Orion input/rendering with the rest of Ace.
== Next Steps & Open Issues ==
* Finish populating Solicit additional feedback for the tables plan on dev.platform (though this really belongs on dev-apps-firefox)* Proceed with the evaluation == Background == In the dev.platform newsgroup, there were two threads with significant discussion about code editing approaches (1, 2). There was a followup meeting on May 9th in which we (devtools, a10y, Ehsan) discussed the options a bit further and the questions surrounding those options. We came out of that meeting with some observations: # contentEditable is the only sane way to do text input, due to both a10y and i18n considerations# we may not need to use the editor for file viewing at stage 1# IBM claims that Orion is not fully accessible. dbolter has asked where it falls short.# Orion does some accessibility events okay: caret changes and text changes. Does not appear to work with screenreaders yet.# RTL works fine in Orion# While it may seem like syntax highlighting is a purely visual thing, the metadata for highlighting may be valuable for providing functions like jump-between-methods.# CodeMirror appears to have the same problems that Ace does, though without some of the previous sectionfeatures we want* Decide # code-oriented indentation is not a requirement for version 1, but tab key support is# We should consider the path forward communities around Ace and Orion and how likely it is we can get what we need while working with those communities (FWIW, a10y is important in general to IBM and the Eclipse project)# Single long lines is a performance case we should consider, since minified files make this case more likely on the web in general than in normal day-to-day editing# Web Inspector appears to use a simple editor that is built into the webkit tree We also had a couple of questions: # What are the requirements for accessibility? (dbolter to followup)# What are the performance characteristics of the best combination various choices for our use cases?  1: [http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/256c4bf1c45eebfc# Use of tradeoffs3rd party projects]2: [http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/e154ba5413e95018# In-browser code editor]  
== Using the User's Editor ==
Canmove, confirm, emeritus
1,093
edits

Navigation menu