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.
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.)
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.
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.
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).
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.
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.
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).
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.
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.
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?
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.
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.
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.
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?
95 comments
[ 3.1 ms ] story [ 161 ms ] thread(Of course everybody knows about Notepad..)
I also fondly remember edit.com, too bad it didnt survive..
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.
More unusually, Win9x doesn't have EDLIN, but it seems the 32-bit versions of NT-based Windows do.
(I, personally, find micro too nano’ish. YMMV.)
Anyway, text editors specifically written for DOS environments integrate rather well with the „classic Windows console“.
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).
Here’s some info about it, and maybe a way to get something that works today
http://www.os2museum.com/wp/microsoft-editor/
Edit: search turns up a free/shareware GUI version, no mention of the 'classic' text-mode one
On Windows, use FAR, not mc. Some aspects of mc I think don't work on Windows (last I tried), and frankly, FAR is significantly more powerful.
My biggest ask on Windows is for a native mosh client. There aren't currently any.
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.
https://joe-editor.sourceforge.io
By the way, there is a free semi-GUI WordStar clone named WordTsar.
Also, it definitely has the best mascot[1]
[0] https://lugaru.com/
[1] https://lugaru.com/pics/changing.gif
One of the very useful features was that it had a multiple resolution selection feature.
https://en.wikipedia.org/wiki/Brief_(text_editor)
(It's mentioned in the article - yay.)
But I use vim/neovim if I'm on a Windows box today. Hasn't happened yet in 2020, though.
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?
However it looks like Windows 98 broke it (according to this message: https://groups.google.com/forum/#!topic/comp.editors/l24T-Wh...)
For anyone brave enough to try random downloaded apps it looks like it is available here: https://winworldpc.com/product/norton-editor/20
When you have Emacs, why use anything else? :)
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?
The Windows PE header contains the LARGEADDRESSAWARE flag which controls the memory available to the executable.
When that flag is off (i.e. the Microsoft recommended default value) the executable only has access to 2 GB of memory.
To access more memory that LARGEADDRESSAWARE PE flag set to on:
https://docs.microsoft.com/en-us/cpp/build/reference/largead...
But in any case, you would think 2 GB is more than enough RAM for most text handling scenarios.