# 2023-10-10

It's been a few days, but I've gotten a lot done. I'm overdue for a
brain dump, but the gist is 

+ Packaging for klib [1] and kge [2], generating .deb files too. I've
  verified that the demo program for kge works installation-wise,
  including desktop and icon support. I use an AI image generator to
  come up with an icon.
+ Doxygenated klib, which felt good.
+ Tracked down weird memory bugs in the Arena and Buffer that leaked
  over into the TLV and Dictionary classes. Also had to hunt down some
  Windows-specific bugs that made me realize that I don't really want
  to do Windows programming.
+ Started a port of ke [3] to C++. This should give me some experience
  in writing a text editor without worrying about the graphics part.
+ Figured out how to prevent a CMake package from installing subproject
  dependencies (aka those grabbed with FetchContent). This sort of
  speeds up development by not needing to have to regenerate and install
  a package each time, but it does mean the changes in klib need to be
  synced upstream first.

## Adventures in writing a text editor

I'm starting off with a CLI editor first to avoid having to deal with
GUI problems.  I wrote an editor in C in 2019 that is still plagued
with memory issues, so I'm hoping to resolve that with a rewrite.  The
first version was intended to be a draft anyhow, following along with a
tutorial.

Let's start with the basics: what is a text editor?  According to
Finseth [4], a text editor is a program that takes some input and
transforms into some output.  That's most programs, right?

I think a text editor is a program that takes key presses as inputs,
performs some (potentially no) processing on them, and stores them in
memory.  That memory can be occasionally be flushed out to disk.

I'm starting with the basic idea of a Frame.  This is sort of an
overload term, but in the case of an editor, a Frame holds some text. 
The frame might be associated with a path that the file should be
flushed out to. Or, it might just remain in memory: a scratchpad of
sorts. The frame should offer a toolset for manipulating the text in
the frame, such as search, replace, cutting, and yanking.

My text editor should have a few key features:

+ Wordstar/TurboPascal style keybindings, with some movement borrowed
  from emacs.
+ Integration with a build system, such as cmake.
+ Copy/paste.
+ Eventually, some sort of styling, but I think I might start with a
  basic gruvbox or eink inspired colouring.
+ Hex editing mode.

There's going to need to be a concept for a key mode: are we inputting
text, entering a command, or escaping a character?

Progress tonight:

+ Wrote a Cursor class with basic cursor distances. Should I replace
  this with a std::pair?
+ Started a File class that's meant to represent a backing file. It needs
  a way to get a read and write handle on the file, because it won't
  know about the backing memory store in a Frame. Thus, a straight 
  Flush(uint8_t *) won't work, for example.
+ Sketched out a Frame class. Thinking about things led to working on
  the File type, particularly about marking files read-only.

Some thoughts:

+ joe's C-c to exit everything, including the editor, is growing on me.
+ Classes to add: TerminalMode, EditorMode, EditorState (which frames
  are open, which one is active, etc).
+ Associate a Cursor with the Frame. Should this be a list of Cursors,
  e.g. representing the ability to jump around in the file? Something
  for later.

## References

[1] https://git.wntrmute.dev/kyle/klib
[2] https://git.wntrmute.dev/kyle/kge
[3] https://git.wntrmute.dev/kyle/ke
[4] https://www.finseth.com/craft/