A "marker" is basically like a persistent selection/cursor composite,
having a head and a tail. The "head" is like the cursor in a selection,
and the "tail" is like the part of the selection that doesn't move. My
goal is for markers to be the only construct used to track regions
in the buffer. I want to replace anchors with them.
BufferChangeOperation now takes an options hash that
can specify whether line endings should be normalized.
This option is set to false when Buffer.setText is called.
This replaces the previous assignment of lineEndings to []
with a more explicit mechanism.
This removes the need to open a new repository
each time a directory-view or file-view is displayed
and also when a status-bar is displayed for a buffer.
This prevents autosave from writing unmodified buffers to disk, which
was causing the tree view to rebuild directory contents based on the
write event just when switching tabs.
For this to work, I needed to make the updating of anchors transactional. Now, all anchors are updated and *then* they emit their events. That way when the cursor moves based on the user typing, the tab stop they're in has a chance to expand before we handle the move event. This prevents spurious cancellation of the snippet when typing on a tab stop.
Path watching resumes once the file is saved again. This commit allows files to be created for as-yet nonexistent paths. We won't call `$native.watchPath` until we have at least 1 subscription to the file in JS and the file exists on disk.
Also, we moved execution of the path watcher callbacks until after the callbacks data structure is updated in order to avoid confusing behavior in specs.
This will be used by the status bar and other expensive code that needs to respond to the buffer changing, but that we don't want running on every single keystroke when the user is typing quickly.
Computing the signature was really slow for large files. Keeping a cached copy of the disk contents and comparing directly costs less in the benchmark. We'll have to turn on the status bar in benchmarks to see if the comparison is too expensive.
Now, we maintain md5 signatures for the on-disk and in-memory contents of the buffer. Whenever either contents change, we recompute the signature and store it on the buffer. We can tell if the buffer is modified by comparing these signatures. When the disk contents change, we compare the memory and disk signatures *before* recomputing the disk signature to determine whether to update the buffer or mark it as a conflict.
