Empty or almost-empty lines would cause the highlighter to stop
highlighting, because they didn't get new styles, even when the
styling of the lines around them was completely changed (for
example when adding a script tag around something in HTML mixed
mode)

readInput would, in some cases, take effect even though our textarea
was in context-menu-hack mode.

This might very well break something else, but passes my minimal tests.

So that languages in which blank lines are significant can detect
them.

Apparently, popping up the context menu took more than 50 \(\!\)
milliseconds on that platform, and codemirror had already hidden
the textarea again by the time the menu arrived.

The code that selected the content of the textarea on a right-click
wasn't selecting everything in IE because of the schizophrenic
approach it takes to newlines and carriage returns.

- Trailing commas in object literals are not allowed by the spec
  and are handled poorly in some browsers.
- Added var to some variable declarations that were not meant to be globals.

(apparently my uglifyJS web-shim doesn't like redirects)

Holding shift and then moving the cursor through the API would cause a
'selection extension' to happen, instead of simply moving the
selection to its new state. Most visible when bindin shift-key combos
to some editing function.

Otherwise, in XHTML documents, writing a ]]> causes bad things
to happen.

For some reason, the absolutely positioned DIV containing the input
textarea causes weird scrolling artifacts when set to width 0. Giving it
width 1px and height 0 makes it behave normally again.