Updated todo file.

todo.md

@@ -5,11 +5,6 @@
     //  glyph size, spacing, line wrapping, etc.).  Buffers then use
     //  BufferFormatters for maintaing information necessary for
     //  1d <-> 2d operations.
-    - Buffer should only store the text itself and the encoding type.  The
-      undo stack and line ending type should be moved into the editor since
-      they only apply to editing operations.  The buffer should only store
-      data related to how the text is statically presented or stored on
-      disk.
     - Create BufferFormatters for console and for freetype, including
       preferences for tab width (specified in spaces) and line wrapping.
       The freetype formatter should not reference SDL at all, and should
@@ -21,12 +16,47 @@
       likely be useful to other people as well, and would encourage me to
       keep the API clean.
 
+- Undo:
+    - Eventually, with global undo, the undo-stack is going to be project-wide,
+      so don't think too hard about where to put it just yet.  For now, just
+      put it somewhere convenient, outside of Buffer.
+
+- Scripting:
+    - What language to use for scripting?  Javascript, Lua, Python, Scheme, ...
+      It should be something easy to integrate and small, so probably not
+      Python.  Javascript, Lua, and Scheme all have small implementations
+      that would be easy to integrate.  Scheme limits the target audience
+      somewhat, as does Lua.  So Javascript is probably the best idea,
+      even though it's not as simple/clean as lua or scheme.
+    - In the end, only hard-code the core editing operations, and leave the
+      rest to scripting.  If something ends up being too slow, you can always
+      move it to be hard-coded for performance later.
+
+- Formatting:
+    - "Formatter" should really just be a factory for producing iterators for
+      lines.  Everything else can be inferred from that.
+    - Perhaps take the same approach as emacs, where scrolling is actually
+      a percentage of the way through the data of the document, rather than
+      a literal vertical position.  Alternatively, take a more complex approach
+      like gedit/mousepad where the immediately visible text gets updated
+      immediately, but a larger process runs in the background for a while to
+      update the rest of the document.  The biggest benefit of the emacs
+      approach is that it's simple and it completely decouples display of the
+      buffer from the text stored in it.
+    - Maybe the biggest lesson here is that regardless of how it's done, it
+      shouldn't actually live inside the buffer.  Formatting information needs        to be stored outside of the buffer either way.
+    - Start with the emacs approach, and you can always migrate to something
+      more sophisticated later.
+
 - Custom line iterator code for file loading, because rust's built-in one
   only recognizes LF and CRLF.
 - File loading is currently very slow.  Investigate.
+- Both Emacs and Vim do line-wrapping extremely efficiently, even for very
+  large files.  Investigate how they do this.
 - Line number display
 - File opening by entering path
 - UI that wraps editors, for split view.
 - Persistent infinite undo
-- "Projects"
+- Saving/loading files to/from buffers should be the Buffer's job, since it
-
+  knows its own internals and can optimize things better.
+- "Projects"