Also the immediate UI library from the same author is very good and the examples are amazing.
To me this is simply mind-blowing.
(They weren't big files, of course, but still. Standards have slipped.)
Indeed standards have slipped or better say have been sacrificed at the altar of "quantity over quality".
For a simple "Hello, World!" string message, nowadays you need how many MBs of RAM.
Madness, complete madness!
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.
Supposedly editors using ropes are good at this.
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!
I.e. side-panel is too large, find+replace menu is modal and confusing.
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.
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.
In other words, there's no objective product goodness/badness. Only what the customer wants. In that sense, the customer (market) is always right.
Inexperienced restauranteurs often experience the same shock. You don't cook the food you want to make, or that you think people ought to eat -- you cook the food people want to eat. Otherwise you'll go out of business.
It's a bad slogan that only portrays half of the reality of the situation.