Wanted: Console Text Editor for Windows | Hacker News Reader

Wanted: Console Text Editor for Windows

virtuallyfun.com

83 pointsrhabarba94 comments

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.

The author tried to use EDIT in the first screenshot at the top

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.

Also, it definitely has the best mascot[1]

[0] https://lugaru.com/

[1] https://lugaru.com/pics/changing.gif

Epsilon seems to be a GUI editor?

I stand corrected: It seems to have both versions included. Still, 250 US$ seem to be obscene.

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?

Must be a Perl thing - even Epsilon’s website is a cgi one.

Brief (by Underware) was "the shit" (awesome) back in the 80s. Even borderless (no chrome).

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.

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.

(Of course everybody knows about Notepad..)

EDLIN has been removed for quite some time, its successor, EDIT.COM, has not survived the let’s-get-rid-of-efficient-software Windows XP era either.

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.

This was so annoying that I built a stand-alone clone of edit using VB for MSDOS. Unfortunately after compiling it was larger than QBASIC :(

I believe EDIT.COM is still there in all 32-bit versions of Windows, but since it's a 16-bit application, none of the 64-bit versions have it.

More unusually, Win9x doesn't have EDLIN, but it seems the 32-bit versions of NT-based Windows do.

That's a shame, I had a happy few minutes remembering assembling binaries via debug.com which was the other way of creating files back then.

I definitely remember windows having some built in terminal editor during Windows XP. Maybe EDIT was removed after then.

EDIT was dropped with 64-bit.

I think EDIT.COM was 16-bit so couldn't survive the 64-bit transition.

I still casually use copy con in windows. Sometimes i forget which is the save shortcut. I think ctrl-z, right?

I also fondly remember edit.com, too bad it didnt survive..

Ctrl+Z would work, or F6.

Nice, i didnt know about f6

To be pedantic ctrl-z inserts an eof, which tells copy to stop reading input from the console.

There is micro (https://micro-editor.github.io). It works great on Mac and I think it works on Windows too.

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 second micro. It has become my default console editor on both Windows and Linux for quick editing tasks.

I had micro as my default text editor on Windows for a while, but it felt like a nano port to me. Not sure why.

Tried it but it felt sluggish. Maybe the lua bits are slowing things down?

Anyone remember Sidekick? It was the first 'terminate and stay resident' program I saw back in the day. Used it as source code editor in DOS. https://en.m.wikipedia.org/wiki/Borland_Sidekick

Borland surely had many editors, it seems.

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.

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

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.

Joe actually has a Windows build - right from their website.

https://joe-editor.sourceforge.io

By the way, there is a free semi-GUI WordStar clone named WordTsar.

> MC overall seems far nicer than FAR

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.

Some of FAR’s best features only work inside ConEmu though. (I think that hasn’t changed in a while.)

A lot of mc's features don't work on Windows. FAR without ConEmu is still better.

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.

Sounds like you know a bit about this, have you tried using the remote-ssh extension for VSCode? If so, how does it compare?

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.

Which operating systems are possible on the remote end?

In short: x86_64 and ARMv7/8 Linux, Windows 10 / server 2016/2019. MacOS Mojave.

In length: https://code.visualstudio.com/docs/remote/ssh

I understand that it’s not a solution for my BSD servers then. Thank you though, I didn’t know about that and I might try it later.

Yes: TRAMP can be a bit slow, but it is very portable.

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).

> where it is available everywhere by default

It is not (anymore), so not even that is clear.

For many people, Vim’s learning curve does not justify its features. Line editors are not for everyone.

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?

On Windows the executable will most likely only have access to 2 GB of memory.

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.

> I also cry a lot about 64-bit Windows builds because I work a lot in WinPE and other environments where syswow64 is not available.

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).

4coder exists (https://4coder.handmade.network/). Quite popular with the "handmade" crowd of folks (Casey Muratori & friends).

My laptops run Windows but I do all my development in Linux VMs via Powershell's built-in SSH client.

My biggest ask on Windows is for a native mosh client. There aren't currently any.

Personally, I'm using mosh inside of WSL using wsltty for the terminal itself. It works well.

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’m not sure whether a JavaScript-based terminal is a good idea.

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.

Emacs runs in Windows consoles. Presumably you start it the usual way, by saying: emacs -nw

When you have Emacs, why use anything else? :)

Even in CUA-mode, Emacs is very unusual in quite a lot of ways in the DOS world. That’s why, I guess.

It's interesting, a shame emacs org-mode is discarded so quickly. If only the barrier of entry weren't so high.

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.

Emacs has a CUA mode to address that specific issue: https://www.gnu.org/software/emacs/manual/html_node/emacs/CU...

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.

The TSE/QEDIT and FTE TUI's look like they were made with Borland's Turbo Vision framework [0].

Oh man, so much retro-computing these days on HN, I love it!

[0] https://en.wikipedia.org/wiki/Turbo_Vision

Microsoft did release a nice editor called M back around the end of the 80s

Here’s some info about it, and maybe a way to get something that works today

http://www.os2museum.com/wp/microsoft-editor/

That guest post was by the same author as the linked post. In fact, the linked post is also present in your link, linked in the first sentence.

The article talks about it, including modern(ish) clones like K.

There was this awesome editor called Kedit that I used on OS/2 and Win NT. I think there were text and GUI versions, but not free.

Edit: search turns up a free/shareware GUI version, no mention of the 'classic' text-mode one

KEDIT, the XEDIT clone? There is a free version of that, The Hessling Editor.

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.)

How about `ee`? https://github.com/herrbischoff/ee

Does it have a Windows version?

(tenox /does/ have a point here.)

Vim works great. Don't see why you'd want to use anything else, except maybe Emacs.

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).

Until recently with Windows Terminal the Windows console app has been garbage. Any text editor would suck using the classic Windows console.

I find the Windows Terminal much inferior to ConEmu.

Anyway, text editors specifically written for DOS environments integrate rather well with the „classic Windows console“.

If you mention HT editor, you also have to mention Hiew. HT is sort of a clone of Hiew.

(2018)

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.

openwatcom vi looks great

It does. If the vi that shipped with Linux distros had that TUI, a lot fewer people would hate vi.

It does indeed! Sad that it doesn’t support UTF-8.

micro works nice under wsl/shell env in windows

Why would you do that as there’s a native micro for Windows?

(I, personally, find micro too nano’ish. YMMV.)

I use Jed.

    scoop install neovim

Reply on news.ycombinator.com