No mention of MS-DOS EDIT which came with Win95 and AFAIK is still there in Windows 10 (32-bit version only)? That would probably be the editor I've used the longest, alongside Notepad and vi. It has a very useful "binary" mode that is somewhat of a cross between a text and hex editor; I've done a lot of binary patching using it.
I used to work with someone whose editor of choice was Epsilon[0]. I've never seen or heard it mentioned anywhere, it never figures in any discussions on technical forums/sites I frequent, but it appears to have a bit of a cult following.
Yeah, it's a hefty price tag. The programmer in question (super experienced Perl-slinger) had been using it so long he knew just about every command and trick, and he'd customised his set up so much he'd locked himself in!
Edit: an excerpt from the website that indicates its age
> Why not settle for the "free" editor that comes with your compiler, or some lesser programmer's editor, or even try to use a word processor to edit your programs?
I had a sudden memory of using edlin, and "COPY CON FILE.TXT", but it has been years since I've used a Windows desktop so I don't know what is available for the console.
Pre-windows 95, EDIT.COM was actually QBASIC.EXE running with the command line switch /EDIT.
Really annoying, as it meant that if you wanted a native TUI editor on an MS-DOS book disk, you had to shoe-horn the larger QBASIC.EXE on to it somehow just to be able to edit config files.
Yeah, for his criteria it seems like a perfect match. He mentions it as the very last one and seems to like it but think it ought to include a file browser... I disagree, though. File browsing is a different beast, and a good file browser would be able to launch micro for editing a file. Likewise you can probably configure micro to use [file browser] for browsing files.
My goto editor in the 80s for DOS and 90s for Windows was Norton Editor. I had it on various diskettes to use when I needed to edit files on customer's computers when I worked in a computer store in college.
Interesting to see The Semware Editor in there. Way back before Windows, I used to use Qedit, the predecessor of TSE, and at the time it blew most other DOS editors out of the water. I believe it is the first shareware software I gladly paid for.
By the time Windows and TSE came along, there were many other choices, but a 64 bit build of TSE might be worth looking into again as a console editor.
My fingers still default to the Wordstar keymap from Borland Pascal/C days, so my daily driver in Linux is Joe - wish there was a Windows build available.
VS Code’s remote ssh extension could help here. It’s basically a “headless vscode” running on the remote instance that your local machine can connect to. (A la. emacs, from what I’ve been told.) The language services and etc. all run on the remote instance, so there isn’t the giant network penalty you get from sshfs or whatever either.
Disclaimer: on team, but not in this area specifically :)
Connecting to a remote emacs client is a bit of a pain. What it does do is handle remote paths via TRAMP: pretty much anything that takes a path (file editing, magit, shell mode, etc) handles ssh automatically.
I've never used VSCode. A cursory look suggests that the VSCode way performs better (in particular, no need to ship files back-and-forth), but depends on the remote end also having VSCode installed. The TRAMP way suffers a bit when dealing with large files, or large numbers of files, but works anywhere ssh + the usual shell utilities does.
We do try to make the remote install easy. It happens behind the scenes on first connect and will even tunnel through the ssh tunnel in cases where proxies/etc. would typically make things annoying.
I respectfully disagree that “learning curve” is a reason not to go with a well established console editor like VIM.
There is a learning curve for everything, including the code and configurations being edited.
I think taking the time to learn tools, like editors, that are available on many platforms saves time in the long run and helps to manage diverse systems more effectively.
Investment in learning something like vi makes sense in the nix world, where it is available everywhere by default. On Windows side the problem is that there's no comprehensive "default editor" to learn.
If you are doing server side sysadmin work on different environments then you might be limited to what is already available. Often you don't want to go through the trouble of getting a specific editor installed in order to edit some config files (3rd party software may require approval, somebody to install it, etc).
The author seems to focus a lot on having 64 bit versions of the editors.
I'm wondering what's the downside of using a 32 bits in the case of a console text editor? I doubt that it's because you could theoretically need to load 4GB+ text files in memory.
Is there a good reason to want a 64 bit version of an editor to the point of excluding it if there isn't one?
I've been using WordPerfect's 'Programmers Editor' since the days of DOS; the C rewrite works for me (on Linux, DOS and Win-whatever), works best with a keyboard with F-keys on the left. It's about a 75Kb executable on Windows (50K stripped on linux).
Have you tried using Fluent Terminal? It is available on github and the Windows Store. To use mosh you need to connect via the quick connect menu in the top left corner of the program.
I haven't done a test yet, but the Fluent Terminal seems fast enough and doesn't eat up that many resources surprisingly. As a UWP program it feels very snappy (as opposed to Hyper being a full on electron app using 200MB for simple text output!) I don't care what technologies they use to build a program, as long as it works. I haven't experienced any hangups using SSH, so it's good enough for me.
I tried a ton of them for a while and the microsoft terminal or wsltty both use the least amount of resources, open the quickest and have the lowest input latency.
The author implies that vi/Vim and an Emacs are the usual suspects here, but they’re rather foreign on Windows and DOS-like environments - which is true. Other editors in the list are - at least, UI/UX-wise - much more common to DOS people.
It still feels rather different than (e.g.) TSE. Don’t misunderstand me, I surely like Emacs and I use it regularly, but the command-line version is a strange thing in a DOS environment.
Yes. I's forgotten its xedit roots. Lots of interactive operations like block editing a subset of lines matched by pattern. And it could edit huge files fast.
I remember using The Boxer, console based editor last century. This was on OS/2, but I seem to recall it was available for Windows too. Not sure though.
There (was and) is a Boxer text editor for Windows, a commercial BRIEF successor. Its developer, Boxer Software, was founded in the early 90s, so it could have had an OS/2 version once.
Nice! I’ll have to check that out! I used BRIEF back in the early 90’s developing plant monitoring/management software. Our products ran on DOS and Windows after that. I’d been using emacs at school, but BRIEF was our editor of choice for this. The column copy and paste is something I still haven’t found as intuitive as BRIEF in any other editor.
GRIEF is an open-source BRIEF clone, it can probably do that. (The article made me try it. I found and reported a few macOS problems, but the Windows version seems to be functional. I might keep it.)
I am quite happy with (Acme and) GNU Emacs as my GUI editors, but Emacs is really annoying to use on a console to me, especially on non-native platforms like Windows. One of the reasons why I like the article.
Thankfully, you don't have to use Emacs on the console. Not even on a Powershell-only Windows system (such systems will let you launch graphical applications just fine).
Even in the article's use-case (remotely editing files on some remote server), Emacs ships with TRAMP, which can be used with PuTTY's plink to do remote editing (assuming the remote host is accessible via SSH): https://www.emacswiki.org/emacs/Tramp_on_Windows
There's also support for TRAMP over SMB, though I haven't personally tried it (usually for SMB I let the OS handle it and then point Emacs at the local representation).
honorable mention, even though you are likely not to run it on a headless windows server, is with a WSL shell you can run any *nix terminal editor and edit windows files just fine.
i noticed he made a 64bit version of fte himself, so i went and got that, and it's great. i didn't even think about a console text editor in windows before. good article.
