2
0

internals.html 25 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505
  1. <!doctype html>
  2. <html>
  3. <head>
  4. <meta charset="utf-8"/>
  5. <title>CodeMirror: Internals</title>
  6. <link rel="stylesheet" type="text/css" href="http://fonts.googleapis.com/css?family=Droid+Sans|Droid+Sans:bold"/>
  7. <link rel="stylesheet" type="text/css" href="docs.css"/>
  8. <style>dl dl {margin: 0;} .update {color: #d40 !important}</style>
  9. </head>
  10. <body>
  11. <h1><span class="logo-braces">{ }</span> <a href="http://codemirror.net/">CodeMirror</a></h1>
  12. <div class="grey">
  13. <img src="baboon.png" class="logo" alt="logo"/>
  14. <pre>
  15. /* (Re-) Implementing A Syntax-
  16. Highlighting Editor in JavaScript */
  17. </pre>
  18. </div>
  19. <div class="clear"><div class="leftbig blk">
  20. <p style="font-size: 85%" id="intro">
  21. <strong>Topic:</strong> JavaScript, code editor implementation<br>
  22. <strong>Author:</strong> Marijn Haverbeke<br>
  23. <strong>Date:</strong> March 2nd 2011 (updated November 13th 2011)
  24. </p>
  25. <p style="padding: 0 3em 0 2em"><strong>Caution</strong>: this text was written briefly after
  26. version 2 was initially written. It no longer (even including the
  27. update at the bottom) fully represents the current implementation. I'm
  28. leaving it here as a historic document. For more up-to-date
  29. information, look at the entries
  30. tagged <a href="http://marijnhaverbeke.nl/blog/#cm-internals">cm-internals</a>
  31. on my blog.</p>
  32. <p>This is a followup to
  33. my <a href="http://codemirror.net/story.html">Brutal Odyssey to the
  34. Dark Side of the DOM Tree</a> story. That one describes the
  35. mind-bending process of implementing (what would become) CodeMirror 1.
  36. This one describes the internals of CodeMirror 2, a complete rewrite
  37. and rethink of the old code base. I wanted to give this piece another
  38. Hunter Thompson copycat subtitle, but somehow that would be out of
  39. place—the process this time around was one of straightforward
  40. engineering, requiring no serious mind-bending whatsoever.</p>
  41. <p>So, what is wrong with CodeMirror 1? I'd estimate, by mailing list
  42. activity and general search-engine presence, that it has been
  43. integrated into about a thousand systems by now. The most prominent
  44. one, since a few weeks,
  45. being <a href="http://googlecode.blogspot.com/2011/01/make-quick-fixes-quicker-on-google.html">Google
  46. code's project hosting</a>. It works, and it's being used widely.</p>
  47. <p>Still, I did not start replacing it because I was bored. CodeMirror
  48. 1 was heavily reliant on <code>designMode</code>
  49. or <code>contentEditable</code> (depending on the browser). Neither of
  50. these are well specified (HTML5 tries
  51. to <a href="http://www.w3.org/TR/html5/editing.html#contenteditable">specify</a>
  52. their basics), and, more importantly, they tend to be one of the more
  53. obscure and buggy areas of browser functionality—CodeMirror, by using
  54. this functionality in a non-typical way, was constantly running up
  55. against browser bugs. WebKit wouldn't show an empty line at the end of
  56. the document, and in some releases would suddenly get unbearably slow.
  57. Firefox would show the cursor in the wrong place. Internet Explorer
  58. would insist on linkifying everything that looked like a URL or email
  59. address, a behaviour that can't be turned off. Some bugs I managed to
  60. work around (which was often a frustrating, painful process), others,
  61. such as the Firefox cursor placement, I gave up on, and had to tell
  62. user after user that they were known problems, but not something I
  63. could help.</p>
  64. <p>Also, there is the fact that <code>designMode</code> (which seemed
  65. to be less buggy than <code>contentEditable</code> in Webkit and
  66. Firefox, and was thus used by CodeMirror 1 in those browsers) requires
  67. a frame. Frames are another tricky area. It takes some effort to
  68. prevent getting tripped up by domain restrictions, they don't
  69. initialize synchronously, behave strangely in response to the back
  70. button, and, on several browsers, can't be moved around the DOM
  71. without having them re-initialize. They did provide a very nice way to
  72. namespace the library, though—CodeMirror 1 could freely pollute the
  73. namespace inside the frame.</p>
  74. <p>Finally, working with an editable document means working with
  75. selection in arbitrary DOM structures. Internet Explorer (8 and
  76. before) has an utterly different (and awkward) selection API than all
  77. of the other browsers, and even among the different implementations of
  78. <code>document.selection</code>, details about how exactly a selection
  79. is represented vary quite a bit. Add to that the fact that Opera's
  80. selection support tended to be very buggy until recently, and you can
  81. imagine why CodeMirror 1 contains 700 lines of selection-handling
  82. code.</p>
  83. <p>And that brings us to the main issue with the CodeMirror 1
  84. code base: The proportion of browser-bug-workarounds to real
  85. application code was getting dangerously high. By building on top of a
  86. few dodgy features, I put the system in a vulnerable position—any
  87. incompatibility and bugginess in these features, I had to paper over
  88. with my own code. Not only did I have to do some serious stunt-work to
  89. get it to work on older browsers (as detailed in the
  90. previous <a href="http://codemirror.net/story.html">story</a>), things
  91. also kept breaking in newly released versions, requiring me to come up
  92. with <em>new</em> scary hacks in order to keep up. This was starting
  93. to lose its appeal.</p>
  94. <h2 id="approach">General Approach</h2>
  95. <p>What CodeMirror 2 does is try to sidestep most of the hairy hacks
  96. that came up in version 1. I owe a lot to the
  97. <a href="http://ace.ajax.org">ACE</a> editor for inspiration on how to
  98. approach this.</p>
  99. <p>I absolutely did not want to be completely reliant on key events to
  100. generate my input. Every JavaScript programmer knows that key event
  101. information is horrible and incomplete. Some people (most awesomely
  102. Mihai Bazon with <a href="http://ymacs.org">Ymacs</a>) have been able
  103. to build more or less functioning editors by directly reading key
  104. events, but it takes a lot of work (the kind of never-ending, fragile
  105. work I described earlier), and will never be able to properly support
  106. things like multi-keystoke international character
  107. input. <a href="#keymap" class="update">[see below for caveat]</a></p>
  108. <p>So what I do is focus a hidden textarea, and let the browser
  109. believe that the user is typing into that. What we show to the user is
  110. a DOM structure we built to represent his document. If this is updated
  111. quickly enough, and shows some kind of believable cursor, it feels
  112. like a real text-input control.</p>
  113. <p>Another big win is that this DOM representation does not have to
  114. span the whole document. Some CodeMirror 1 users insisted that they
  115. needed to put a 30 thousand line XML document into CodeMirror. Putting
  116. all that into the DOM takes a while, especially since, for some
  117. reason, an editable DOM tree is slower than a normal one on most
  118. browsers. If we have full control over what we show, we must only
  119. ensure that the visible part of the document has been added, and can
  120. do the rest only when needed. (Fortunately, the <code>onscroll</code>
  121. event works almost the same on all browsers, and lends itself well to
  122. displaying things only as they are scrolled into view.)</p>
  123. <h2 id="input">Input</h2>
  124. <p>ACE uses its hidden textarea only as a text input shim, and does
  125. all cursor movement and things like text deletion itself by directly
  126. handling key events. CodeMirror's way is to let the browser do its
  127. thing as much as possible, and not, for example, define its own set of
  128. key bindings. One way to do this would have been to have the whole
  129. document inside the hidden textarea, and after each key event update
  130. the display DOM to reflect what's in that textarea.</p>
  131. <p>That'd be simple, but it is not realistic. For even medium-sized
  132. document the editor would be constantly munging huge strings, and get
  133. terribly slow. What CodeMirror 2 does is put the current selection,
  134. along with an extra line on the top and on the bottom, into the
  135. textarea.</p>
  136. <p>This means that the arrow keys (and their ctrl-variations), home,
  137. end, etcetera, do not have to be handled specially. We just read the
  138. cursor position in the textarea, and update our cursor to match it.
  139. Also, copy and paste work pretty much for free, and people get their
  140. native key bindings, without any special work on my part. For example,
  141. I have emacs key bindings configured for Chrome and Firefox. There is
  142. no way for a script to detect this. <a class="update"
  143. href="#keymap">[no longer the case]</a></p>
  144. <p>Of course, since only a small part of the document sits in the
  145. textarea, keys like page up and ctrl-end won't do the right thing.
  146. CodeMirror is catching those events and handling them itself.</p>
  147. <h2 id="selection">Selection</h2>
  148. <p>Getting and setting the selection range of a textarea in modern
  149. browsers is trivial—you just use the <code>selectionStart</code>
  150. and <code>selectionEnd</code> properties. On IE you have to do some
  151. insane stuff with temporary ranges and compensating for the fact that
  152. moving the selection by a 'character' will treat \r\n as a single
  153. character, but even there it is possible to build functions that
  154. reliably set and get the selection range.</p>
  155. <p>But consider this typical case: When I'm somewhere in my document,
  156. press shift, and press the up arrow, something gets selected. Then, if
  157. I, still holding shift, press the up arrow again, the top of my
  158. selection is adjusted. The selection remembers where its <em>head</em>
  159. and its <em>anchor</em> are, and moves the head when we shift-move.
  160. This is a generally accepted property of selections, and done right by
  161. every editing component built in the past twenty years.</p>
  162. <p>But not something that the browser selection APIs expose.</p>
  163. <p>Great. So when someone creates an 'upside-down' selection, the next
  164. time CodeMirror has to update the textarea, it'll re-create the
  165. selection as an 'upside-up' selection, with the anchor at the top, and
  166. the next cursor motion will behave in an unexpected way—our second
  167. up-arrow press in the example above will not do anything, since it is
  168. interpreted in exactly the same way as the first.</p>
  169. <p>No problem. We'll just, ehm, detect that the selection is
  170. upside-down (you can tell by the way it was created), and then, when
  171. an upside-down selection is present, and a cursor-moving key is
  172. pressed in combination with shift, we quickly collapse the selection
  173. in the textarea to its start, allow the key to take effect, and then
  174. combine its new head with its old anchor to get the <em>real</em>
  175. selection.</p>
  176. <p>In short, scary hacks could not be avoided entirely in CodeMirror
  177. 2.</p>
  178. <p>And, the observant reader might ask, how do you even know that a
  179. key combo is a cursor-moving combo, if you claim you support any
  180. native key bindings? Well, we don't, but we can learn. The editor
  181. keeps a set known cursor-movement combos (initialized to the
  182. predictable defaults), and updates this set when it observes that
  183. pressing a certain key had (only) the effect of moving the cursor.
  184. This, of course, doesn't work if the first time the key is used was
  185. for extending an inverted selection, but it works most of the
  186. time.</p>
  187. <h2 id="update">Intelligent Updating</h2>
  188. <p>One thing that always comes up when you have a complicated internal
  189. state that's reflected in some user-visible external representation
  190. (in this case, the displayed code and the textarea's content) is
  191. keeping the two in sync. The naive way is to just update the display
  192. every time you change your state, but this is not only error prone
  193. (you'll forget), it also easily leads to duplicate work on big,
  194. composite operations. Then you start passing around flags indicating
  195. whether the display should be updated in an attempt to be efficient
  196. again and, well, at that point you might as well give up completely.</p>
  197. <p>I did go down that road, but then switched to a much simpler model:
  198. simply keep track of all the things that have been changed during an
  199. action, and then, only at the end, use this information to update the
  200. user-visible display.</p>
  201. <p>CodeMirror uses a concept of <em>operations</em>, which start by
  202. calling a specific set-up function that clears the state and end by
  203. calling another function that reads this state and does the required
  204. updating. Most event handlers, and all the user-visible methods that
  205. change state are wrapped like this. There's a method
  206. called <code>operation</code> that accepts a function, and returns
  207. another function that wraps the given function as an operation.</p>
  208. <p>It's trivial to extend this (as CodeMirror does) to detect nesting,
  209. and, when an operation is started inside an operation, simply
  210. increment the nesting count, and only do the updating when this count
  211. reaches zero again.</p>
  212. <p>If we have a set of changed ranges and know the currently shown
  213. range, we can (with some awkward code to deal with the fact that
  214. changes can add and remove lines, so we're dealing with a changing
  215. coordinate system) construct a map of the ranges that were left
  216. intact. We can then compare this map with the part of the document
  217. that's currently visible (based on scroll offset and editor height) to
  218. determine whether something needs to be updated.</p>
  219. <p>CodeMirror uses two update algorithms—a full refresh, where it just
  220. discards the whole part of the DOM that contains the edited text and
  221. rebuilds it, and a patch algorithm, where it uses the information
  222. about changed and intact ranges to update only the out-of-date parts
  223. of the DOM. When more than 30 percent (which is the current heuristic,
  224. might change) of the lines need to be updated, the full refresh is
  225. chosen (since it's faster to do than painstakingly finding and
  226. updating all the changed lines), in the other case it does the
  227. patching (so that, if you scroll a line or select another character,
  228. the whole screen doesn't have to be
  229. re-rendered). <span class="update">[the full-refresh
  230. algorithm was dropped, it wasn't really faster than the patching
  231. one]</span></p>
  232. <p>All updating uses <code>innerHTML</code> rather than direct DOM
  233. manipulation, since that still seems to be by far the fastest way to
  234. build documents. There's a per-line function that combines the
  235. highlighting, <a href="manual.html#markText">marking</a>, and
  236. selection info for that line into a snippet of HTML. The patch updater
  237. uses this to reset individual lines, the refresh updater builds an
  238. HTML chunk for the whole visible document at once, and then uses a
  239. single <code>innerHTML</code> update to do the refresh.</p>
  240. <h2 id="parse">Parsers can be Simple</h2>
  241. <p>When I wrote CodeMirror 1, I
  242. thought <a href="http://codemirror.net/story.html#parser">interruptable
  243. parsers</a> were a hugely scary and complicated thing, and I used a
  244. bunch of heavyweight abstractions to keep this supposed complexity
  245. under control: parsers
  246. were <a href="http://bob.pythonmac.org/archives/2005/07/06/iteration-in-javascript/">iterators</a>
  247. that consumed input from another iterator, and used funny
  248. closure-resetting tricks to copy and resume themselves.</p>
  249. <p>This made for a rather nice system, in that parsers formed strictly
  250. separate modules, and could be composed in predictable ways.
  251. Unfortunately, it was quite slow (stacking three or four iterators on
  252. top of each other), and extremely intimidating to people not used to a
  253. functional programming style.</p>
  254. <p>With a few small changes, however, we can keep all those
  255. advantages, but simplify the API and make the whole thing less
  256. indirect and inefficient. CodeMirror
  257. 2's <a href="manual.html#modeapi">mode API</a> uses explicit state
  258. objects, and makes the parser/tokenizer a function that simply takes a
  259. state and a character stream abstraction, advances the stream one
  260. token, and returns the way the token should be styled. This state may
  261. be copied, optionally in a mode-defined way, in order to be able to
  262. continue a parse at a given point. Even someone who's never touched a
  263. lambda in his life can understand this approach. Additionally, far
  264. fewer objects are allocated in the course of parsing now.</p>
  265. <p>The biggest speedup comes from the fact that the parsing no longer
  266. has to touch the DOM though. In CodeMirror 1, on an older browser, you
  267. could <em>see</em> the parser work its way through the document,
  268. managing some twenty lines in each 50-millisecond time slice it got. It
  269. was reading its input from the DOM, and updating the DOM as it went
  270. along, which any experienced JavaScript programmer will immediately
  271. spot as a recipe for slowness. In CodeMirror 2, the parser usually
  272. finishes the whole document in a single 100-millisecond time slice—it
  273. manages some 1500 lines during that time on Chrome. All it has to do
  274. is munge strings, so there is no real reason for it to be slow
  275. anymore.</p>
  276. <h2 id="summary">What Gives?</h2>
  277. <p>Given all this, what can you expect from CodeMirror 2?</p>
  278. <ul>
  279. <li><strong>Small.</strong> the base library is
  280. some <span class="update">45k</span> when minified
  281. now, <span class="update">17k</span> when gzipped. It's smaller than
  282. its own logo.</li>
  283. <li><strong>Lightweight.</strong> CodeMirror 2 initializes very
  284. quickly, and does almost no work when it is not focused. This means
  285. you can treat it almost like a textarea, have multiple instances on a
  286. page without trouble.</li>
  287. <li><strong>Huge document support.</strong> Since highlighting is
  288. really fast, and no DOM structure is being built for non-visible
  289. content, you don't have to worry about locking up your browser when a
  290. user enters a megabyte-sized document.</li>
  291. <li><strong>Extended API.</strong> Some things kept coming up in the
  292. mailing list, such as marking pieces of text or lines, which were
  293. extremely hard to do with CodeMirror 1. The new version has proper
  294. support for these built in.</li>
  295. <li><strong>Tab support.</strong> Tabs inside editable documents were,
  296. for some reason, a no-go. At least six different people announced they
  297. were going to add tab support to CodeMirror 1, none survived (I mean,
  298. none delivered a working version). CodeMirror 2 no longer removes tabs
  299. from your document.</li>
  300. <li><strong>Sane styling.</strong> <code>iframe</code> nodes aren't
  301. really known for respecting document flow. Now that an editor instance
  302. is a plain <code>div</code> element, it is much easier to size it to
  303. fit the surrounding elements. You don't even have to make it scroll if
  304. you do not <a href="../demo/resize.html">want to</a>.</li>
  305. </ul>
  306. <p>On the downside, a CodeMirror 2 instance is <em>not</em> a native
  307. editable component. Though it does its best to emulate such a
  308. component as much as possible, there is functionality that browsers
  309. just do not allow us to hook into. Doing select-all from the context
  310. menu, for example, is not currently detected by CodeMirror.</p>
  311. <p id="changes" style="margin-top: 2em;"><span style="font-weight:
  312. bold">[Updates from November 13th 2011]</span> Recently, I've made
  313. some changes to the codebase that cause some of the text above to no
  314. longer be current. I've left the text intact, but added markers at the
  315. passages that are now inaccurate. The new situation is described
  316. below.</p>
  317. <h2 id="btree">Content Representation</h2>
  318. <p>The original implementation of CodeMirror 2 represented the
  319. document as a flat array of line objects. This worked well—splicing
  320. arrays will require the part of the array after the splice to be
  321. moved, but this is basically just a simple <code>memmove</code> of a
  322. bunch of pointers, so it is cheap even for huge documents.</p>
  323. <p>However, I recently added line wrapping and code folding (line
  324. collapsing, basically). Once lines start taking up a non-constant
  325. amount of vertical space, looking up a line by vertical position
  326. (which is needed when someone clicks the document, and to determine
  327. the visible part of the document during scrolling) can only be done
  328. with a linear scan through the whole array, summing up line heights as
  329. you go. Seeing how I've been going out of my way to make big documents
  330. fast, this is not acceptable.</p>
  331. <p>The new representation is based on a B-tree. The leaves of the tree
  332. contain arrays of line objects, with a fixed minimum and maximum size,
  333. and the non-leaf nodes simply hold arrays of child nodes. Each node
  334. stores both the amount of lines that live below them and the vertical
  335. space taken up by these lines. This allows the tree to be indexed both
  336. by line number and by vertical position, and all access has
  337. logarithmic complexity in relation to the document size.</p>
  338. <p>I gave line objects and tree nodes parent pointers, to the node
  339. above them. When a line has to update its height, it can simply walk
  340. these pointers to the top of the tree, adding or subtracting the
  341. difference in height from each node it encounters. The parent pointers
  342. also make it cheaper (in complexity terms, the difference is probably
  343. tiny in normal-sized documents) to find the current line number when
  344. given a line object. In the old approach, the whole document array had
  345. to be searched. Now, we can just walk up the tree and count the sizes
  346. of the nodes coming before us at each level.</p>
  347. <p>I chose B-trees, not regular binary trees, mostly because they
  348. allow for very fast bulk insertions and deletions. When there is a big
  349. change to a document, it typically involves adding, deleting, or
  350. replacing a chunk of subsequent lines. In a regular balanced tree, all
  351. these inserts or deletes would have to be done separately, which could
  352. be really expensive. In a B-tree, to insert a chunk, you just walk
  353. down the tree once to find where it should go, insert them all in one
  354. shot, and then break up the node if needed. This breaking up might
  355. involve breaking up nodes further up, but only requires a single pass
  356. back up the tree. For deletion, I'm somewhat lax in keeping things
  357. balanced—I just collapse nodes into a leaf when their child count goes
  358. below a given number. This means that there are some weird editing
  359. patterns that may result in a seriously unbalanced tree, but even such
  360. an unbalanced tree will perform well, unless you spend a day making
  361. strangely repeating edits to a really big document.</p>
  362. <h2 id="keymap">Keymaps</h2>
  363. <p><a href="#approach">Above</a>, I claimed that directly catching key
  364. events for things like cursor movement is impractical because it
  365. requires some browser-specific kludges. I then proceeded to explain
  366. some awful <a href="#selection">hacks</a> that were needed to make it
  367. possible for the selection changes to be detected through the
  368. textarea. In fact, the second hack is about as bad as the first.</p>
  369. <p>On top of that, in the presence of user-configurable tab sizes and
  370. collapsed and wrapped lines, lining up cursor movement in the textarea
  371. with what's visible on the screen becomes a nightmare. Thus, I've
  372. decided to move to a model where the textarea's selection is no longer
  373. depended on.</p>
  374. <p>So I moved to a model where all cursor movement is handled by my
  375. own code. This adds support for a goal column, proper interaction of
  376. cursor movement with collapsed lines, and makes it possible for
  377. vertical movement to move through wrapped lines properly, instead of
  378. just treating them like non-wrapped lines.</p>
  379. <p>The key event handlers now translate the key event into a string,
  380. something like <code>Ctrl-Home</code> or <code>Shift-Cmd-R</code>, and
  381. use that string to look up an action to perform. To make keybinding
  382. customizable, this lookup goes through
  383. a <a href="manual.html#option_keyMap">table</a>, using a scheme that
  384. allows such tables to be chained together (for example, the default
  385. Mac bindings fall through to a table named 'emacsy', which defines
  386. basic Emacs-style bindings like <code>Ctrl-F</code>, and which is also
  387. used by the custom Emacs bindings).</p>
  388. <p>A new
  389. option <a href="manual.html#option_extraKeys"><code>extraKeys</code></a>
  390. allows ad-hoc keybindings to be defined in a much nicer way than what
  391. was possible with the
  392. old <a href="manual.html#option_onKeyEvent"><code>onKeyEvent</code></a>
  393. callback. You simply provide an object mapping key identifiers to
  394. functions, instead of painstakingly looking at raw key events.</p>
  395. <p>Built-in commands map to strings, rather than functions, for
  396. example <code>"goLineUp"</code> is the default action bound to the up
  397. arrow key. This allows new keymaps to refer to them without
  398. duplicating any code. New commands can be defined by assigning to
  399. the <code>CodeMirror.commands</code> object, which maps such commands
  400. to functions.</p>
  401. <p>The hidden textarea now only holds the current selection, with no
  402. extra characters around it. This has a nice advantage: polling for
  403. input becomes much, much faster. If there's a big selection, this text
  404. does not have to be read from the textarea every time—when we poll,
  405. just noticing that something is still selected is enough to tell us
  406. that no new text was typed.</p>
  407. <p>The reason that cheap polling is important is that many browsers do
  408. not fire useful events on IME (input method engine) input, which is
  409. the thing where people inputting a language like Japanese or Chinese
  410. use multiple keystrokes to create a character or sequence of
  411. characters. Most modern browsers fire <code>input</code> when the
  412. composing is finished, but many don't fire anything when the character
  413. is updated <em>during</em> composition. So we poll, whenever the
  414. editor is focused, to provide immediate updates of the display.</p>
  415. </div><div class="rightsmall blk">
  416. <h2>Contents</h2>
  417. <ul>
  418. <li><a href="#intro">Introduction</a></li>
  419. <li><a href="#approach">General Approach</a></li>
  420. <li><a href="#input">Input</a></li>
  421. <li><a href="#selection">Selection</a></li>
  422. <li><a href="#update">Intelligent Updating</a></li>
  423. <li><a href="#parse">Parsing</a></li>
  424. <li><a href="#summary">What Gives?</a></li>
  425. <li><a href="#btree">Content Representation</a></li>
  426. <li><a href="#keymap">Key Maps</a></li>
  427. </ul>
  428. </div></div>
  429. <div style="height: 2em">&nbsp;</div>
  430. </body></html>