DisplayBuffer should just focus on providing basic support for folding.
Scanning the structure of the code, looking at scopes, etc is more the
domain of the LanguageMode object.
Structural folding should really be handled at the edit session level
so that the DisplayBuffer doesn't need access to the LanguageMode. It
should only be concerned with the raw ability to create folds.
Since this is the more external method, having a shorter name
is more convenient. The former `buildEditSession` method took a
Buffer, and is now called `buildEditSessionForBuffer`.
This prevents the editor from synchronously redrawing in specs with
cursors in invalid locations. Markers are always updated under the
hood before a change event is emitted from the Buffer or DisplayBuffer.
We still wait to trigger marker observers, but if their position gets
read, it is up to date.
This is needed by the snippets package, which needs to know where the
cursor was previously when it moves to decide whether to cancel the
current snippet.
This is used by cursor to only autoscroll when the marker head is
explicitly moved, so that passive movements caused by buffer insertions
don't trigger autoscrolling.
Whereas marker methods on buffer take for granted that everything is
in buffer coordinates, methods on the DisplayBuffer offer both
screen and buffer coordinate versions of the marker API.
LanguageMode is the central point for all language-specific behavior associated with an EditSession. There is one LanguageMode instance per EditSession. LanguageMode has access to the EditSession and its TokenizedBuffer, and in reverse the EditSession, DisplayBuffer, and TokenizedBuffer also make use of LanguageMode. This is a bit incestuous, but I think it's okay because you can think of LanguageMode as a swappable strategy object that governs language-specific aspects of that constellation of objects.
The idea is that the DisplayBuffer serves a similar role to the Buffer, except that it's holding content in an arrangement that's optimized for display.
