I've worked on a text editor last year. The idea was to get to do some IDE like tooling at some point, but that might never happen. I intended to make incremental parsing work but I still haven't got a good approach figured out that wouldn't rely on dry parser theory and code generation.
Anyway, since @seventh-chord asked about text buffers. That text editor can easily handle multi-gigabyte files in-memory since it is supported by a text rope that I did, which is again supported by an RB tree that I did. Small inserts/deletes anywhere in the file, even with 2G of text loaded, take only 5-50 microseconds to complete.
The textrope itself doesn't really have a notion of text but it's just a storage for binary data that can efficiently handle insertions and deletions. The only thing it currently does is count UTF-8 leader bytes and 0x0a bytes. On top of that is a layer for "real" text handling, like movement by codepoints, words, lines, and so on.
If you want to take a look at it, the project is at https://github.com/jstimpfle/astedit. The things I described above are mostly in the files rb3ptr.c (RB tree), textrope.c (storage), and textedit.c / textpositions.c (movement).
(Note, if you want to try it out: it's barely usable, and it has a VIM-like interface. There is no documentation. There is insertion, deletion, selection (with v key), and a really bad undo-redo system. There is a command-mode that you enter with : just like in VIM. It has 'w [FILE]', 'r FILE', and 'g <N>' (goto line) commands. There is not even copy-paste.)
Anyway, since @seventh-chord asked about text buffers. That text editor can easily handle multi-gigabyte files in-memory since it is supported by a text rope that I did, which is again supported by an RB tree that I did. Small inserts/deletes anywhere in the file, even with 2G of text loaded, take only 5-50 microseconds to complete.
The textrope itself doesn't really have a notion of text but it's just a storage for binary data that can efficiently handle insertions and deletions. The only thing it currently does is count UTF-8 leader bytes and 0x0a bytes. On top of that is a layer for "real" text handling, like movement by codepoints, words, lines, and so on.
If you want to take a look at it, the project is at https://github.com/jstimpfle/astedit. The things I described above are mostly in the files rb3ptr.c (RB tree), textrope.c (storage), and textedit.c / textpositions.c (movement).
(Note, if you want to try it out: it's barely usable, and it has a VIM-like interface. There is no documentation. There is insertion, deletion, selection (with v key), and a really bad undo-redo system. There is a command-mode that you enter with : just like in VIM. It has 'w [FILE]', 'r FILE', and 'g <N>' (goto line) commands. There is not even copy-paste.)
Edited by jstimpfle
on
It would be nice if you provided binaries so we can test it without having to compile it. I tested it a little and it crashes often just by pressing key outside of insert mode. The font is far too big in my opinion.
Thank you for your feedback. This project is experimental and coded with a cowboy mentality - I don't do a lot of testing and I'm pushing all commits directly to the master branch, so there can be the occasional unhappy commit. Normally, reliability has been ok and it shouldn't crash. Possibly the crash you experienced (was it just a hang, by coincidence?) is related to missing sound implementation on windows and your key presses generating beeps.
I've made a few changes and I've created a release on Github with precompiled binaries for Linux and Windows. Would you be willing to try again? If there are still problems, please send me a PM describing your platform and what you did - your feedback is very welcome but I didn't intend to hijack this thread.
The font size can now be changed with plus and minus keys in normal mode. Related rant, I've been working on this project with a 4K screen, that's why the font size was set rather large. I'm also working on a 13" laptop with low DPI, but rendering vector fonts with few pixels is really hard, so I hadn't bothered to change the number of pixels used dynamically. I've made an attempt at subpixel rendering, but I must have done sth wrong since the font appears really "colorful". Also I believe subpixel rendering doesn't work very well for light-on-dark text even if implemented correctly. I've even read a comment from someone that complained that the text rendering in 4coder is still not super readable - which leads me to think that I should go back to bitmap fonts for low DPI screens. In fact I've never been able to change my terminal from xterm because bitmap fonts are so much easier on the eyes (and also faster).
I've made a few changes and I've created a release on Github with precompiled binaries for Linux and Windows. Would you be willing to try again? If there are still problems, please send me a PM describing your platform and what you did - your feedback is very welcome but I didn't intend to hijack this thread.
The font size can now be changed with plus and minus keys in normal mode. Related rant, I've been working on this project with a 4K screen, that's why the font size was set rather large. I'm also working on a 13" laptop with low DPI, but rendering vector fonts with few pixels is really hard, so I hadn't bothered to change the number of pixels used dynamically. I've made an attempt at subpixel rendering, but I must have done sth wrong since the font appears really "colorful". Also I believe subpixel rendering doesn't work very well for light-on-dark text even if implemented correctly. I've even read a comment from someone that complained that the text rendering in 4coder is still not super readable - which leads me to think that I should go back to bitmap fonts for low DPI screens. In fact I've never been able to change my terminal from xterm because bitmap fonts are so much easier on the eyes (and also faster).
Just tried out the Windows binary and it seems to work perfectly with no crashes. I also tried compiling the source yesterday, but as soon as I tried to type anything it was crashing.
I'm not familiar with Vim-style editing so I can't do much, but I really like the overall feel of it, the colors and smooth scrolling.
Thank you for releasing your source. You just gave me material to study (as I'm also making a text editor and I'm about to release my source as well), and it's nice to learn from someone who is way more knowledgeable than me!
I'm not familiar with Vim-style editing so I can't do much, but I really like the overall feel of it, the colors and smooth scrolling.
Thank you for releasing your source. You just gave me material to study (as I'm also making a text editor and I'm about to release my source as well), and it's nice to learn from someone who is way more knowledgeable than me!
The binaries you provided worked better (no crash).
A think you might look into is to put the program asleep when nothing is happening. At the moment, it still pushes frames and since I have the window compositor off (on Windows 7) it pushes a lot more than 60 frames per second and I can ear my GPU fan speeding up.
For the font, I'm not an expert but my understanding was that for low DPI screen subpixel rendering (e.g. clear type) should give better results as it "multiplies" the horizontal resolution by 3, and on high DPI screen anti-aliased bitmaps looked better. But I never actually used sub pixel myself, and I don't have a high DPI screen.
Here is an example of sub pixel rendering lcd_ft_text_demo (from CDBG I think).
A think you might look into is to put the program asleep when nothing is happening. At the moment, it still pushes frames and since I have the window compositor off (on Windows 7) it pushes a lot more than 60 frames per second and I can ear my GPU fan speeding up.
For the font, I'm not an expert but my understanding was that for low DPI screen subpixel rendering (e.g. clear type) should give better results as it "multiplies" the horizontal resolution by 3, and on high DPI screen anti-aliased bitmaps looked better. But I never actually used sub pixel myself, and I don't have a high DPI screen.
Here is an example of sub pixel rendering lcd_ft_text_demo (from CDBG I think).
Edited by Simon Anciaux
on
Reason: typo