From d7c5ad7d6263fd1baf9bfdbaa4c50b70ef2fbdb2 Mon Sep 17 00:00:00 2001 From: Alexander Sulfrian Date: Tue, 8 Jun 2010 08:22:05 +0200 Subject: reverted folder structure change for better mergeing with upstream --- trunk/infrastructure/ace/blog.txt | 390 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 390 insertions(+) create mode 100644 trunk/infrastructure/ace/blog.txt (limited to 'trunk/infrastructure/ace/blog.txt') diff --git a/trunk/infrastructure/ace/blog.txt b/trunk/infrastructure/ace/blog.txt new file mode 100644 index 0000000..0b095a2 --- /dev/null +++ b/trunk/infrastructure/ace/blog.txt @@ -0,0 +1,390 @@ +ACE.js: In-Browser Code Editing Finally Solved + +You may have seen them around -- "in-browser code editors" are text +editors that run on the web in your browser, supporting editing, +syntax highlighting, indentation, and other features familiar from a +desktop editor/IDE like Emacs, Eclipse, or TextMate. Compared to +desktop editors, the in-browser knock-offs I've seen leave me quite +dissatisfied. I can deal with the lack of power-user features, but +just in terms of basic usability, these web-based editors are +sputtering at the starting line. On the whole, they feel unresponsive +on small files, they slow to a crawl on large files, and they tend to +have unaddressed quirks, artifacts, and differences from native +appearance and behavior. Anyway, that's enough negativity; I have a +lot of respect for the authors and their hard work, and in writing ACE +I'm standing on their shoulders. But I was curious to see if I could +take AppJet's editor to the next level and approach the speed and +robustness of a desktop editor. After a few months of work, I'm proud +to declare success. + +Here's a walk-through of ACE.js, our new in-browser code editor. +ACE.js is a self-contained, cross-browser JavaScript file that allows +a web page to embed scrolling panes of editable code. Typing text is +snappy and there are no visual artifacts or clutter. +Syntax-highlighting happens live, as you type. Amazingly, operations +scale up well with document size. You can paste in 1,000 lines of +text, or more, and after a second or two of thought, the editor is +fully responsive again. While you keep typing, it unobtrusively +finishes syntax-highlighting the whole buffer in a matter of seconds. +Local edits to the text are just as fast on long documents as on short +ones. Changes that require large-scale re-highlighting, like opening +or closing a multi-line comment, affect the text in view almost +instantaneously, and then ACE.js quitely goes to work on the rest of +the document over the next few seconds without holding you up. ACE.js +supports advanced features like Emacs-style unlimited undo, flashing +matching parentheses as you type them or move across them, and basic +auto-indentation. Full functionality is supported across Internet +Explorer 6+, Firefox 2+, Safari 3+, and Camino 1.5+. + +I've emphasized "scalability" a lot so far, by which I mean efficiency +and responsiveness in the face of large documents, because that's the +aspect of ACE that so clearly sets it apart. But that's only one of +three "axes" that the ultimate editor needs to excel on. + +The second is what I'll call "nativity", meaning how close the editor +comes to the gold standard of the desktop editor experience. This +includes responsiveness (some in-browser editors have sluggish typing +even on small documents), but also things like undo, copy/paste, +selection, arrow-keys, shift-arrow-keys, different input methods and +devices, and so on. + +The third axis is "flexibility". How easy is it to add features? To +support more languages for the incremental highlighting, different +undo models, different indentation schemes, macros that expand as you +type, auto-complete, go-to-line by number, and whatever else you can +imagine. + +Why am I lecturing you on these theoretical principles? Well, there's +an interesting insight that explains a lot about the existing crop of +editors, and it isn't one you'd hit upon without spending a lot of +time in the trenches (yes, specifically the trenches of writing an +in-browser code editor). Based on the hodge-podge of facilities that +browsers happen to make available, you basically end up with the +following slogan: "scalability, nativity, flexibility, pick any two". +Based on this, we can classify editors into three types, which I'll +describe briefly from the point of view of someone writing an editor +(like me); if you're not familiar with browser scripting, hopefully +this won't be too hard to get through. + +Type I editors sacrifice scalability. The typical implementation is a +text-area to handle the typing, covered by a block of colored text to +handle the display. You (the person making the editor) get a boost in +nativity at the start, because you inherit the browser's text +handling, all the stuff I mentioned above, like undo and copy/paste. +The degree of flexibility is also good, because you can style the +colored text independently of the editing in the textarea, and you can +manipulate the textarea easily, such as by assigning a new content +string. Unfortunately, this scales quite badly with document size. +The good Type I editors are slick and responsive, but pretty limited +in how large files can get. + +Type II editors sacrifice nativity. This is the kind of editor where +you manually manipulate document (DOM) nodes as the user types. You +have to re-implement the desktop's native editing behavior from +scratch, first putting in support for typing and selecting text (both +by mouse and keyboard), and hopefully eventually supporting undo and +copy/paste with other programs (through some elaborate hack). This +type is attractive because it offers unlimited flexibility, and +theoretical scalability. In practice, you end up with mostly +flexibility, because getting the nativity right is such a huge task, +and scalability takes a back seat to general responsiveness. Type II +editors are fancy but feel slow and quirky. + +Type III editors, as you've probably guessed by now, are the category +ACE falls into, and are the ones that sacrifice flexibility, the third +axis, though in fact they make you work for all three axes. The crazy +idea here, which seems to have originated with Dutch programmer Marijn +Haverbeke, is to take advantage of a browser feature called "design +mode" (or "content editable"), a mode which allows the user to +directly edit an HTML document. This feature has quietly been added +to all major browsers over time. In fact, it's what GMail uses to let +users compose rich-text e-mail. The advantages of basing an editor on +a design-mode buffer are that such a buffer has a full DOM (document +model), which allows arbitrary styling and swapping of parts of the +document, and that native editing operations (selection, copy/paste) +are mapped by the browser onto operations on the DOM. + +What's the downside of a Type III editor? It's a nightmare to +implement! GMail skirts the issue by only using hard-coded browser +commands like "make the selection bold" or "insert unordered list". +What happens if you stray from this set of basic commands, and access +that alluring DOM directly, without careful preparation? Disaster! +Building a robust, extensible editor on top of design mode is kind of +like landing a man safely on the moon, where you design the +spacecraft, the mission control computer, and the pressurized suit. +You're constantly trying to insulate yourself from a hostile +environment. + +More specifically, any change your editor makes to the design mode DOM +causes the browser to instantly lose track of the selection range or +insertion point if any, the undo history, and basically any other +useful editing state. (This can be worked around with a lot of +selection manipulation, though IE in particular lacks even a way to +access the current selection relative to the DOM.) A simple edit like +the user pressing the "enter" key to start a new line may cause the +browser to insert a line break tag (BR), or split a block element into +two, whatever it wishes. Pasted text is converted into HTML, through +a somewhat arbitrary process, and inserted into the document. In +fact, the DOM is constantly being modified by the browser in response +to user actions (like typing), and you have to peek at it and +efficiently make sense of it, determine what's changed, incorporate it +into your representation, make any of your own changes (e.g. indent a +line), modify the DOM to display your changes to the user, and have it +all look like nothing special happened. A more Draconian policy for +dealing with the browser, like trapping all mouse and key events, +would just leave you with a Type II editor. The key is to treat the +DOM as a hugely complicated I/O device between you and the browser, +and carefully make rules to constrain it. + +You also deal with the fact that design mode's "native" behavior is +HTML-oriented, not text-oriented, and the fact that it tends to have a +lot of quirks and bugs. You don't get scalability for free, either, +you need some clever data structures. For example, determining the +absolute line number of the blinking insertion point is an +order-of-document-size operation without the aid of efficient data +structures that can be maintained as the document changes. + +The plus side is that once you've systematically beat design mode into +submission, you can have an unmatched degree of scalability and +nativity. From there, it's just a matter of keeping your layers of +abstraction scalable, and being aware of "nativity"-style constraints +(like responsiveness and events), and you can build up to flexibility, +the crown jewel. The reward is how easy it is to add new editor +features! + +Speaking of which, here is a list of current ACE features. Some of +them are small and just required recognizing their benefit, while +others are more significant. Some features, like "Emacs-style undo" +and "highlight matching parentheses", are significant despite having +been implemented in a couple hours each, and are signs of what's to +come in the future of ACE. + +General + - Numbered lines + - Correct vert/horiz scroll-bar behavior + - Handles large documents (thousands of lines, but see "quirks") +Browser support + - Internet Explorer 6+, Firefox 2+, Safari 3+, Camino 1.5+ + - Text size scales with page when changed by user +Syntax highlighting + - Correct JavaScript syntax (including regular expression subtleties) + - Extensible for other programming languages + - Incremental rehighlighting with minimal recalculation for each edit + - Highlight live as you type + - Moves highlighting task to background if not finished right away +Editing + - Emacs-style unlimited undo + - Native copy/paste, within editor and with other programs + - Highlight matching (or mis-matched) parentheses, brackets, and braces + - Basic auto-indentation + - Multi-stroke international characters on Mac +Interface + - Import/export text string + - Toggle editor between ACE and textarea + - Resize, focus, register key event handlers + - Multiple ACE editors allowed per page + - Packaged in one JavaScript file + - Can be created inside an iframe, any domain, any nesting +Future + - Super-extensible + - More languages? + - Smarter auto-indentation? + - Indent/unindent selection? + - Auto-complete? + - Macros? + - User extensibility, a la Emacs?? +Bugs/Quirks + - Firefox 2/3: Document height and width are limited to 32767 pixels + (about 2,045 lines of text at default text size) due to Firefox bug, + not scheduled for resolution for FF3 launch + +====== + +>> TO ADD: + - link to demo + - what to {say,ask} about {interest, use, licensing, source}? + + + + + + + + + + + + + + + + + + + +ACE.js: In-Browser Code Editing Finally Solved + +You may have seen them around -- "in-browser code editors" are text +editors that run over the web in a browser, supporting editing, syntax +highlighting, indentation, and other features familiar from a desktop +editor/IDE like Emacs, Eclipse, or TextMate. Compared to desktop +editors, the in-browser knock-offs that I've seen leave me very +dissatisfied. I can deal without the power-user features, but just in +terms of basic usability, these web-based editors are sputtering at +the starting line. On the whole, they feel unresponsive on small +files, they slow to a crawl on large files, and they tend to have +unaddressed quirks, artifacts, and differences from native appearance +and behavior. Anyway, that's enough negativity; I have a lot of +respect for the authors and their hard work, and in writing ACE I'm +standing on their shoulders. But you see, I tend to approach projects +like this with super-high standards, dangerously so even. Luckily, +after months of work here at AppJet, there's a happy ending. + +[[="I tend to approach projects with super-high standards" is a bit awkward - sounds like tooting your own horn too much for my taste=]] + +Here's a walk-through of ACE.js, our new in-browser code editor. It's +[[="it" the walkthrough? or "it" the browser?=]] +written in self-contained, cross-browser JavaScript that can be +dropped into any web page. It looks and feels a lot like a "native" +editor, meaning typing is fast and there are no artifacts or clutter. +It does syntax-highlighting live, as you type. Amazingly, it scales +up with document size. You can paste in 1,000 lines of text, or more, +and after a second or two of thought, the editor is fully responsive +again. While you keep typing, it unobtrusively finishes +syntax-highlighting the whole buffer in a matter of seconds. Local +edits to the text are just as fast on long documents as on short ones. +Changes that require large-scale re-highlighting, like opening or +closing a multi-line comment, affect the text in view almost +instantaneously, and then ACE quitely goes to work on the rest of the +document over the next few seconds without holding you up. Advanced +features include Emacs-style unlimited undo, flashing matching +parentheses as you type them or move across them, and basic +auto-indentation. Full functionality is supported on Internet +Explorer 6+, Firefox 2+, Safari 3+, and Camino 1.5+. + +I've emphasized "scalability" a lot so far, by which I mean efficiency +and responsiveness in the face of large documents, because that's the +aspect of ACE that so clearly sets it apart. But that's only one of +three "axes" that the ultimate editor needs to excel on. + +The second is what I'll call "nativity", meaning how close the editor +comes to the gold standard of the desktop editor experience. This +includes responsiveness (some in-browser editors have sluggish typing +even on small documents), but also things like undo, copy/paste, +selection, arrow-keys, shift-arrow-keys, different input methods and +devices, and so on. + +The third axis is "flexibility". How easy is it to add features? To +support more languages for the incremental highlighting, different +undo models, different indentation schemes, macros that expand as you +type, auto-complete, go-to-line by number, and whatever else you can +imagine. + +Why am I lecturing you on these theoretical principles? Well, there's +an interesting insight that explains a lot about the existing crop of +editors, and it isn't one you'd hit upon without spending a lot of +time in the trenches (yes, specifically the trenches of writing an +in-browser code editor). Based on the hodge-podge of facilities that +browsers happen to make available, you basically end up with the +following slogan: "scalability, nativity, flexibility, pick any two". +Based on this, we can classify editors into three types, which I'll +describe briefly from the point of view of someone writing an editor +(like me); if you're not familiar with browser scripting, hopefully +this won't be too hard to get through. + +[[= I'm not a huge fan of "type I-II-III" nomenclature. It's totally opaque. And in this case, they don't even form a continuum, except for type III being better than I and II. =]] + +Type I editors sacrifice scalability. The typical implementation is a +text-area to handle the typing, covered by a block of colored text to +handle the display. You (the person making the editor) get a boost in +nativity at the start, because you inherit the browser's text +handling, all the stuff I mentioned above, like undo and copy/paste. +The degree of flexibility is also good, because you can style the +colored text independently of the editing in the textarea, and you can +manipulate the textarea easily, such as by assigning a new content +string. Unfortunately, this scales quite badly with document size. +The good Type I editors are slick and responsive, but pretty limited +in how large files can get. + +Type II editors sacrifice nativity. This is the kind of editor where +you manually manipulate document (DOM) nodes as the user types. You +have to re-implement the desktop's native editing behavior from +scratch, first putting in support for typing and selecting text (both +by mouse and keyboard), and hopefully eventually supporting undo and +copy/paste with other programs (through some elaborate hack). This +type is attractive because it offers unlimited flexibility, and +theoretical scalability. In practice, you end up with mostly +flexibility, because getting the nativity right is such a huge task, +and scalability takes a back seat to general responsiveness. Type II +editors are fancy but feel slow and quirky. + +Type III editors, as you've probably guessed by now, are the category +ACE falls into, and are the ones that sacrifice flexibility, the third +axis, though in fact they make you work for all three axes. The crazy +idea here, which seems to have originated with Dutch programmer Marijn +Haverbeke, is to take advantage of a browser feature called "design +mode" (or "content editable"), a mode which allows the user to +directly edit an HTML document. This feature has quietly been added +to all major browsers over time. In fact, it's what GMail uses to let +users compose rich-text e-mail. The advantages of basing an editor on +a design-mode buffer are that such a buffer has a full DOM (document +model), which allows arbitrary styling and swapping of parts of the +document, and that native editing operations (selection, copy/paste) +are mapped by the browser onto operations on the DOM. + +[[= It's not clear how Type III editors sacrifice flexibility =]] + +What's the downside of a Type III editor? It's a nightmare to +implement! GMail skirts the issue by only using hard-coded browser +commands like "make the selection bold" or "insert unordered list". +What happens if you stray from this set of basic commands, and access +that alluring DOM directly, without careful preparation? Disaster! +Building a robust, extensible editor on top of design mode is kind of +like landing a man safely on the moon, where you design the +spacecraft, the mission control computer, and the pressurized suit. +You're constantly trying to insulate yourself from a hostile +environment. + +More specifically, any change your editor makes to the design mode DOM +causes the browser to instantly lose track of the selection range or +insertion point if any, the undo history, and basically any other +useful editing state. (This can be worked around with a lot of +selection manipulation, though IE in particular lacks even a way to +access the current selection relative to the DOM.) A simple edit like +the user pressing the "enter" key to start a new line may cause the +browser to insert a line break tag (BR), or split a block element into +two, whatever it wishes. Pasted text is converted into HTML, through +a somewhat arbitrary process, and inserted into the document. In +fact, the DOM is constantly being modified by the browser in response +to user actions (like typing), and you have to peek at it and +efficiently make sense of it, determine what's changed, incorporate it +into your representation, make any of your own changes (e.g. indent a +line), modify the DOM to display your changes to the user, and have it +all look like nothing special happened. A more Draconian policy for +dealing with the browser, like trapping all mouse and key events, +would just leave you with a Type II editor. The key is to treat the +DOM as a hugely complicated I/O device between you and the browser, +and carefully make rules to constrain it. [[= Genius analgy, IMO. :) =]] + +You also deal with the fact that design mode's "native" behavior is +HTML-oriented, not text-oriented, and the fact that it tends to have a +lot of quirks and bugs. You don't get scalability for free, either, +you need some clever data structures. For example, determining the +absolute line number of the blinking insertion point is an +order-of-document-size operation without the aid of efficient data +structures that can be maintained as the document changes. + +The plus side is that once you've systematically beat design mode into +submission, you can have an unmatched degree of scalability and +nativity. From there, it's just a matter of keeping your layers of +abstraction scalable, and being aware of "nativity"-style constraints +(like responsiveness and events), and you can build up to flexibility, +the crown jewel. The reward is how easy it is to add new editor +features! [[= I'm kind of confused here. You said ACE is a type III editor, sacrificing flexibility, but now you say that ACE *has* flexibility. Huh? =]] + +Speaking of which, here is a list of current ACE features. Some of +them are small and just required recognizing their benefit, while +others are more significant. [[= awkward sentence =]] Some features, like "Emacs-style undo" +and "highlight matching parentheses", are significant despite having +been implemented in a couple hours each, and are signs of what's to +come in the future of ACE. -- cgit v1.2.3-1-g7c22