Updated todo file.

todo.md

@@ -1,25 +1,14 @@
-- Clean separation of text buffer from rest of code:
+- Syntax highlighting:
-    //- Create a "BufferFormatter" trait that informs Buffer how its text
+    - It's tempting to want to do syntax highlighting only on the bare
-    //  should be formatted.  Such formatters then determine how the
+      minimum parts of the text after an edit, but realistically there
-    //  text buffer graphemes map to a 2d display (e.g. how tabs are handles,
+      are always cases where the entire text has to be scanned again to
-    //  glyph size, spacing, line wrapping, etc.).  Buffers then use
+      get correct results.  So it must be something that can be done
-    //  BufferFormatters for maintaing information necessary for
+      asynchronously.
-    //  1d <-> 2d operations.
+    - Maybe a quick-n-dirty local update, followed by an async background
-    - Create BufferFormatters for console and for freetype, including
+      update.
-      preferences for tab width (specified in spaces) and line wrapping.
+    - Should the syntax highlighting data be stored in the text buffer itself?
-      The freetype formatter should not reference SDL at all, and should
+      Or should there be an accompanying structure on the side for that?
-      have only the freetype library itself as a dependency.
+    - What do other editors do?
-    //- Handle tab settings properly after the refactor
-    //- Buffer needs a "reformat" method, which can be run after the formatter
-    //  is changed in some way (e.g. toggling line wrapping).
-    - Possibly split the text buffer out into its own library...?  Would
-      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, ...
@@ -32,27 +21,6 @@
       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.