How it works?

[mzbab88]

Can you write a bit about how it works? I'm interested in how you store an open file and undo history. What happens when you open a new file, and what happens when you copypaste something from one part of file to another.

[nsf]

Well, the files are stored as double-linked lists of lines. That may lead to problems if you have very long lines of text, but it has to be really long to be noticable (maybe 1 MB or more). Text is stored as UTF-8 directly. Every time I need to find the position on a line in characters I just scan UTF-8 sequence.

As for history. All histories I know of are always implemented as a set of rewindable actions. So as godit. With text it's pretty simple, you can insert text and you can remove text. You store that as an action. Of course what text is inserted/removed needs to be recorded and of course where it's inserted is also relevant. There is also additional bookkeeping for cursor position before and after action, because you can delete the same chunk of text from two different cursor positions (e.g. backspace vs delete), when you undo you have certain expectations about cursor location. And finally you can group history actions so that they represent single "undo" step.

Overall architecture of an editor is far from best. There is tight coupling between visual representation of the text buffer (view) and the buffer itself. I wanted to fix that, but it probably will never happen. Internally in godit in order to edit text using all the fancy commands, text has to be visible, which is definitely a problem if you want to implement some "off screen" editing, like global search & replace.

I still use godit almost every day. Sometimes for various quick edits, and for git commits (it's set as my EDITOR env var). Even though I code in sublime and don't really use emacs key bindings anymore.

[mzbab88]

Thank you for responding, really appreciate that. Simplicity of godit's source code is probably his best trait, haven't seen a text editor simplier yet. Still can't quite grasp it's logic though.

I'm trying to do a text editor too, and I have this idea of speeding up file opening and minimising memory usage by loading a file in a bunch of 4KiB sized chunks, and using one 4KiB chunk as an array of [pointer to string, len of string] pairs to represent a file. But I got confused by my own ideas, and I'll probably need to write something reminisent of memory manager, deal with memory fragmentation, and probably still waste a lot of memory while saving a file and defragmenting memory. I'll probably just use your way.

[nsf]

If you want to make a text editor that can easily work with large files, your best bet is to rely on OS primitives that can be very helpful here. Take a look at memory mapping (https://en.wikipedia.org/wiki/Mmap). But I can't be more specific here as I've never done anything like that.

Yes, godit was written to be simple, that's why I never went into difficult topics, such as syntax highlighting or automatically breaking long lines of text into multiple visible lines. And as you've noticed godit has no settings at all, another deliberate decision.