Code editors in Mozilla apps
By Kazé on Thursday, February 19 2009, 11:20 - Permalink
The main problem when designing a Mozilla-based development tool is the lack of a decent code editor. Here’s a quick overview of the existing solutions.
<editor>
SeaMonkey Composer uses a plaintext editor to edit HTML source (editortype="text").
Plain and simple, reliable, gets the job done… as long as you don’t want any syntax highlighting, line numbers, code folding, auto-completion, etc.: it’s a Notepad, no more, no less.
Nvu used an html editor to edit HTML source (editortype="html"):
- a colored source view of the current page is generated, modified to add line numbers and sent to the html editor
- after this html view of the html source has been edited in wysiwyg, it’s exported to text and the HTML document is rebuilt from that text.
I think this isn’t an acceptable solution:
- all these successive conversions are too tricky: this “Source tab” was very buggy in Nvu’s and has caused most of the crashes and data losses
- this pseudo syntax highlighting can’t be updated as you modify the code, so what’s the point?
- the html editor is a poor text editor: it’s slow, the caret gets stuck sometimes, requiring to use the mouse.
I guess it’s better than nothing but as far as I’m concerned, I prefer a Notepad.
<browser>
Firebug uses a browser to display and edit the HTML source. This brings a decent syntax highlighting and a good code folding, and it’s very handy for small modifications.
However, it’s nowhere near a text editor either: it’s slow, it’s impossible to use without a mouse, and it’s very specific to HTML and CSS. It makes a lot of sense in Firebug and might be interesting in a web editor like KompoZer, but it doesn’t claim to be a code editor.
SciMoz
Komodo relies on SciMoz, i.e. a Scintilla binding. I think it’s the best possible editor component for Mozilla apps: it’s very fast and lightweight, it has the best lexer I know (better than Vim’s imho) and a good code completion. Its code folding feature works well with all languages… except with HTML, unfortunately.
The main drawback is that SciMoz is very difficult to embed into a non-Komodo app. I believe ActiveState would like to share the effort on SciMoz with Mozilla, and an <editor editortype="scintilla"> element would sure rock… but unfortunately this doesn’t seem to be a priority for Mozilla. I sure wish it was!
Speaking of KompoZer, the solution would be to build KompoZer on OpenKomodo: KompoZer would become quite heavy-weight but it would remain acceptable compared to Expression Web or DreamWeaver.
<canvas>
The good news might come from Bespin:
We’ve also been asked whether we’d like to make it easy for folks to embed Bespin’s canvas editor in their own non-Bespin projects. Absolutely we do. Bespin will eventually spin out three projects:
1. The Bespin project: an on-line code editor (i.e., the project we’ve currently announced)
2. Thunderhead: a canvas/JS GUI toolkit
3. (To Be Named Editor): a stand-alone canvas editor that you can embed
I still doubt Bespin can come close to Scintilla in terms of performances and features; but having an embeddable, standalone editor that could easily be used in any Mozilla project would be a great improvement, despite all other limitations.
So far I intended to use SciMoz in KompoZer 0.9, but Bespin might bring a very interesting alternative — especially if KompoZer merges with SeaMonkey Composer. I’ll keep a close eye on this standalone canvas editor project!
Comments
I looked through the same options (twice even) when evaluating a code editor for Ubiquity (this was before Bespin was project). Sadly, none of them seemed particularly viable. I came to the same conclusion: Komodo's Scintilla-based editor was the best, but would be a pain to port over.
Eventually we ended up choosing CodeMirror. That is, until we got fed up with the huge performance issues and other bugs, and eventually defaulted back to a plain-text editor.
But there is definitely interest in having a proper editor available in XUL, from various different projects. While there is now a focus on Bespin, and its great, having a web-based editor isn't necessarily suitable for all projects.
Franky, I don’t want any syntax highlighting, line numbers, code folding, auto-completion, etc. The simple editor in the original Mozilla Composer worked just fine. I would love to see it incorporated into Kompozer.
Blair > yes, it’s a pity that SciMoz is so hard to embed. It’ll really be nice if Mozillians could work together on this: I’m pretty sure ActiveState would appreciate to share the effort on this binding.
I’m glad to know I’m not the only one who went back to the plaintext editor. :-/
Neil > KompoZer 0.8a1 already uses a plaintext editor to edit the HTML source — i.e. the same component as in Mozilla Composer: simple but reliable. Much more reliable than Nvu’s code editor. I haven’t decided yet wether KompoZer 0.8 will include Nvu’s source editor too (I hate it but some users want it back), but if I do, it won’t replace the current plaintext editor: it’ll just be another way to edit the HTML source — probably in a dialog box.
However, I still think a modern code editor (syntax highliting, etc.) would be necessary for this project. KompoZer 0.8 will rely on a plaintext editor like Mozilla Composer as I have no short-term solution to embed a decend code editor, but it’s one of the main things I have in mind for the 0.9 branch.
I think you'll find this news interesting :
http://www.openkomodo.com/blogs/jef...
Bobo, Omnisilver, Sandro & others > thank you for the links about the recent works on the SciMoz component. I’ve been following this thread for a long time, it’s good to see there’s some progress on SciMoz — but unfortunately we’re still very far from an embeddable code editor component: no syntax highlighting, no text insertion. It’s already a nice proof of concept, I hope to see some more progress in this project soon.