I have a different suggestion. Start with a single line. define an api for move, insert and delete. figure out how to display this line, associate the cursor with the current position and how to map keystrokes to these simple functions. Add commands to load/save this one line file. Also some convenience functions (move to star/end of a line etc). Add simple search, search and replace. Next extend this to as many lines as you can display on your screen. Add more commands. Add commands to operate on a sequence of lines. Next allow arbitrary number of lines, and arbitrary length lines (now you can see only a rectangular slice of the file). Add commands to move that window, move lines around etc. Resist the urge to micro optimize or do so early. Just use the simplest data structures that help you write the clearest code. Later you can profile the code and fix slow parts.
I suggest this as it will force you to solve problems yourself as opposed reading about other people’s solutions. Basically learn by doing. Learn by struggling to come up with solutions and data structures, thereby developing some insight. The stepwise development should help focus on a small subset of problems at a time. Don’t be afraid of changing data structures as you gain knowledge. In fact write code to make it easy! Use a language that won’t trip you up in low level issues such as memory management. The api will make testing easier. Armed with this knowledge you’ll better appreciate and understand other people’s solutions as well!
Similar suggestion: if you're trying to learn the architecture of a big established project like Vim or Emacs, don't start at the top and try to follow everything. Start with a small feature you would like to tweak, implement, or understand. How does Emacs render the modeline, for example. Just finding the relevant code in the repo will give you some info. Read through it, follow its calls and the data structures it touches. Getting used to the code style might take a bit. You probably won't understand or retain everything about how this piece works, but in hacking on it you will naturally brush up against other areas and build up your familiarity with the project practices and larger structure. And you can use that as a stepping stone to check out another area of functionality.
Except text editors _need_ other people's solutions to learn from, because text editing is one of those cases where "a good implementation for a part of the problem" is a terrible solution for the full problem. Editing implementation for single lines of text do not work well at all for entire text files. Operations become incredibly slow, which is why we invented things like rope data structures and buffered views.
Editing implementation for single lines of text do not work well at all for entire text files. Operations become incredibly slow, which is why we invented things like rope data structures and buffered views.
memmove() is about 100 gigabytes a second on my computer. That's 100 megabytes every single msec. My screen refreshes at about 100hz. None of my source code files are even 1 megabyte let alone 100 megabytes, so at least on my computer, for all of the files I edit, there isn't a single operation that a "rope" or a "buffered view" could offer over the naive because I could literally just rewrite the entire file in C 100 times every keystroke, and I think for many operations it is obvious how to do better.
For this reason and others I think it's absolutely plausible for a beginner to self-teach themselves how to write a good text editor and even improve on things, and I would never want to discourage someone from a discovery they have both the interest and the time for.
None of my source code files are even 1 megabyte let alone 100 megabytes
Source code, sure. Log files and other kinds of text can routinely can be quite large. Also, within the context of source code, colorization and other useful features can be far less expensive if you only have to reapply them to limited section of the current file.
The process of incremental building things. Figure out what needs to be built first and then implement it. Finally compare your work with others. To be frank I used to feel that there must be some sort of deep intellectual concepts lying around, and whatever I try or implement is just dumb. But now after what you described the process and technique seems not so complicated.
Comments
I have a different suggestion. Start with a single line. define an api for move, insert and delete. figure out how to display this line, associate the cursor with the current position and how to map keystrokes to these simple functions. Add commands to load/save this one line file. Also some convenience functions (move to star/end of a line etc). Add simple search, search and replace. Next extend this to as many lines as you can display on your screen. Add more commands. Add commands to operate on a sequence of lines. Next allow arbitrary number of lines, and arbitrary length lines (now you can see only a rectangular slice of the file). Add commands to move that window, move lines around etc. Resist the urge to micro optimize or do so early. Just use the simplest data structures that help you write the clearest code. Later you can profile the code and fix slow parts.
I suggest this as it will force you to solve problems yourself as opposed reading about other people’s solutions. Basically learn by doing. Learn by struggling to come up with solutions and data structures, thereby developing some insight. The stepwise development should help focus on a small subset of problems at a time. Don’t be afraid of changing data structures as you gain knowledge. In fact write code to make it easy! Use a language that won’t trip you up in low level issues such as memory management. The api will make testing easier. Armed with this knowledge you’ll better appreciate and understand other people’s solutions as well!
Similar suggestion: if you're trying to learn the architecture of a big established project like Vim or Emacs, don't start at the top and try to follow everything. Start with a small feature you would like to tweak, implement, or understand. How does Emacs render the modeline, for example. Just finding the relevant code in the repo will give you some info. Read through it, follow its calls and the data structures it touches. Getting used to the code style might take a bit. You probably won't understand or retain everything about how this piece works, but in hacking on it you will naturally brush up against other areas and build up your familiarity with the project practices and larger structure. And you can use that as a stepping stone to check out another area of functionality.
Except text editors _need_ other people's solutions to learn from, because text editing is one of those cases where "a good implementation for a part of the problem" is a terrible solution for the full problem. Editing implementation for single lines of text do not work well at all for entire text files. Operations become incredibly slow, which is why we invented things like rope data structures and buffered views.
memmove() is about 100 gigabytes a second on my computer. That's 100 megabytes every single msec. My screen refreshes at about 100hz. None of my source code files are even 1 megabyte let alone 100 megabytes, so at least on my computer, for all of the files I edit, there isn't a single operation that a "rope" or a "buffered view" could offer over the naive because I could literally just rewrite the entire file in C 100 times every keystroke, and I think for many operations it is obvious how to do better.
For this reason and others I think it's absolutely plausible for a beginner to self-teach themselves how to write a good text editor and even improve on things, and I would never want to discourage someone from a discovery they have both the interest and the time for.
Source code, sure. Log files and other kinds of text can routinely can be quite large. Also, within the context of source code, colorization and other useful features can be far less expensive if you only have to reapply them to limited section of the current file.
Does DRAM even support speeds that high? I thought DDR4 goes to like 25 GB/s. Are you measuring cache speed?
bad editors hang on large files.
Others hang on large files without a newline in the first 100MB.
You don't just need to memmove, you need to put that data into a structure that can be edited.
I really appreciate your thoughts.
The process of incremental building things. Figure out what needs to be built first and then implement it. Finally compare your work with others. To be frank I used to feel that there must be some sort of deep intellectual concepts lying around, and whatever I try or implement is just dumb. But now after what you described the process and technique seems not so complicated.
Yeah its good advice. All Architectures are build like this. Inkrementally.