If you want a TUI text editor with CTRL-C/V and mouse support, I'd recommend looking at micro: https://github.com/zyedidia/micro

For quick editing, my go to is vim. It’s a real superpower to have if you’re confined to the terminal. However, in the modern post-AI/vibe coding days with super fast AI completions and agentic editing, I think GUIs are the way to go. They make the constant context switching more seamless. Whereas terminal editors work best for very focused zen coding. That’s just my opinion.

I think Claude Code + vim might be a better solution. You’re using the best tool for the job - Claude Code for agentic assistance and vim for editing + review.

Do you have any opinions about Claude Code vs Aider?

https://www.github.com/marssaxman/ozette/

I didn't care about mouse support, though.

* https://mastodon.social/@cks/114704709419805125

https://en.wikipedia.org/wiki/PC-Write

I must have written a million lines of code with PC-Write in the 80's .. seems kind of odd to me that it has just disappeared into oblivion, given that its an extremely powerful editor.

Huh, the source is out there somewhere .. might be a fun Lazarus/Free Pascal project one of these days ..

druthers pl (plural only)

(US, informal, often humorous) Wishes, preferences.

Microsoft hasn't designed a new text editor to "avoid VIM memes". It has re-implemented its old EDIT editor, which was a DOS program with a PIF on Windows NT, and which came out with MS-DOS 5 in 1991. There weren't silly "VIM memes" in 1991. Indeed, Stevie had barely turned into VIM in 1991.

The original announcement was discussed on Hacker News about a month ago.

* https://news.ycombinator.com/item?id=44031529

And the idea that "Windows devs are forced to fire up Notepad" is just risible. Even by 1991 there was a wide array of text editors available in the Microsoft world. EDIT was over half a decade late to the party. DR-DOS had had EDITOR for a while. And if memory serves E and T2 were already in IBM's PC-DOS and OS/2.

* https://news.ycombinator.com/item?id=44041533

It was pointed out back in 1991 that it was late to the party. Quite how someone from the world of Ubuntu can think that there are no text editors in the Windows world in 2025 apart from Notepad and so developers are "forced", its word, to use it, boggles the mind.

* https://news.ycombinator.com/item?id=44037559

Anyone who actually does Windows development, and has probably discussed with other developers the merits of the various editors available, from MobaEdit through EditPad, WordPad, Brief, CodeWriter, and many others to Notepad++, would question the apparently zero knowledge that has informed this piece.

By 1994 when I was first using vi, (not vim) the rather faded "cheat sheet" I was handed already had remarks about the need to teach beginners how to leave the editor. I think I went years writing :q! which isn't the fastest way out but does do what I meant.

I think that’s a joke

In particular the fact that Ctrl + anything letter-oriented makes something that is word-oriented instead, for example Ctrl + Left Arrow and Ctrl + Right Arrow let you skip word-by-word in documents, and Ctrl + Backspace lets you delete entire words at a time. This feels like it should be way more common knowledge than it is, like how copying and pasting any multiline document into your browser's URL bar will almost certainly format it into a sane single-line format.

Considering the hotkeys for xut and vaste, I think it's safe to say the mnemonic accounts for zero of the decision and the keyboard location accounts for all of it.

I find it extremely useful, GUI or not. Too bad it doesn't work half the time when it matters, especially on Windows.

Alt+F4 on Windows has the undesirable property that if you hit it several times, and it works, you'll close several different things. Ctrl-C in the terminal won't do this.

Win+c/win+v looks like a good compromise, using the Windows button for OS/DE commands, instead of application commands.

I miss Sun keyboards and their dedicated copy/paste keys.

> The original computer terminals and microcomputers for which WordStar was developed, many running the CP/M operating system, did not have function keys or cursor control keys (arrow keys, Page Up/Page Down). WordStar used sequences of alphabetic keys combined with the "Control" key, which on keyboards of the time was conveniently next to the letter A in the position now usually occupied by the Caps Lock key. For touch typists, in addition, reaching the function and cursor keys generally requires them to take their fingers off the "home keys" with consequent loss of typing rhythm.

[1]: https://www.wikiwand.com/en/articles/Wordstar

:)=

It quickly morphed into ^C, but the first few months were interesting.

Coming from the VAX, it was ^T.

Of course in the Mac you have the same shortcut in every app because you use cmd+c/v

It really bugged me that by default you use ctrl+shift+c/v on Linux but only in the terminal.

Found a lovely feature in kitty term that does the right thing for ctrl+c depending on if you have text selection or not. Works great for me.

You have these same shortcuts in bash, zsh, the python repl, html form fields, etc. And anything that doesn't use gnu readline can be wrapped in rlwrap.

Note that copying and pasting is an exception. Otherwise, navigating words with shortcuts seems to fairly universally use these shortcuts.

And the logic of what Ctrl/CMD/Shift keys do together looks very random, no logic in it. Like, Ctrl+Left in Zsh scrolls the entire log to top, rather than move the cursor to the start of the line.

I use zsh, slack, Chromium, SublimeText and Zed on Mac.

I guess I've also that useless "right click menu" keyboard button that's not even worth repurposing for anything due to the placement making it incredibly awkward to use. I'd be curious to know if anyone here actually uses the ctrl or alt keys that are located on the right.

As for the right ctrl, by association with the AltGr, I usually map it as the Compose key.

You must be located in the US, because the US is probably the only keyboard layout with a right Alt key. All the others have an AltGr key in that position.

I use the right Ctrl key in combination with the arrow, Backspace and Delete keys. Also with Return to enter the same content in multiple cells in Excel.

I use the right control keys, I use Ctrl+Ins/Del, I use "Context menu" key, when it's available. And hey, I have almost a 30 years of muscle memory for them, so when some another idiot replaces the right Ctrl with F23 (which even can't be remapped by default AND pops up the stupidest menu for selecting what F23 should do) I really what to punch him in the face.

NB: as someone up in the thread mentions, right Ctrl is extremely useful for navigating in the text.

For those unfamiliar with the compose key it is a superior input mechanism for rare characters that maps a mnemonic sequence to the character in question. you want an ø type compose o /

A tutorial if you do not have a compose key configured, I tend to run a minimal bare bones X11 setup, A more full featured environment may have it's own way of doing it.

map the compose key in ~/.xsession

    xmodmap -e 'keysym Menu = Multi_key'

    include "%L" #include the compose file found in /usr/X11R6/share/X11/locale/<localemapping>/Compose
    <Multi_key> <w> <e> <b> : "" # spiderweb
    <Multi_key> <c> <c> <c> <p> : "\xe2\x98\xad" #symbol representing proletarian solidarity between agricultural and industrial workers

I don't know if the compose system is found any where else but I regard it as one of the better things to come out of the X11 project. A little below select / middle click paste.

Although these days, chances are good that some things will not be accessible at all, because many devs these days just don't care to do even the basics like submitting dialogs on Enter properly. Historically, though, Windows at least was very thorough in making sure that everything GUI could be operated entirely from keyboard. Much of that is still there, just increasingly obscure - e.g. few people know that Alt+Space will open the same menu that you can get by clicking the window icon in the title bar (the one with Maximize, Minimize, Move, Size etc). Even fewer know that when you pick Move or Size from that menu, you can use the arrow keys to move and resize the window.

I get freaked out enough seeing devs that can't touch type. Now you're telling me there's a large number that also don't know the copy/paste shortcuts!?

If instead you need to navigate somewhere you don't exactly know the location of, scanning and clicking is faster.

Then again, if you happen to know the exact location, going there by command is much faster

I'll take good keyboard controls for pretty much anything else though.

Search is better especially with code. I used emacs and vim more than other editors, so I got use to their navigation shortcut. And on macOS, the trackpad is nice and convenient. But I still prefer search and paging shortcuts when I need to scroll.

Skipping forward 3 words on the line, for example, could be ctrl+right ×3.

I can do that faster than I can move my hand from the keyboard to the mouse, let alone drag it around.

Hey, that's me :)

Out of curiosity, why is this a yardstick for SW developers? I assumed the more valuable skill of the profession would be critical thinking not finger dexterity on pressing buttons without looking. That's why I didn't become a secretary or court stenographer.

I mean, a lot of doctors can't hand write for shit, but is that in anyway relevant to being a good doctor?

What about SW devs with handicaps or mobility issues?

Touch typing feels like a pretty niche hill to die on.

Programming isn't bottlenecked by how fast you can enter or type text, it is about focusing and thinking and then solving a problem. In other words, being able to enter text faster does not imply also being able to solve a problem faster.

I would even say that on the contrary, taking longer and reflecting on what you are typing more may perhaps result in a better quality solution of the problem being solved.

Unless you are thinking slower than you are typing, you should invest in learning a basic and very easy skill

Plus, writing code is not the only kind of typing that I expect a developer to do. Even if I could accept that typing speed is not important for writing code, it's certainly important for writing documentation, good commit messages, communication with team mates and stakeholders, etc.

In other words, the only thing I think about is what to write, not how I do it.

I move my hands around as I type, too. I learned piano before typing, and it’s weird to me to try and keep them in one place. I type as fast as I’d ever want or need to, though, so I couldn’t care less if it’s not “proper”. I’d still say you and I both touch type.

There is no way back. Relaxed posture, no UI elements stealing my focus unnoticed, parallelism (partially): continually "big-picturing" text; speaking with people while typing. The rhythm of this motoric skill and his quite specific form of memory alone, strangely decoupled from and coupled to the other mental processes at the same time, the interplay is simply marvelous.

I wouldn't link it to competency as a dev.

Our main output is typed code.

Yes, our most valuable skill is critical thinking. So I don’t want to waste time and thought on wondering where the “f” key is. If I’m thinking about typing, I’m not thinking about the problem.

Pretty sure my main output (at least by volume) is text files detailing things such as requirements, implementation strategies, and algorithmic tradeoffs.

It’s an invaluable skill not just for developers, but for anyone whose job requires frequent typing.

It is sort of nice to turning your laptop screen red and dim, and code on a dark porch at night (OLED screen required to get real darkness). Just you, the vim, and some fireflies. Your eyes will adjust to the darkness, and maybe you’ll see some animals that you don’t normally see.

"I can touch type" == "I spend enough time writing things on the computer every day that I have invested in the fluidity and comfort of my own hands" == "I'm enough of a nerd to actually be good at my job".

But it's also worth it from an ergonomics standpoint. I learned to touch type over the space of a few weeks of practice, meant years ago, and it's the reason I can use a split ortho keyboard today, which is much nicer on my wrists than the alternatives. I can also keep a notebook between the two keyboard halves which is much nicer to scribble on than having it to the side somewhere.

That's exactly why I don't touch type.

Forcing my hands in the optimal "home-row" positioning for touch typing gives me wrist pain. Moving my hands towards my most comfortable position disables the ability to touch type.

>It's a signaling mechanism more than anything, as you can see from the other responses here.

Firstly, what if that type of signaling is flawed and might even be discriminatory if applied to screening people for an actual job, especially that SW devs conder themselves highly liberal and open minded to diversity.

Secondly, I also can't fathom how keeping my eyes focused on one screen continuously for long periods is healthy for them versus exercising them having to occasionally refocus towards the keyboard and back.

Thirdly, even if I would touch type, my job needs me to take my eyes of the "IDE screen" occasionally to look at other things like datasheets, PCBs, notes, etc. Then the amount of distractions in the office far outpace any supposed efficiency gains from not having to take my eyes off the screen, so there's no benefit to it anyway as the job has many other bottlenecks.

Reading the comments on this thread, makes me feel like I'm watching that scene from American Psycho where they're all in their bubble flaunting and judging each others' business card designs when they're all the same design. Glad I don't work with such judgmental individuals who scrutinize such pointless details like the way you type, as if their way is the only right way. Must be a nightmare.

>"I'm enough of a nerd to actually be good at my job".

Well then, I guess I'm lucky to be good at my engineering job without the way I type being an issue.

The nice thing about touch type is to not think about typing. One quick glance to position your hands on the home row (there’s helper on F and J), and then whatever you want to write just flow out. While I use two thumbs to type this on mobile, I’m mostly using my peripheral vision. Typing on a real keyboard is better as I have better feedback and can use all my fingers.

It’s only one reason: No need to think about typing, it’s all muscle memory.

Also signals are heuristics and thus important because it's impossible to evaluate everything from first principles every time.

Touch typing means not looking at the keyboard while typing, not not-thinking about typing.

>What did you think it meant?

What do YOU think it means?

Can't you not touch type while still not thinking about typing?

Am I the only human capable of doing an activity while not thinking about it?

I chose to reply to you while addressing the rest of the comments since yours distills them, so it makes sense to reply to all in one comment than to each individually. Apologies for the misunderstanding.

What if I told you that touch typing means you could do that while you are typing.

In my college, if you couldn't type 40 WPM, you didn't graduate.

When I was 29, I got very bad RSI in my right wrist, and re-evaluated my whole computing life as a result: switched to dvorak, removed the mouse/touchpad in favor of keyboard-centric tools, and swapped to a trackball when the pointer was needed. I also learned to touch type.

Of all the changes I made, I think the one with the most lasting value was touch typing. I didn't want to learn it, but I just bit the bullet, and I'm glad I did. It makes doing everything else on the computer very fluid and comfortable. It sounds like the touch typing position doesn't work for you, but the core point is that being able to effortlessly interface with the machine while your eyes can do something else is empowering.

I bothered writing this because I spent decades both before and after learning to touch type, so I feel I have some perspective on how they compare.

I tend to use win+space, which instead toggles the input method you're using, as opposed to toggling how the pinyin input method interprets your input. But I had to learn about this secret special functionality of shift, because (some time ago; I don't know if it's still true) after switching your input method with world of warcraft running, the chat UI in the game would become nonresponsive.

After all, who ever heard of wanting to switch between different languages while using a chat interface?

I recall thinking shift was an insane default but it did explain why she used CAPS LOCK to capitalize single characters.

(Though I've also seen one complain that he was used to lowercase and couldn't read text in all caps. Strategies must differ.)

Do you get freaked out the same way seeing professional drivers that don't race? I've never related the speed of typing to the quality of coding (maybe to the quantity, but not a reason for being freaked out).

In any domain where typing is the dominant activity, it would make sense to invest the small effort it takes to learn to touch type, and to learn basic keyboard shortcuts. You don’t have to reach 120 words per minute for the investment to pay off.

I used to be a one or two finger typist. Eventually, I took a touch typing class. For a long while it seemed like a waste of time. I could already type with one or two fingers at 40 words per minute. However, as I became proficient with touch typing, and as my touch typing speed approached my hunt and peck speed I started to realize what a powerful technique it was. I no longer needed to look at the keyboard, and my thoughts more easily flowed into the computer. This was a qualitative difference, not just about speed.

To continue the driving metaphor, IMO a driver who has had some basic driver education, and achieved some basic level of familiarity with the machine, will be a better driver, even if they never go faster than 40 miles an hour.

> as my touch typing speed approached my hunt and peck speed I started to realize what a powerful technique it was. I no longer needed to look at the keyboard

There's no connection between these things. I use two (sometimes three) fingers per hand. Do I need to look at the keyboard? Of course not.

I don't need to look at the keyboard because, when I would sneak downstairs to use the computer at night, I didn't want to turn on the lights.

Didn't know that. I learned the other day that one can paste a password into the URL bar and drag it to a password field on the website that's annoyingly blocking paste (on Firefox at least). Probably a bad idea for security reasons (telemetry?). Just found it surprising. Also noticed many crappy sites that block paste will forget to block Ctrl + insert or Ctrl + Shift + v. I usually don't have this problem because the plugin of my password manager usually works..

You could probably drag it directly from the password manager to the password field, instead of using the URL bar as an intermediate (which indeed is a bad idea as whatever you enter there usually gets sent somewhere).

~/.bashrc:

stty intr ^x

~/.inputrc (at the end):

"\C-v": "" # Unbind Ctrl-V

~/.config/terminator/config (in case anyone happens to be using terminator):

[keybindings]

  copy = <Control>C

  paste = <Control>V

Do you want to be productive on your own snowflake system, or employable?

Ctrl-X, Ctrl-C and Ctrl-V isn’t even part of the IBM CUA specification. CUA places the Cut command at Shift-Del, Copy on Ctrl-Insert, and Paste on Shift-Insert.

I remember the lower left row on the US keyboard was always the first four operations from the nearly-ubiquitous Edit menu since day one.

    Z - Undo 
    X - Cut
    C - Copy
    V - Paste

Early apps frequently also had "Clear" in the Edit menu, which was like Cut except the cleared item didn't go into the system Clipboard

What developer doesn't have these shortcuts memorized? It sounds like you're living in some bizarro world.

But the question is: what developers don't know about the standard keyboard shortcuts for copy and paste? Do they exist in any statistically significant numbers? ("There exists X" is not a very meaningful contribution if the Xs involved are something like 0.01% and are outnumbered by the number of programmers who write all their code on their mobile phone or whose version control strategy is to inscribe all their programs on a Tic Tac or a grain of rice or who think that Commodore 64-inspired homegrown operating systems are specially positioned to reveal the Word of God and offer protection against being pursued and persecuted by the CIA. Or are these some special breed of 9-to-5 darkmatter programmers who aren't going to show up on the radar, anyway?)

Microsoft adopted the X/C/V shortcuts from the Macintosh for Windows 3.0 (replacing Command by Control), in addition to the existing CUA shortcuts (which are still supported and used today).

You mean CMD+C and CMD+V, right?

Making Caps Lock an additional Ctrl, and using Emacs keybindings (supported in nearly every IDE and on many command lines) makes one even more productive, because your hand doesn't have to travel all the way to where the arrow keys are. (A similar thing can be said about Vi keybindings.)

It is a strange phenomenon that many people do not wish to invest a few hours to make their lives easier later on.

As for Caps Lock, some of us have good reasons to have it mapped to something else that needs to be done frequently, e.g. switching keyboard layouts.

Likewise, ALT just sends ESC assuming you're using the standard US keymap.

https://font.subf.dev/en/

https://github.com/subframe7536/maple-font

For example, TUI (text user interface) and CLI (command-line interface) are quite different. "CLI Text Editor" sounds more like someone editing a file using ECHO commands.

This new editor is actually a reimplementation of the classic MS-DOS 5 EDIT program from 1991. At that time, VIM was still very new, so "VIM memes" weren't yet part of the tech landscape.

Before VIM, there was vi. In Usenet posts - about 15 years before Google - people used to add a pithy humorous sentence at the bottom called "tagline" - here is one: "How do you exit vi? Reboot the system."

And Notepad was not the only option for Windows devs. We've had EDIT, DR-DOS EDITOR, Brief, WordPad, EditPad, Notepad++, and more.

:!killall vi

Of course.

For a cli text editor, ed would qualify, right?

It'd still say ed is more of a TUI than CLI, albeit kind of old-school since it doesn't redraw the screen, just continuously show output and let you enter commands. Maybe "REPL" comes closer, because it's not interactive in the typical TUI way.

But as to that, it's slightly different than merely being able to play back a recording of commands. It IS that, but that can be applied in a way that acts more like the examples I said like sed or patch, or expect, where the script can apply some funcion to different inputs, not just playing back a recording. I'm not denying the implimentation, how the job gets done, is technically still just a recording of commands.

They are equally obviously different from the non-interative interface where all input is provided in the command line arguments and other shell syntax (pipes, redirection).

ls is a cli app. bash is an interative app that provides the cli environment in which you use ls.

I fail to see what is gained by trying make the meaning of "cli app" unclear when it definitely has an understood meaning, just because you can technically assemble the same words to mean other things. Sure in certsin contexts where you are speaking more geneticslly and more abstractly like in some research paper you may refer to a wide range of things all as "command line interface". But so what? How does noting that help in this context? (It does not)

Note that the latter is analogous to the notion of how TUI programs provide their own interactive (generally full-screen) interface. When making the distinction between CLI and TUI, it’s the latter that is meant, i.e. is it a line-oriented or screen-oriented interface.

Saying “command-line editor” or “CLI editor” doesn’t imply that the editor commands are necessarily invoked as non-interactive shell commands, as opposed to the editor implementing a CLI of its own.

Technically, every program can serve as a “CLI command”, since you can invoke it with arguments. However, “command-line” and “interface” are generally understood to mean the user interface where the user types commands. When invoking a program with arguments from another program with exec or similar, you don’t call that a CLI.

TUI apps aren't common anymore, which adds to the confusion as a lot of people didn't grow up with them and don't grasp the difference. A TUI app takes control of the terminal and redraws different parts of the screen to present a consistent, non-scrolling experience. If you've ever used a system where your interface was an IBM 3270 emulator (or better, an actual 3270 terminal), that's TUI. vi/vim and non-GUI Emacs are also TUI.

A CLI app just prints its output at the cursor and the output scrolls off the top of the screen as you go. The Bourne, Korn, Bourne Again, and C shells are all CLI, as are most REPLs and the majority of interactive non-GUI UNIX programs (including ed) these days.

We always called them "signatures." They were even stored in a file named .sig.

They were stored separately in a list and there was software that would pick one of them randomly to add to the signature when posting.

I think we also used them in fidonet echomail, but I don't remember for sure.

BBS networks like ILink had tearlines, optional taglines, and mandatory origin lines. FidoNet had tearlines and origin lines because it shared roots and sometimes nodes with the BBS networks; so they were there for compatibility. Usenet mainly had signatures, with all of its equivalents to the other stuff in headers.

* http://ftsc.org/docs/fts-0004.001

  * Origin: any random text (12:34/56.78)

I find it interesting that everyone is using TUI when I've always seen CUI (Character User Interface). I come from a DOS and Windows background, and it seems like TUI comes from the *nix world.

And Notepad was not the only option for Windows devs.

Dr Dobbs and other tech magazines used to have ads for a variety of editors. And linkers, which were the bane of 80s programmers' lives. There was a whole era of programmer-oriented software that seems to have been largely forgotten.

So, technically, if you’re using a TUI in a graphical terminal window within a GUI, you’re strictly speaking not in a CUI, but are emulating a CUI within a GUI. And the CLIs and TUIs are running within that CUI.

Additionally, TUI is either Text or Terminal User Interface. Either way, it seems to be heavily associated with ncurses. As I understand it, ncurses essentially outputs a stream, which includes things like ANSI escape sequences for position and color. By contrast, CUIs like Turbo Pascal wrote directly to video memory.

Or here some usage of the term in 2002 referring to a Turbo Vision or Norton Commander-like interface: https://www.digitalmars.com/d/archives/c++/dos/75.html

The technical means of how the contents of the TUI is established (character stream with special codes, or direct writes to text-mode video buffer) is largely irrelevant for the term. The essential characteristic is that the visual “state space” of the interface is a character matrix, and that the program treats it as such (instead of just unidirectional line-based output).

Maybe you are right that CUI actually doesn’t cover CLI. The Unix System V documentation uses “Character User Interface” for curses-based interfaces (https://books.google.com/books?hl=en&id=idAmAAAAMAAJ). Then CUI and TUI are roughly synonymous, though TUI is the widespread term nowadays.

https://devblogs.microsoft.com/commandline/edit-is-now-open-...

my biggest problem with azure was also the fact that they couldn't stick to industry-standard terminology, but they has to invent their own. it made azure docs tremendously confusing.

* https://news.ycombinator.com/item?id=44310682

Instead of 2 days ago when I actually wrote it. (-:

:wq (sorry, I had to).

ctrl-z

if no ssh, then nano is not a bad option, though i would go with joe (https://joe-editor.sourceforge.io/) which can also show the shortcuts, but much much more powerful, yet it's just a single ~700kbyte exe (or 1.5MB with some optional syntax highlighting grammars and docs)

While (neo)vim doesn't have TRAMP and dired, it has netrw, which does the same stuff (on a basic level). You can do the following to edit a remote file:

vim scp://user@hostname/path-to-file-here

You can also replace user@hostname with an ssh alias you've configured, which makes it easier to work with multihop ssh and different keys and users. One useful usage of the remote editing is to combine it with opening multiple files to compare two files on different machines:

vim -O ~/.config/mpv/mpv.conf scp://htpc/.config/mpv/mpv.conf

To browse a directory instead of a specific file, just put the dir instead of a non-dir file and it will open a filebrowser view where you can then pick a file to open. In the above examples, leave off mpv.conf and you'll then be able to pick either your mpv.conf or input.conf or files related to your mpv scripts.

For example the built-in version control works the same as in a local context.

That's why it's called transparent:

> TRAMP stands for “Transparent Remote (file) Access, Multiple Protocol” — https://www.gnu.org/software/tramp/

it makes a big difference, imho... not as good as plan 9, of course :)

Vim has ex built in - `Q` in normal mode to enter Ex mode, 3-5 command lines will show at the bottom and you can Ex away. I don't know of practical uses, I've only done it for the novelty.

Obligatory: To exit Ex mode use `:vi[sual]` - and that's probably where Vi got its name.

I remember editing the AUTOEXEC.BAT in that thing as well as writing my own BAT files and QBASIC.

MicroEmacs is small and lightweight. I port it to whatever machine I'm using, and it works nicely in a remote tty window. It doesn't need a customization language, as I just change the source code.

Recently, I added color syntax highlighting to it, and support for unicode characters.

https://github.com/DigitalMars/med

why not https://joe-editor.sourceforge.io/ starting via jmacs?

MS-DOS 5 EDIT is actually just a stub which runs QBASIC in editor mode, in which all the BASIC-related features are disabled.

Windows 95 EDIT was different, it actually had BASIC removed from the binary. I don't know if it was a rewrite or if they just deleted (or even #ifdef-ed) out the BASIC parts out of the source code.

QBASIC was basically just a cut-down build of QuickBASIC with some features disabled. The TUI part was provided by the "Character Windows" (aka "Character-Oriented Windows", CW or COW) library, a TUI-mode analog to the Windows 3.x API for DOS TUI apps, it was also used by some other Microsoft products such as Word for DOS. It would be great were Microsoft to open source it (although from what I've heard, significant chunks of this stuff have already been included in various leaks of DOS and Windows source code, but it would be nice to have it publicly available in a completely kosher way)

Huh, I've wondered about the difference for the last 30+ years.

I briefly worked with them.

That said, give me QuickBasic back in the terminal on Windows, Mac, and Linux, and now you’ve got my attention…

There are already open source clones of QuickBasic which provide what you want, plus a whole lot more, such as QB64 and FreeBASIC.

While I'd love it were Microsoft to some day open source QuickBasic/QBasic/PDS/VB for DOS/etc, that would largely be of historical rather than practical benefit.

People do know the technical difference, it's just a shorthand

Sometimes people use CLI to mean something you're literally doing at the shell prompt, and sometimes people use CLI to mean anything that isn't a GUI. And the Venn diagram of those meanings has significant overlap when both of those meanings are contextually valid and the end result of the meaning is functionally identical.

If I say, "instead of Firefox I'm using lynx, a CLI web browser," it's not really so ambiguous what I mean that you're confused. You can do backflips and dodge context to arrive at being confusing, but you really have to cross into disingenuous reading to get there.

The fact that you CAN draw a difference does not actually mean that the author needs to in order to communicate effectively.

Sounds like ed, or edlin for the DOS oldies, to me.

At first I tried really hard to use these tools, since my work laptop runs Windows, but gradually I accepted that no, even the experienced users aren't doing any better, these tools are just worse than the ones I was used to, and so I use a Unix shell and terminals designed to run those shells instead.

There were Windows/ Microsoft tools where I found things to like. C# is at least arguably a better Java for example. But a lot of the things I expected to find had benefits were just disappointing.

Some time during my day I'll forget that because Microsoft's engineers have apparently seen a real Unix but have little or no experience living with one they've decided PRIMARY and CLIPBOARD are the same thing. This is another one of those things like doing MAC and encryption in the wrong order, or not realising you need a new variable (with the same name) for each iteration of your loops, where it makes sense if it's 1975 and this isn't yet common knowledge, but this is 2025, fucking ask someone.

There are more annoyances, but those are the biggest two.

If you want consistency, just use the other one?

Make sure to add

  alias edit=msedit

https://en.wikipedia.org/wiki/EMac

It might have been faster to just write the code they needed vs consult a lawyer and local security person for every crate they wanted to pull in.

I agree with pretty much all of their reasoning.

https://en.wikipedia.org/wiki/MS-DOS_Editor

Edit: just read https://devblogs.microsoft.com/commandline/edit-is-now-open-... and it seems that all 32bit windows versions had edit. I was probably using Windows XP 32 the last time I remember using edit

https://news.ycombinator.com/item?id=44034961

Several years ago the better micro was born then packaged, I’ve used since. It has more features than edit like highlighting, though missing a menu. That’s good enough I think.

In some situations like constrained environments (openwrt) I use nano with CUA keybindings because micro is too big.

Just checked, key bindings are similar but largely wrong... focused on the Function keys.

The first UNIX system I learned on had pico, the editor nano was modeled after. I personally found it intuitive enough, but too simple in the long run. Editors like nano or DOS EDIT are great for light use, but you reach their limitations pretty fast if you do a lot of serious editing.

I mean in VIM you can't even easily exit. I've always had to literally reboot my computer to get out of VIM. One time even that didn't work, so I had to pull the main circuit breaker in my house to get it to quit.

  docker run --platform linux/arm64 \
    -it --rm \
    -v $(pwd):/workspace \
    ghcr.io/simonw/alpine-edit

More notes here: https://simonwillison.net/2025/Jun/21/edit-is-now-open-sourc... - and a new TIL on publishing to the GitHub Container Registry here: https://til.simonwillison.net/github/container-registry

You can also compile directly from source on macOS - instructions here, I've not tried this yet: https://github.com/microsoft/edit/blob/main/README.md#build-...

It also felt like a better way to distribute the tool for other people to use: I don't want to distribute a compiled binary (because in macOS you then need to sign it for other people to use it), but a Docker incantation skips that step.

I'm definitely not a Docker expert, but I've become a huge fan.

  container run -it --rm -v "$(pwd):/workspace" ghcr.io/simonw/alpine-edit

[1] https://github.com/apple/container

Or are you not on a Mac, PC, or Chromebook?

Also surprised you haven't encountered this earlier, given it affects all usage of Alt in the terminal.

Today, it has successors: Midnight Commander (TUI on Linux), FAR Manager (TUI for Windows), Windows Commander (graphical UI, Windows).

Although MC is good tool, I notice something rubs me the wrong way in it, and I rarely use it -- probably, it's the conflict of focuses between a panel and the shell. E.g. you typed something, then tried to move to another folder, hit enter -> MC decides you run the command, hides the panels, lets the system yell at you "no such executable".

https://github.com/elfmz/far2l

Debian even has it in the official repos. It's also on Homebrew.

We're on a slippery slope towards DFW's subsidized time. Year of the depend adult undergarment, here we come.

Thing of all the (wo)man-hours in computing lost due to the slight difference in people finding the modifier key+key (including the slight increase in error rates) and the just having a dedicated Cut/Copy/Paste keys.

It just never made it to the PC or Mac worlds

https://www.reddit.com/r/keyboards/comments/w72hiw/ive_been_...

It was certainly convenient for people learning the ropes. Too bad it died out when chiclet keyboards became the norm.