I've overheard Casey(and Jonathan Blow) mention several times throughout their streams about writing a text editor.
I did just that and highly recommend it. It took about 6 months to write. Everything was done from scratch. The buffer handling and text drawing and even the font was handdrawn as well.
LOC is about 25,000 but that's a pittance compared to how many lines that go into writing a game.
It has enough features that I have completely stopped using Visual Studio.
I did just that and highly recommend it. It took about 6 months to write. Everything was done from scratch. The buffer handling and text drawing and even the font was handdrawn as well.
LOC is about 25,000 but that's a pittance compared to how many lines that go into writing a game.
It has enough features that I have completely stopped using Visual Studio.
Awesome! Do you have a demo video anywhere we can check out?
- Casey
- Casey
I thought this post was really insightful (it was written when Atom was announced):
Why Atom Can't Replace Vim
It talks about the "big ideas" that emacs and vi introduced and how the power of composability in vi does not seem to have been understood. I'm a vi user and would love to find something less cryptic but I've never found something that didn't seem completely "nerfed" in comparison (no slam on emacs - it is fine, just not a modern replacement).
Why Atom Can't Replace Vim
It talks about the "big ideas" that emacs and vi introduced and how the power of composability in vi does not seem to have been understood. I'm a vi user and would love to find something less cryptic but I've never found something that didn't seem completely "nerfed" in comparison (no slam on emacs - it is fine, just not a modern replacement).
I would love to see more about it. I feel that windows is in dire need of (more) good text editors. Do you have a link so we can check it out?
I've tried several text editors, but none does have really convinced me. Since Handmade Hero showed me that is not a hard thing to do everthing from scratch I want to program my own editor in C too (I really enjoy the language at the moment). But honestly I have no idea how text editors work, because I have not much programming experience, I've only made games so far.
Has someone good resources how to program a text edior from scratch? It must not be a complete guide, I need just a basis to start with. I have actually some cool ideas I want to experiment with (depend how hard would it be to implement). One of them is to make a very simple API, something like we did with the game and platform layer, so you can easily embed it in your game code and then live editing the source code (and run the compile script) inside the game without leaving fullscreen. So you can just manipulate directly your game while testing it. Similar to the Quake console, but with the full source code. Of course it would only work if you have the awesome dynamic library loading at runtime like what Casey did.
I don't know how complex it would be, but I am motivated enough to try it B)
Has someone good resources how to program a text edior from scratch? It must not be a complete guide, I need just a basis to start with. I have actually some cool ideas I want to experiment with (depend how hard would it be to implement). One of them is to make a very simple API, something like we did with the game and platform layer, so you can easily embed it in your game code and then live editing the source code (and run the compile script) inside the game without leaving fullscreen. So you can just manipulate directly your game while testing it. Similar to the Quake console, but with the full source code. Of course it would only work if you have the awesome dynamic library loading at runtime like what Casey did.
I don't know how complex it would be, but I am motivated enough to try it B)
Sorry about the "can't attach" thing - I think I turned it off when I set up the board so that we wouldn't have to police uploads and so on. I'm not sure why the "attachments" thing still shows up :/
- Casey
- Casey
@Flederfalter,
This probably isn't exactly what you're looking for, but there is an interesting open source project called 'vis' that I stumbled across recently. The goal of vis is to create a fast and lightweight version of a vim-like editor more-or-less from scratch.
Github project: https://github.com/martanne/vis
Mailing list thread: http://lists.suckless.org/dev/1409/23497.html
There is a decent discussion of some of the design considerations in the README of his Github project and lots of design discussion in the mailing list thread.
vim may or may not be your thing, but the vis source code is digestible and small enough to get your head around, and most of the data structures and algorithms are not specific to vim features. The vis motto is "80% of vim's features implemented in roughly 1% of the code". After looking at the mess that the real vim and emacs code bases have become over the years, it'll probably come in well under that 1% mark.
I wouldn't take the vis code as any kind of absolute truth, but it's at least one reasonable implementation in the right spirit of things.
-Jeff
This probably isn't exactly what you're looking for, but there is an interesting open source project called 'vis' that I stumbled across recently. The goal of vis is to create a fast and lightweight version of a vim-like editor more-or-less from scratch.
Github project: https://github.com/martanne/vis
Mailing list thread: http://lists.suckless.org/dev/1409/23497.html
There is a decent discussion of some of the design considerations in the README of his Github project and lots of design discussion in the mailing list thread.
vim may or may not be your thing, but the vis source code is digestible and small enough to get your head around, and most of the data structures and algorithms are not specific to vim features. The vis motto is "80% of vim's features implemented in roughly 1% of the code". After looking at the mess that the real vim and emacs code bases have become over the years, it'll probably come in well under that 1% mark.
I wouldn't take the vis code as any kind of absolute truth, but it's at least one reasonable implementation in the right spirit of things.
-Jeff
I'm actually doing that myself, too! :D Having written Intype (http://inotai.com/intype/) in the past (it's dead now), it's fairly easy for me as I know what to do.
I've spent like a week on it for now. I now have a multiplatform (Mac, Windows, Linux) hardware-accelerated (OpenGL/Direct3D) custom editor, my own text buffer handling and all in a Unicode-savvy manner. Really recommend doing it, it's a lot of fun.
My vision is to have a really simple editor, very close to what Casey's Emacs configuration looks like. Though being a graphic designer I really care about typography and them feels.
However, I'm using Qt, just to speed some things up for the initial working version. Though I found myself skipping a lot of Qt lately.
I'm primarily writing that for myself, but plan to release it fully open-source.
@PickUpType Can we possibly talk somewhere? :)
I've spent like a week on it for now. I now have a multiplatform (Mac, Windows, Linux) hardware-accelerated (OpenGL/Direct3D) custom editor, my own text buffer handling and all in a Unicode-savvy manner. Really recommend doing it, it's a lot of fun.
My vision is to have a really simple editor, very close to what Casey's Emacs configuration looks like. Though being a graphic designer I really care about typography and them feels.
However, I'm using Qt, just to speed some things up for the initial working version. Though I found myself skipping a lot of Qt lately.
I'm primarily writing that for myself, but plan to release it fully open-source.
@PickUpType Can we possibly talk somewhere? :)
Edited by Martin Cohen
on
@Flederfalter Back in the day I was studying source codes of various open source editors (SciTE, jEdit, etc.). It all depends on your requirements, but perhaps following tips will help you get started:
TextBuffer: I usually start with creating a Buffer that does not care about Unicode, it's just a glorified array of characters with methods like insertText(position, text) / removeText(position, length). For text storage you might want to check Rope (http://en.wikipedia.org/wiki/Rope_(data_structure)) or a Gap buffer (http://en.wikipedia.org/wiki/Gap_buffer). I usually have an option to simply replace the buffer storage, though I usually use Gap buffer (mostly because I know it well).
Lines: Then you need to know where the lines start and end and provide functions to access the lines (begin offset, end offset, length, text retrieval, etc.). For that you can use an array that only remembers where the lines end. Update the array inside the insertText/removeText.
Cursor: The cursor (or caret if you want) is simply a position into the buffer. Some editors blend cursor with selection (so the cursor has two positions). Cursor is usually bound to the buffer and provides functions/methods to change the document (Cursor::insertText(char *text, size_t text_length)).
View: You will need means to convert a position (offset) in a document to screen coordinates and vice versa. Plus means to render the text (line-by-line) on the screen. For that you'll need to know the font and the concrete text layout on the screen. Simplest form is to use bitmap/fixed-width fonts with only basic character set (Latin1), so that each character in the buffer maps exactly to one character on the screen, preferably with each character having the same pixel-width.
Input: Simply use platform events/messages to get characters typed, or keys pressed to move the cursor and insert typed text.
Syntax Highlighting: Most "modern" code editors today use TextMate grammars, which is a bunch of regular expressions to match the code and apply colors to it (usually via a theme that works similar to CSS). You don't need that as long as you want only limited amount of languages (preferably only C/C++), few regular expressions or small parsers for strings, comments and numbers should do the trick.
The parsing is usually done line-by-line. When a text on a line text changes, the parser goes character by character on that line and stores the recognized part (either as direct color, or as a general token type) along with their positions and lenghts in an array. That array is later used with rendering to color the code.
TextBuffer: I usually start with creating a Buffer that does not care about Unicode, it's just a glorified array of characters with methods like insertText(position, text) / removeText(position, length). For text storage you might want to check Rope (http://en.wikipedia.org/wiki/Rope_(data_structure)) or a Gap buffer (http://en.wikipedia.org/wiki/Gap_buffer). I usually have an option to simply replace the buffer storage, though I usually use Gap buffer (mostly because I know it well).
Lines: Then you need to know where the lines start and end and provide functions to access the lines (begin offset, end offset, length, text retrieval, etc.). For that you can use an array that only remembers where the lines end. Update the array inside the insertText/removeText.
Cursor: The cursor (or caret if you want) is simply a position into the buffer. Some editors blend cursor with selection (so the cursor has two positions). Cursor is usually bound to the buffer and provides functions/methods to change the document (Cursor::insertText(char *text, size_t text_length)).
View: You will need means to convert a position (offset) in a document to screen coordinates and vice versa. Plus means to render the text (line-by-line) on the screen. For that you'll need to know the font and the concrete text layout on the screen. Simplest form is to use bitmap/fixed-width fonts with only basic character set (Latin1), so that each character in the buffer maps exactly to one character on the screen, preferably with each character having the same pixel-width.
Input: Simply use platform events/messages to get characters typed, or keys pressed to move the cursor and insert typed text.
Syntax Highlighting: Most "modern" code editors today use TextMate grammars, which is a bunch of regular expressions to match the code and apply colors to it (usually via a theme that works similar to CSS). You don't need that as long as you want only limited amount of languages (preferably only C/C++), few regular expressions or small parsers for strings, comments and numbers should do the trick.
The parsing is usually done line-by-line. When a text on a line text changes, the parser goes character by character on that line and stores the recognized part (either as direct color, or as a general token type) along with their positions and lenghts in an array. That array is later used with rendering to color the code.
Important features include Undo/Redo and a Search.
I agree font is very important. I modeled mine after Consolas. It renders like ClearType but has extra contrast and stems lines up perfectly with the grid so no blur. This wouldn't be a problem but my monitor has such a low DPI. You can message me on reddit, same username as here.
I agree font is very important. I modeled mine after Consolas. It renders like ClearType but has extra contrast and stems lines up perfectly with the grid so no blur. This wouldn't be a problem but my monitor has such a low DPI. You can message me on reddit, same username as here.
@itfrombit Yeah, I've seen this project some days ago. It looks indeed interesting, though it is a litte difficult to me to get the idea just by looking at the source code.
@martincohen thanks for your tips. I think I can start with that. Like Casey said: "always do babysteps" :)
But there is one thing I miss to know how I do the font encoding/rendering stuff efficiently. Maybe I just waiting for Casey when he shows more details on the renderer and comes to text rendering. I am still learning to get comfortable with C anyway, so I will continue to follow Handmade Hero and write my super awesome text editor additionally then.
@martincohen thanks for your tips. I think I can start with that. Like Casey said: "always do babysteps" :)
But there is one thing I miss to know how I do the font encoding/rendering stuff efficiently. Maybe I just waiting for Casey when he shows more details on the renderer and comes to text rendering. I am still learning to get comfortable with C anyway, so I will continue to follow Handmade Hero and write my super awesome text editor additionally then.
Maybe not the place to ask, but has anyone thought of (possibly radical) new approaches to editing code?
Random example, what if a text editor acted more like a spreadsheet? What if you could swim your cursor around all the whitespace, not just where there's already spaces? What if you could move text around like you can move selections in an image editor? Dunno, just spitballin here...
BTW, (also maybe not the place to ask but..) has anyone used Light Table? (I haven't myself, just curious if it brings anything new to the table or is just the same ol' thing)
Random example, what if a text editor acted more like a spreadsheet? What if you could swim your cursor around all the whitespace, not just where there's already spaces? What if you could move text around like you can move selections in an image editor? Dunno, just spitballin here...
BTW, (also maybe not the place to ask but..) has anyone used Light Table? (I haven't myself, just curious if it brings anything new to the table or is just the same ol' thing)
I tried LigthTable and it has some interesting features like built-in variable watches and inline evaluation of Clojure, Python and Javascript code. Also you can open browser tab inside editor in case you want to debug Javascript side to side with your code. Other than for those three languages however... I wouldn't say it currently offers much over other editors.
One thing I haven't seen in a text editor yet is the ability to quickly move to the next upper case. There probably is a way to do it and I just haven't figure it out yet, if so it would be great to hear about it. Just annoyed at the fact that I can quickly move to a name like calculateCurrentPosition but if I want to change it to calculateFinalPosition I can't just quickly erase the middle word by using caps as stop points.. then again I might be the only one who thinks this would be useful.