Since there are a lot of text editors, I'd like to see more detail on the motivations for yet another one. How does this compare to the current top-five open source editors?
The resident memory was 10MB in my windows machine when I ran this. A strong reason for me to use this would be in a low powered device. I want to write markdown in a tiny editor like this. I want to run multiple projects side by side and this is good for that. If I'm a beginner trying do dev on a machine lower than 4G of RAM. So many more examples come to my mind. I'm pretty sure there are more
Also the immediate UI library from the same author is very good and the examples are amazing.
I upgraded to 64 GB of RAM and now my average usage is around ~40% so hopefully I will be able to live with that for some time. Browsers, VSCode and other webapps and Electrons are using crazy amounts of memory. But... RAM is cheap now so who cares. :P It's about time to start telling kids legends about old days where people were using memory leak detectors and analyzers.
Out of curiosity, what's your CPU utilization? Every bloated Electron-based app I've ever seen also happened to consume cycles while sitting there doing nothing. I'm willing to give up my RAM, but not my CPU.
On my GNU / Debian testing 64-bit, with 10 tabs opened it consumed 31 MiB of RAM and my CPU pushed itself to reach 0.75% at its busiest processing during typing.
Right now, I'm editing all the files in a 3kLOC project in neovim, doing completion with an LSP host, in 14.8MB. Keep it going for a few days and you might rack up 40MB. People can keep creating lightweight editors all they like, but you really need to bring more to the table than that when vim already exists.
What would you say are top open source editors one would consider, and by what criteria should one benchmark the comparison?
While subjective criteria are perhaps most important (usability, integration with favorite programming language, extensibility), for technical quality perhaps there can be some meaningful numerical benchmarks. For example, the lag and memory use when opening a many-GB text file and editing the middle of it with syntax highlighting.
Personally, I'm thinking of its comparison to Geany. A wonderful editor but I have a feeling the first difference is it's going to seem real bloated. Time to see.
Second that about Geany. Wonderful editor that i have been using for years - anytime find a new system or need to have 1 editor that will handle any type of file in a civilised manner, then my first install is Geany.
That said looking at the author's main.c this looks really nice as a shell for anyone looking to create a tool with lua scripting. Im going to download and study this one!
Usability is only objective if you use the word in a dictionary sense: "it is possible to use this editor". It is very much subjective in its usual use: how easily it can be used by a certain user to do certain things. Say, to me a text editor without Vim key bindings is not usable. To someone else, Ctrl-C / Ctrl-V bindings may be preferable. 'Usable code editor' and 'usable screenplay editor' are completely different categories, even though both are text editors.
Different approaches to extensibility can exist, all of them good in certain areas. Both Emacs and VS Code are extensible; which approach is better? You'll find different opinions.
You'll need, as a minimum, to specify a language to move "integration with favorite programming language" towards objectivity.
They are subjective in the degree to which they are measurable. How would you measure how well a text editor “integrates with a programming language”? There are many ways to measure this, making any single measurement choice subjective to a degree.
There is absolutely an objective process for identifying criteria and identifying how well it meets those criteria.
First, an open-ended survey among text editor users to identify the features/requirements that matter to them.
Second, tag and categorize those responses into a standardized list of features/requirements.
Third, survey users to determine both the relative importances of those features/requirements, as well as how well each editor meets their needs for each feature/requirement. Both of these can be done using Likert scales, most commonly giving a score between 1 (does not meet needs at all) to 5 (completely meets needs), with intermediate values being "mostly doesn't", "somewhat", and "mostly". Several hundred randomly chosen survey respondents will generally give you the statistical precision you need.
Companies do this all the time. It's bread and butter for many product managers and user researchers, to justify to execs why a particular feature ought to be built rather than other ones (combined with other factors like cost, risk, strategy, etc.).
And there you have it. To answer your specific question, to measure how well a text editor integrates with a programming language, you just ask its users to rate how well it does. Since user opinion is all that matters in the end, that's the objective answer.
When it comes to products, people's average evaluation is the objective answer. Because people's evaluations are what lead to usage, purchase, subscriptions, etc. There is no other "objective" answer.
There's nothing subjective about it. What users think about your product is your product in the marketplace. That's the entire meaning of "the customer is always right".
Satisfying user demand for a capability isn't a mathematics problem where there's some independently objectively right answer.
Also the immediate UI library from the same author is very good and the examples are amazing.
1. https://github.com/rxi/microui
2. https://floooh.github.io/sokol-html5/index.html