Considering the code I have up in the next i3 workspace right now, I think it's safe to use the present tense for me with respect to vim -- and with respect to not using syntax highlighting.
My own interpretation here would be most of those programmers wrote a lot of code from scratch, without a ton of library support.
When I think of most of the innovations that came later to text editors, I mainly think of features that make it easier to leverage massive amounts of code written by other people in a collaborative environment. E.g., linters, LSP, autocomplete, version control integration.
Also, perhaps unintuitively, I'd also put window management in that category which is for me the most important text editor feature. I.e., reading and understanding code written by other programmers spread across many files is the most difficult part of my job, therefore window management is the most important feature.
I might even put debugger integration in this category, something I always reach for the debugger for is answering "what is calling this function and with which arguments?"
Just about the only feature I can think of that's not in `ed` and that's not most helpful for collaboration and using libraries is syntax highlighting.
I like the way Emacs/Vim handle window management which work the same in the ways that matter to me:
- Tabs contain splits (as opposed to splits containing tabs like VS Code). This is important because you can "save your place" with several related places in files and be able to perform a complex subtask in a new tab, and then return to where you were in the original tab
- A split can contain any file, or a directory listing (more details in on this http://vimcasts.org/blog/2013/01/oil-and-vinegar-split-windo...). This makes it easy and intuitive to precisely place a file in a specific split, and it also makes it easy to "jump to definition" within a split without opening a new tab/split, which is disruptive.
For example of what this site offers, I found the following web page when looking for a .RTF (Rich Text Format) text editor (in my case, specifically for Linux, and ideally open source):
(Now that I think about it -- in the future, wouldn't it would be great to have a website/database that would contain all software, not just text editors, but the data would be so granular so as to allow searches on such attributes as open source (or not!), LOC, platform, language, program type, subtype, etc., etc. AlternativeTo has some of this, GitHub has some of this, Wikipedia lists have some of this, and of course, this website has some of this -- but for Text Editors only... anyway, just thinking aloud! <g> :-) <g>)
Great to hear someone other than myself is interested in an all software site.
I started working on a site for that in December after getting fed up with the number of times I've looked for a program to do X, not finding it, starting to build it myself, only to stumble across a random HN comment two months later that links to a program that solves the problem better than I ever could.
I'd really like a resource that lets me find this stuff better, so I'm making it.
Of course, if the usual pattern repeats again — sometime in March I'll come across such a site that has already done this and been running for 5 years and we never knew
This used to be freshmeat.net, which rebranded to freecode.org and immediately died. It was an heirarchical directory of software, classified by category, user interface, UI toolkit, license, implementation language, operating system support... I often wonder what happened to that database. It would be a great thing to revive. "I want an ncurses text editor that runs on linux and has a permissive license" or "I want a QT-based email client that runs on Windows and is GPL" or "What Mac OS X software is using GTK these days", all extremely quick and easy to look up.
edit: http://freshcode.club/ is basically the freecode version of the site, revived. Unfortunately, one of the changes late in freshmeat's existence was a removal of the formal categorization heirarchy and a transition to arbitrary 'tagging', which led to almost-identical tags, confusingly conflicting tags, and generally made life slightly harder.
The original site (as with sourceforge) was based on "Trove", which I can barely find mention of these days: https://tuxedo.org/esr/trove/ the post talking about how it was updated for python 1.5 should be taken as an indication that a new start might be needed!
Infrastructure engineer here, but have worn many hats so far. Started using Vim writing web SPA applications, still using it as my main driver for all writing; which is mostly go, shell and terraform.
I want to know what Wim Taymans, Lennart Pottering, and FreeCAD's RealThunder use! There doesn't seem to be many of the big name devs, outside of core low level stuff, talking about editors, unlike guitarists and such who love talking about gear.
My personal editor MySample [1] is an extension the Crystal Edit [2] control. Through the years I have improved the colour coding, added navigation through HTML files (for editing my static website), to also make it possible to open images and added a small scripting language, primarily to manipulate images.
I listened to that but I must have missed that. I remember him saying he uses visual studio & visual studio code and that he tried vi but didn't like it.
yeah, I was hoping that the comprehensive family tree would have listed some editors that were "descended" from aurora, in being explicitly inspired by / trying to clone its architecture and user experience.
"Kuned" missing. Full name "Kunnallistiedon Editori". From 1973, perhaps. For PDP-11 and CP/M. It mostly solved issues regarding "ÄÖÅ"-characters on anglo-made TTY and video terminals. Most functions were the same as in Wordstar.
-- In 1972, 300 municipalities in Finland founded common datacenter named "Kunnallistieto".
Linus Torvalds used a variant of MicroEmacs that is non-extensible and has non-standard keybindings.
Bryan Cantrill used Vim without syntax highlighting.
What this tells me is that what matters is what you write and whether you finish it, not what you write it in.
[1] Past tense because things might have changed.