There was a hint in the previous post where I mentioned I'd be building a lot of the tools that I use from the ground up and since I normally build stuff with my requirements in mind they turn out to be very minimal.
A lot of stuff that I've built is either tied to this website or you can find it on the work page and I was told that in my idea of reinventing the wheel for almost all tools was stupid but also interesting but mostly stupid .
While I agree to that, and you shouldn't be reinventing the wheel when working on production apps for clients , it's okay if you are doing it to learn. I consider myself really lucky that I've got all these resources out there that I can learn from and it actually makes it easier to find better explanation to stuff if the man page or documentation of a certain library or tool isn't well documented.
It won't. You might not be a fan of the minimal approach to things but if you are , you might have another option to choose for when choosing code editors. I still VIM is the best there is but then that's just my opinion.
If someone has observed the pattern of my repositories, you'd notice the things I've built or have forked to go through are for building a code editor. If unclear let me guide you through the mini-tools I've rebuilt.
and the forks include
Obviously no one is that observant but it's been going on for a while. I also wanted to take on building a browser but I'll get to why I didn't later in the post.
The above minitools each have attempts of figuring out how I could abstract each part of the final code editor into modules of its own thus making the final editor a lot more pluggable with various tools and to get a basic understanding of how plugins can be made a lot more scalable.
Apex takes on adding tabspaces etc to an existing textarea on the web which isn't that helpful when you build the editor using something like Go Lang, but I just wanted to see how the syntax highlighter actually worked, and yes, I did go through codemirror and primjs's codebases to see how they were doing it and work on improving where I could.
Mark on the other hand was a failure because I didn't really complete it to the point that I wanted to. I wanted it to be like a wysiwyg editor where the markdown would update as you typed and reflected in the same editing space something like Typora, but I never went ahead with the idea and instead left it out there like every other web based markdown editor. So, technically didn't learn much from it but was still in the right direction so I'm going to give it a break.
Similary, Hen and Snips were experiments to figure out visualisation methods and while doing that I added a Mini playground for react components. Took 2 approaches to make it , one with iframe and one with a contained div , though I think the iframe approach would be a lot more secure but either way, I've got helper code for both now.
It is, yes. That's also the reason why I didn't really try making a browser. Even though there are terminal based options out there that I do like using but, I like the dev tools experience of Firefox and so it's hard for me to actually think about building one right now with a day job.
Building both a browser and a code editor in parallel would get me burnt out in no time but don't worry, there will be a day when I attempt making a browser.
Also, it's going to be slow because
Tip: For people who are expecting to earn via Open Source,
your best bet is to go the Open Core way which a
lot of Open Source purists won't like and the
other one is to offer managed services
while giving away a self hosted solution for free.
Gitlab, SourceHut, Mongo, you get the idea.
Oh there's nothing wrong with the current ones. As I said I like building these things both to learn and to have my own take on something as solution and try to not kill the ram. And to think I was going to build it with Electron was the first mistake but I have a better approach now, it's a very old one but still the best way to go through building desktop tools in my opinion.
The requirements for the editor though,are very minimal and the existing solutions. Atom, VSCode, end up offering a lot more that I'm every going to use. I'm not kidding, I made a post long back about my vscode setup and I've gotten rid of the other themes and only using Min Theme now and don't even have polacode and music time anymore. Also, Sublime and VIM are great alternative and I do use them right now more than I use VSCode. I still want to try building one.
To sum it up, this is all I want
Why don't I use any other plugins? Well basically because I have everything else handled by tools that run when i commit or are setup to run as a github action.
My linters run during commit, formatters run during commit and also as a github action to make sure all files are formatted and not just the ones that were just staged and I sometimes directly edit from Github's web editor so those changes are formatted for me automatically from the action.
Stuff like this doesn't need to be done in realtime because I've been coding for
a long time now and silly mistakes like typos and all are rectified during
testing. You'll still see a lot of typo messages in my commits because I
commit the functionality before I test it and then add fixes as their own
separate commit. I like being verbose about the mistakes I made.
Anyway, building an editor with just the above 2 functionalities should be simple right? Well that's the thing, I tried doing it with Nova with 0 knowledge of how large amounts of text buffers are to be handled and what data structures i was supposed to use and that botched the project before I even started and that's when I went the route of building every module slowly and understanding things I need to learn and think about before going ahead and jumping into building it.
Don't worry, you'll get updates of my progress with it after I'm done with
dark which is the current project I'm working on. Haven't really told anyone
on what's it's going to be but I will once I have an mvp ready for it.
Adios.