31–40 of 276 posts
If you are interested in small Lua-based text editors, I advise you to take a look at Textadept: https://foicica.com/textadept/ . Specifically as to minimalism: "Relentlessly optimized for speed and minimalism over the years, the editor consists of less than 2000 lines of C code and less than 4000 lines of Lua code." I believe this is a limit that the editor's author self-imposed and keeps to it with an impressive st…
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?
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.
So there's no GUI toolkit? Everything is drawn with Simple DirectMedia Layer?
I wrote a short article detailing the technique here: https://rxi.github.io/200402.html
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?
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…
Fast and small is how they all start out. Feature complete and fast, now that is impressive.
Earlier quoted context omitted.
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…
how are "usability, integration with favorite programming language, extensibility" subjective? these all seem like very objective features.
Earlier quoted context omitted.
it seems to compile/run fine for me on catalina but everything is absolutely huge (hidpi compatibility issues?)
Same here; font is huge on catalina. It seems like this is the culprit: static double get_scale(void) { float dpi; SDL_GetDisplayDPI(0, NULL, &dpi, NULL); #if _WIN32 return dpi / 96.0; #elif __APPLE__ return dpi / 72.0; #else return 1.0; #endif } I found changing it to dpi / 192.0 to be fairly comfortable. It wouldn't be too hard to add a scale option and change to `return (dpi * scale) / 192.0`. The "right way" is p…
There should be a separate feature to handle higher-resolution screens.
Anyway, it feels really easy to change anything in this editor.
Earlier quoted context omitted.
how are "usability, integration with favorite programming language, extensibility" subjective? these all seem like very objective features.
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.
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.