> A unique property of writing a code editor is that after a very short bootstrapping period, the thing you’re writing will also be the main tool you’re using to write it.<p>I love these types of projects that happened because someone needed it and wanted to, and I loved that they came to us with the project in hand so they didnt have to talk down 100 but-why's like "dude why do you need yet another hobby editor, just use vim/emacs/whatever, i program in $LANG too and use these 37 plugins and 4 keymappings and it all Just Works".<p>I contribute to a popular IDE that I'm sure a lot of you use, and I'm still going to put down my setup and put a week all-in into this just to, if anything, spiritually put something out there, something positive, to validate this person's work. I see value in projects like these, and though it's hard to put into words I hope someone more eloquent echoes this sentiment in a more tangible way. This is great stuff, I wish more people broke the norm and just did-the-thing.<p>> Randomly deleting unit tests may seem like insanity to some of you, and in certain contexts it probably is — but writing your own editor is a particular endeavour, and if you embark on it I encourage you to do whatever feels right to you, refactor as you please, and embrace the chaos. Happy hacking!<p>I wish more people dared to buck the trends. Good on you, Gus.
><i>Don’t worry about breaking things. If the new structuring you’ve thought of is better, get stuck in and change the code. You will introduce bugs this way, but because you’re using the editor every day to write itself, you’ll find them quickly (in fact, almost by definition, you’ll tend to find them more quickly the more important they are) and your policy of always working on whatever needs fixing right now will make sure they’re fixed promptly.</i><p>Solid advice in the early-ish days of any project.<p>It's not like your code was perfect <i>before</i> the refactor - you just hadn't found some of the bugs yet. You will have bugs after too, but now you have more experience and will probably find most of them quickly. Don't get too attached to the maybe-bugs you currently have.<p>Also:<p>><i>When you’ve got a while (true) loop that searches a tree, it’s gonna throw you an infinite loop every now and then.</i><p>A surprisingly effective strategy I've found for development purposes: never have infinite loops.<p>Nothing is <i>actually</i> infinite. You think X might loop 100x? Put a limit of 10,000 ("absurd and impossible"), and crash your debug builds when it happens. With enough of this, you'll get hits, and they're extremely effective at catching pathological cases that you didn't realize could happen. "It's a bit slow" is often too hard to notice.
Writing an editor from scratch is a fun exercise. I've written a few using codemirror, and can recommend the kilo-tutorial[1], which walks you through antirez's kilo editor (a 1000 line editor) and explains each change in steps.<p>[1]: <a href="https://viewsourcecode.org/snaptoken/kilo/" rel="nofollow">https://viewsourcecode.org/snaptoken/kilo/</a>
> Don’t waste time keeping unit tests constantly up-to-date if the code is working. Once the code is both correct and well-factored, feel free to disable or remove the unit tests so they don’t clutter your test runs with errors after subsequent refactorings.<p>Wait, what?! To each their own, but you'll pry my well-maintained collection of unit tests--which describe all _defined behavior_ in my application--from my cold dead fingers, thank you very much.
I’m constantly surprised by the ubiquity of javascript.<p>Of all the languages I would choose for a desktop app, it ranks pretty far down, yet I am clearly in the minority.<p>But I’m not here to show my age or biases - I am genuinely curious. What am I missing that makes JS/node (or is that a redundancy? Is there any other choice than node for JS local development?) such an attractive choice for local development.<p>Over say java / swift / rust for static languages or python / closure / julia for dynamic?
The editor is based on Electron 22.1.0<p><a href="https://gitlab.com/gushogg-blake/edita-release.git" rel="nofollow">https://gitlab.com/gushogg-blake/edita-release.git</a>
>I start most of my algorithms with while (true)<p>That's gonna hurt<p>>When you’ve got a while (true)* loop that searches a tree, it’s gonna throw you an infinite loop every now and then. Fortunately, the more times this happens the better you’ll get at lightweight debugging strategies, and the more familiar you’ll become with the algorithm and the data structures<p>I like your style, kid.
I'm working on a new programming language and every point resonates with me on a spiritual level. One thing that helped me a lot was writing more integration tests at the outer edges of the application, opposed to unit tests of individual modules. Usually the logic doesn't change between rewrites, so keeping a somewhat stable interface keeps me from breaking stuff in between grand rewrites.
I use my own editor as my daily editor, both for code and most other text files. A few observations on the article:<p>> Use it early<p>This was key to me. If you're going to wait until you have a perfect editor to use it, you're better off spending your time on something else, because it'll take a really long time to get there if you ever do.<p>I started working on my editor because I was endlessly tinkering with my emacs config and realised I could write an editor in fewer lines than my config...<p>You need to have a reasonable clear picture of what an MVP looks like to you. But having as a goal to use it early can also drive design.<p>E.g. in my case the first thing I did to enable this was to have the editor serialise all open buffers to JSON and write a dump regularly. If I didn't expect to use the editor until it was stable, I might not have. But I came to like being able to start the editor after a reboot and have all of my buffers as they were.<p>I later also moved the buffers into a separate process using DrB (the editor is in Ruby). Combined that made it near impossible to lose changes as DrB makes the backend near crash proof (exceptions are forwarded to the client), and the checkpoints/dumps deals with the last little piece of risk.<p>The day that was finished, I switched 90%+ of my editing to my own editor even though it was still buggy and lacking in functionality.<p>As a result I as of writing have 2199 open buffers, some dating back a couple of years. I kill some now and again - e.g. if I open a particularly large file, or something sensitive - but by default I just stopped caring as the dump is only 66MB.<p>> If you’re using the code editor to write itself, the most pressing bugs and missing features will make themselves apparent to you for free.<p>This is a big deal with using my own editor. I have a "roadmap" of things I like the idea of, but "what is painful right now" trumps all of it, because I don't have any users (nor do I want any - I'm slowly splitting functionality into gems that I'm happy to deal with issues with, but the github copy of the repo of the editor itself is wildly out of date and heavily dependent on my personal setup, so likely won't even run for anyone else)<p>It also means I can follow the "refactor when it seems like a good idea" advice without caring if the editor is half broken for a while. I have bugs in there that are clear regressions that I'm ok with working around but that I'd never allow myself to commit code for if I was writing this with the expectation of other people using it.
For comparison table in code patterns:<p><a href="https://codepatterns.vercel.app/" rel="nofollow">https://codepatterns.vercel.app/</a><p>There’s one column missing: whether the query is purely syntactic or has semantics as well.<p>In particular, JetBrains allows not only searching for all _expressions_, but also, eg, constrain expressions to be of a specific type, something which isn’t possible with just a parser:<p><a href="https://www.jetbrains.com/help/idea/search-templates.html#type_filter" rel="nofollow">https://www.jetbrains.com/help/idea/search-templates.html#ty...</a>
This reminds me of the time I hacked together an editor in assembly. I’m all for writing “just another xyz”, however after 2 decades of development I’m tired of the infinite amount of todo apps/editors/etc. on the web. I am conflicted though. On the one hand reimplementing something existing is a great way to learn coding, sdk’s, api’s, etc. On the other hand I feel it’s limiting imaginations and I would love to see something new and unique. How many “better mouse traps” do we need.
The CodePatterns piece deserves serious consideration as its own project; it could be the basis for a generic refactoring engine. It would be great to have some kind of refactoring scripting language for e.g. updating clients of your library when you make a breaking change to it. Just include the update script and your clients will have a painless upgrade to the new library version.
Turbo C for dos was written in 2 1/2 months. Now it takes almost 2 years to write a code editor? This is not a ding towards the OP. It is an awareness that something has gone fundamentally wrong with development.<p>vscode and modern IDE now take 1-2 gb of ram for medium projects. What has caused so much resource usage?
Congrats for building something new. I too, am trying to build a note taking app on top of Tauri. I am still extremely early but stories like this keeps me going. Keep up the good work!
I've fantasised idly for some years over building an editor around something very like the AST Mode, so I'm looking forward to trying this out.
So refreshingly pragmatic.<p>Some of these ways of working will be brutally beaten out of you in most dev teams unfortunately, whether they're effective or not.<p>Yay cargo culting!
The code of the editor is in JavaScript and not in TypeScript. Which makes me wonder how hard it goes in terms of regressions when the codebase becomes progressively larger.<p>I love vanilla JavaScript, but I always try to switch to TypeScript if the codebase becomes larger than 100-200 lines of code. Or otherwise I may regret, and I know it too well from previous experiences.
The unit testing section is interesting because I feel like this may not be the perfect approach to them, but it is not a bad method. Too many times I see unit testing being used as the holy grail of debugging and then half of them get ignored because "Oh that's a known issue."
Being in a quibbling mood, and remembering stories of people who would reboot a device using their own drivers and no OS, I object to "ground up".<p>No sand or gallium containing stone was transmogrified in this story.<p>"I wrote a code editor from the ground up. I started with notepad and stopped there."
Anyone got this working on macOS? Out of the box, I get:<p>> App threw an error during load<p>> Error: --start-args argument required to separate command-line args from node/electron paths<p>> at filters (~/progs/edita/build/electron/mainProcess/utils/getArgs.js:13:10)<p>after `npm start`.
I got a kick out of the Agile Manifesto parody on the main page:<p>>><p>- ...<p>- Perfecting smooth and ergonomic interactions over shipping quickly.<p>- Providing rich and configurable features over simplicity or minimalism.<p>- A visually pleasing and quiet interface (over keeping up with design trends).
here a video, where he shows some features: <a href="https://codepatterns.vercel.app/" rel="nofollow">https://codepatterns.vercel.app/</a>