What features does your editor have that other editors cannot provide? Seems like it would be easier to grab one of more popular editors and script/write a custom plug-in to suit your needs.
That was my starting point, and I changed because it wasn't easier.
I switched because my Emacs config was thousands of lines of code to try to wrangle it to do what I wanted. My editor is ~3.5k lines of code and is closer to things how I want them. It's spartan, and you and most other people would hate it. That's fine - I have no interest in writing a general-purpose editor.
Writing a good general-purpose editor is immensely hard, but writing a small editor for yourself is not.
I could absolutely manage to squeeze everything I want into any open-source editor and many proprietary ones via extensions, but there's no value in that to me when I can write less code and get something that's exactly adapted to my workflow.
For starters, I use a tiling window manager, and there are no editors that are designed with that in mind. That doesn't mean they work badly with them, but that e.g. they spent a lot of code on window and tab/frame management that my window manager is already doing the way I want it, and so just by making my editor client-server (a few dozen lines of code with Ruby via DrB), I got that "for free": When I split a view in two, I use the API of my window manager to halve the size of the actual top level window and insert a new editor instance that observes the same buffer. I could retrofit that on other editors too, but doing it from scratch means the "split a view in two" code in my editor is about a dozen lines of code.
Another example is that for my novels, the syntax highlighting dynamically adapts to highlight things I've taken notes about (e.g. characters, locations). I could do that with another editor too, but having full control over the way the rendering layer works meant it was trivial to have my custom workflow control the lexing.
My advice is to start small, and look at some simple examples. E.g. I knew I wanted mine to run in a terminal, and I love Ruby, so I started with Femto which is a really tiny Ruby editor. By itself, it's pretty useless (but beautifully written), but it was remarkably quick to get to something that was "tolerable" for light editing, and then I iterated from there.
There are many options for small ones for all kinds of different values of "small" that can serve as inspiration. E.g. Linus Torvalds has his own branch of MicroEmacs (as do many others, it's a popular starting point, and the basis for e.g. Pico, mg, Vile). Antirez (of Redis fame) has Kilo, so named because it was written to be <1k lines excluding comments, and there's an "instruction booklet" on how to write one that's using Kilo to demonstrate approaches to writing one.
The first starting point, I think is deciding how general you want it to be. E.g. I early on decided I don't care at all about being able to use it as my only editor ever, and that meant I could pick and choose use-cases that were out of scope. For example, I just want to edit "human-scale" files, not multi-GB datasets or log files - I'm happy to open that in Emacs if I ever need it - and so that gave me far more flexibility in terms of data structures because I don't need it to scale beyond a few thousand lines, and that saved me a lot of effort.
What features does your editor have that other editors cannot provide? Seems like it would be easier to grab one of more popular editors and script/write a custom plug-in to suit your needs.
That was my starting point, and I changed because it wasn't easier.
I switched because my Emacs config was thousands of lines of code to try to wrangle it to do what I wanted. My editor is ~3.5k lines of code and is closer to things how I want them. It's spartan, and you and most other people would hate it. That's fine - I have no interest in writing a general-purpose editor.
Writing a good general-purpose editor is immensely hard, but writing a small editor for yourself is not.
I could absolutely manage to squeeze everything I want into any open-source editor and many proprietary ones via extensions, but there's no value in that to me when I can write less code and get something that's exactly adapted to my workflow.
For starters, I use a tiling window manager, and there are no editors that are designed with that in mind. That doesn't mean they work badly with them, but that e.g. they spent a lot of code on window and tab/frame management that my window manager is already doing the way I want it, and so just by making my editor client-server (a few dozen lines of code with Ruby via DrB), I got that "for free": When I split a view in two, I use the API of my window manager to halve the size of the actual top level window and insert a new editor instance that observes the same buffer. I could retrofit that on other editors too, but doing it from scratch means the "split a view in two" code in my editor is about a dozen lines of code.
Another example is that for my novels, the syntax highlighting dynamically adapts to highlight things I've taken notes about (e.g. characters, locations). I could do that with another editor too, but having full control over the way the rendering layer works meant it was trivial to have my custom workflow control the lexing.
Okay, now I want to write my own editor.
Thanks for the inspiration.
Do it. It's fun.
My advice is to start small, and look at some simple examples. E.g. I knew I wanted mine to run in a terminal, and I love Ruby, so I started with Femto which is a really tiny Ruby editor. By itself, it's pretty useless (but beautifully written), but it was remarkably quick to get to something that was "tolerable" for light editing, and then I iterated from there.
There are many options for small ones for all kinds of different values of "small" that can serve as inspiration. E.g. Linus Torvalds has his own branch of MicroEmacs (as do many others, it's a popular starting point, and the basis for e.g. Pico, mg, Vile). Antirez (of Redis fame) has Kilo, so named because it was written to be <1k lines excluding comments, and there's an "instruction booklet" on how to write one that's using Kilo to demonstrate approaches to writing one.
The first starting point, I think is deciding how general you want it to be. E.g. I early on decided I don't care at all about being able to use it as my only editor ever, and that meant I could pick and choose use-cases that were out of scope. For example, I just want to edit "human-scale" files, not multi-GB datasets or log files - I'm happy to open that in Emacs if I ever need it - and so that gave me far more flexibility in terms of data structures because I don't need it to scale beyond a few thousand lines, and that saved me a lot of effort.
Thanks for the tips! Especially the one about "human-scale" files.