[dimitar]

I think Emacs still does all of this; the argument the author makes is that it is "arcane", it just uses conventions he is not used to. It is however fully self-documented and interactive.

For me the best textual interface I've ever used remains Magit in Emacs: https://magit.vc/ I wish more of Emacs was like it.

I actually use emacs as my git clients even when I'm using a different IDE for whatever reason.

[brucehoult]

The thing is that emacs predates Apple developing cmd-z/x/c/v and Microsoft copying Apple in Windows. Before that, the most commonly copied keystrokes in programmer's editors were the freaking Wordstar ones e.g. in all the Borland products.

Also OP apparently has no knowledge of the far better IDEs we had 30-40 years ago including but not limited to:

- Apple MPW, 1986. GUI editor where every window is (potentially) a Unix-like shell, running commands if you hit Enter (or cmd-Return) instead of Return. Also the shell scripting has commands for manipulating windows, running editing actions inside them etc. Kind of like elisp but with shell syntax. There's an integrated source code management system called Projector. If you type a command name, with or without arguments and switches, and then hit option-Return then it pops up a "Commando" window with a GUI with checkboxes and menus etc for all options for that command, with anything you'd already typed already filled out. It was easy to set up Commando for your own programs too.

- Apple Dylan, 1992-1995. Incredible Lisp/Smalltalk-like IDE for Apple's Dylan language

- THINK Pascal and C, 1986. The Pascal version was orginaly an interpreter, I think written for Apple, but then became a lightning-fast compiler, similar to Borland on CP/M and MS-DOS but better (and GUI). The C IDE later became a Symantec product.

- Metrowerks Codewarrior, 1993. Ex THINK/Symantec people starting a Mac IDE from scratch, incorporating first Metrowerks' M68000 compilers for the Amiga, then a new PowerPC back end. Great IDE, great compilers -- the first anywhere to compile Stepanov's STL with zero overhead -- and with a groundbreaking application framework called PowerPlant that heavily leaned on new C++ features. It was THE PowerPC development environment, especially after Symantec's buggy PoS version 6.

- Macintosh Allegro Common Lisp (later dropped the "Allegro"), 1987. A great Mac IDE. A great Lisp compiler and environment. Combined in one place. It was expensive but allowed amazing productivity in custom native Mac application development, far ahead of the Pascal / C / C++ environments. Absolutely perfect for consultants.

Really, it is absolutely incredible how slick and sophisticated a lot of these were, developed on 8 MHz to 33 or 40 MHz M68000s with from 2-4 MB RAM up to maybe 16-32 MB. (A lot of the Mac II line (and SE/30) theoretically supported 128 MB RAM, but no one could afford that much even once big enough SIMs were were available.)

[Narishma]

All your example are in the Apple ecosystem. Depending on where the author is from, it may not be that surprising that they wouldn't know about them. In my corner of the wolrd, Apple was basically non-existent until the iPod and iPhone.

[int_19h]

> Before that, the most commonly copied keystrokes in programmer's editors were the freaking Wordstar ones e.g. in all the Borland products.

Borland switched to https://en.wikipedia.org/wiki/IBM_Common_User_Access shortcuts in the last few versions of their TUI - Ctrl+Ins, Shift+Ins, Shift+Del for clipboard, for example. Since Windows also supported them (and still does!) this actually made for a nice common system between Turbo Vision TUI apps and actual GUI in Windows.

[jsrcout]

From my own experience, Think Pascal was fantastic for the time. MPW was serious and high-powered stuff for pro development on a late 80s/early 90s microcomputer; used it professionally for 2 or 3 years and loved it. Never tried the other ones you mentioned.

As you say, it's incredible how slick and sophisticated those systems were, given the hardware of the day. I mean sure current IDEs may be preferable but we're also using 4 Ghz systems these days instead of 40 Mhz or whatever.

[versteegen]

(Edit:) Let me start by thanking you, I love these stories about the glory days of computing generations past! I really must try some of these; obviously there are so many fantastic ideas to take.

Irrelevant aside: I've been using emacs 20 years but I very recently gave up and mapped ctrl-V to paste because I still made the mistake of hitting that too often. (I don't hit ctrl-C accidentally, because to select text I've already switched to emacs for at least a few seconds.)

[bigstrat2003]

> It is however fully self-documented and interactive.

Unfortunately not true. I've fired up emacs once or twice, and couldn't even figure out how to save a document because it didn't show me how to do that. It might be more documented than vi (but that bar is *on the floor, vi has one of the most discovery-hostile user interfaces ever made), but it's not self-documented enough to just pick up and use with no instruction.

[SoftTalker]

I'm pretty sure that if you have an unmodified install and no .emacs that is configured otherwise, when you start emacs you are prompted with a help screen that includes instructions on using the built-in tutorial. If you do that, you'll learn the basics in about 10-15 minutes. If you skip that, yeah it's pretty different from most other software conventions.

[prmoustache]

vi is documented

Problem is most people start it the first time by providing a text file instead of firing it on its own and be greeted by the tutorial. I guess that is because they are blindly following another tutorial instead of trying to understand what they are doing.

My opinion is that "self documentation", "Getting started" pages and "tutorials" is a disease. People would actually get up to speed quicker by reading real manuals instead. They are just lured into thinking they will learn faster with tutorials because they get their first concrete results quicker but at this stage the harsh reality is thay they still usually don't know anything.

First time I used vi, I just had my operating system manual on my desk and I quickly learned to open man pages in a separate tty.

[krs_]

That's a fair criticism, although once you learn how to access the documentation and where to look for/expext it I find that most things, including add-on packages and whatnot, can be learned from within Emacs itself just fine. But it does take some knowledge to get to that point in the first place for sure.

[jjav]

>it's not self-documented enough to just pick up and use with no instruction.

If they just plop you in front of a 3-d printer never having seen one and having no documentation, it'll probably take you a good while to produce something useful with it.

All good tools require training & experience.

[lproven]

> couldn't even figure out how to save a document

100% this.

It is (counts on fingers) 43 years since I got my first computer of my own, and I've been using Unix-like OSes since just 6 years later in 1988... So, 37 years?

Still, even now, Emacs is this bizarre thing that teleported in from 1962 or something. Older than Unix, older than -- well, anything else still used by almost anyone except Cobol and Fortran.

I am old, starting to think about retirement, and Emacs is weird and clunky and ugly. It uses weird nonstandard names for things like "files" and "windows" and even the keys on your keyboard.

I know they are native and natural for the fans. I'm not one. I'm a fan of the great era of UI standardisation that happened at the end of the 1980s and start of the 1990s.

I wish someone would do a distro of Emacs with ErgoEmacs built in, on by default, and which could pick up the keyboard layout from the OS.

ErgoEmacs is a brave attempt to yank Emacs into the 1990s but you need to know Emacs to use it, so it's not enough.

https://ergoemacs.github.io/

[someNameIG]

I'm pretty sure the built in tutorial shows you how to save a document.

[tiberious726]

In unconfigured emacs, you can literally just go Buffer>Save in the toolbar. If you didn't know to look in the buffer menu, then you didn't read even a little bit of the tutorial that appears when you open it

[dapperdrake]

Magit is mind blowing.

How did the magit guy or people even come up with the data model? Always had the feeling that it went beyond the git data model. And git porcelain is just a pile of shards.

[BeetleB]

> How did the magit guy or people even come up with the data model?

It's not all that different from a typical TUI interface.

Magit isn't great because of the interface. It's great because the alternative (plain git) has such a crappy interface. Contrast principle and all.

[nobleach]

For reference, I did use Magit for my short stint with Emacs (and then Spacemacs/Doom Emacs). I've always been more into Vim. I tried the Atom editor several years ago with lots of Vim emulation and quite a bit of customization - one of those being a Magit clone.

I moved to NeoVim many years ago and have been using NeoGit (a supposed Magit clone) the entire time. It's good but I'm missing the "mind blowing" part. I'd love to learn more though! What features are you using that you consider amazing?

[kelvinjps10]

I don't know but I didn't find as intuitive as lazygit

[layer8]

To navigate a Turbo-Vision-style IDE and explore its functionality, you basically only need to know how the Alt and Tab keys work (okay, and Return and Esc and arrow keys), as alluded to in TFA. Emacs doesn’t quite have that base level of operating uniformity I think.

[JoelMcCracken]

To navigate emacs, you really only need to know ctrl, alt, and the basic norms of keyboard usage (return for newline/accept, shift for capitals)

Really, compared to what I see here, the chief difficulty with emacs is the sheer volume of possible commands, and the heterogeneity of their names and patterns, which I believe is all a result of its development history. But the basics are just as you describe.

[skydhash]

The base input of emacs is ‘M-x’. From there, any command is accessible. And you have ‘M-:’ for evaluating any bit of elisp code. There’s a few UI concepts to learn (frame, window, buffers, point, mark, region,…), but that would fit in a single sheet of paper.

[jmmv]

> it just uses conventions he is not used to

I think that after 25+ years of usage, I'm "used to it" by now.

[1313ed01]

Agree about Emacs, and I used it already in MS-DOS back in the day. You could launch the compiler (or make, more likely) using M-x compile or use C-z to open command.com to run commands on the prompt and then exit from that back to Emacs. Almost like multitasking!

I never really liked any of the typical late-MS-DOS era TUI applications and have no nostalgia for those. I think a small TUI like a OS installer is fine, but I realised it is the command-line I like. Launching into a TUI is not much different from opening a GUI, and both break out of the flow of just typing commands on a prompt. I use DOSbox and FreeDOS all the time, but I almost never spend time in any of the TUI applications.

Despite that, I am currently working on a DOS application running in 40x25 CGA text mode. I guess technically it is a TUI, but at least it does not look much like a typical TUI.

[cmrdporcupine]

So, I have been using emacs on and off for 32 years at this point, and I my emacs all set up with eglot and rustic and magit and the like and it's great.. but I still find I just fall back to RustRover when doing development because (unlike some the classic TUI IDEs mentioned in TFA) it just never feels like it's fully glued together and it's always a bit fragile and I never remember how to do certain things -- even though I'm the one who set it up.

That and lack of a decent visual debugger situation.

So I have this weird thing where I use emacs for interactive git rebasing, writing commit messages, editing text files and munging text... and then RustRover for everything else.

It's sorta like the saying, "I wish I was the person my dogs think I am"... "I wish emacs was actually the thing that I think it is" ?

[frou_dh]

There is a good IDE-style debugger available for Emacs these days: https://github.com/svaante/dape

Since it has no dependencies, I wouldn't be surprised if it gets merged into Emacs core at some point.

[creddit]

The Magit experience is due to the use of the transient package for its UI.

Some other packages also use it. Most notably for my personal usage is the gptel package.

[tarsius]

> The Magit experience is due to the use of the transient package for its UI.

(I'm the author of Magit and Transient. (Though not the original author of Magit.))

The transient menus certainly play an important role but I think other characteristics are equally important.

A few years ago I tried to provide an abstract overview of Magit's "interface concepts": https://emacsair.me/2017/09/01/the-magical-git-interface/. (If it sounds a bit like a sales pitch, that's because it is; I wrote it for the Kickstarter campain.)

[dimitar]

Indeed! I went back just to mention it owes its incredible UX to the transient package, I am going to look up more uses for it. Do recommend more if you can, please!

[pkal]

Transient is the worst part about Magit IMO (the best parts are how you can prepare a commit to just include the right changes, or the functionality bound inside the transient menus that make complex operations such as fixups or rebases trivial). Transient UIs are consistently uncomfortable to work with, and could usually be replaced by just using a regular special-mode keymap in a custom buffer. The fact that Transient hooks into the MVC and breaks elementary navigation such as using isearch or switching around buffers has irritated me ever since Magit adopted the new interface.

The real neat thing about Emacs' text interface is that it is just text that you can consistently manipulate and interact with. It is precisely the fact that I can isearch, use Occur write out a region to a file, diff two buffers, use find-file-at-point, etc. that makes it so interesting to me at least.

A far more interesting example than Magit is the compile buffer (from M-x compile): This is just a regular text buffer with a specific major mode that highlights compiler errors so that you can follow them to the referenced files (thereby relegating line-numbers to an implementation detail that you don't have to show the user at all times). But you can also save the buffer, with the output from whatever the command was onto disk. If you then decide to re-open the buffer again at whatever point, it still all looks just as highlighted as before (where the point is not that it just uses color for it's own sake, but to semantically highlight what different parts of the buffer signify) and you can even just press "g" -- the conventional "revert" key -- to run the compile job again, with the same command as you ran the last time. This works because all the state is syntactically present in the file (from the file local variable that indicates the major mode to the error messages that Emacs can recognize), and doesn't have to be stored outside of the file in in-memory data structures that are lost when you close Emacs/reboot your system. The same applies to grepping btw, as M-x grep uses a major mode that inherits the compile-mode.

[rbanffy]

> it just uses conventions he is not used to.

It just came up with conventions few others adopted later when they reinvented the wheel.

[pjmlp]

Back in the day I had to use XEmacs as it was more advanced as plain Emacs.

After IDEs finally started being a common thing in UNIX systems, I left Emacs behind back to IDEs.

Still I have almost a decade where Emacs variants and vi were the only option, ignoring stuff like joe, nano, ed, even more limited.

[speed_spread]

It's not about being arcane, it's about the lack of discoverability. Emacs and vi don't have (by default) affordances like a menu that enables a user to discover and learn the interface at their own pace. The learning curve is much smoother and allows for casual uses without having to pull a book each time.

[kickingvegas]

FWIW, I started a project last year to build Transient menus for major Emacs modes called “Casual” to address discoverability. Interested readers can find more info about it here: https://kickingvegas.github.io/casual/

[tmtvl]

Emacs does have a menu by default. It's one of the things I appreciate most about it (especially the Help menu) and I'm always befuddled to see frameworks like Doom Emacs or Spacemacs disable the menubar.

[saint_yossarian]

Vim does have a menu system, and AFAIK it's still enabled by default in GUIs like GVim.

[thdhhghgbhy]

Love Magit, it is a work of art. I moved to vim a few years back and miss magit dearly. The most feature complete Neovim magit clone is buggy.

[bowsamic]

Magit is really great, however, it can definitely be quite slow and buggy sometimes

[Syntonicles]

I've been using Magit for years, and have never noticed any bugs.

The interface is unique and takes a lot of getting used to. I did need to leverage my extensive experience with Git and Emacs to understand unexpected behaviour but the fault always lay with me.

Given the implications of bugs in such a critical part of a developer's workflow, can you be more specific?

[badsectoracula]

> it just uses conventions he is not used to

...and everyone else, including everyone who is also using a GUI on Linux - even if they use the GUI version of Emacs.

[jama211]

Yeah, basically when they said that it should’ve begged the question “why is he not used to those conventions?” And the answer would be because the conventions it uses aren’t used by anything else (which means they can barely be called conventions), and makes no effort to adopt any conventions of the platform it’s running on even just to get you started.

Also, another user said it has a tutorial when opened which should teach the basics in “10 to 15 min” but I have a feeling I would need 0 minutes to learn the basics of turbo c++.

I get that there are diehard eMacs and vim fans and honestly I’m happy for them. But at the end of the day scientifically speaking ease of use is not JUST down to familiarity alone. You can objectively measure this stuff and some things are just harder to use than others even with preloaded info.

[cmrdporcupine]

and frankly including other emacs users, too.

Any non-trivial use of emacs ends up involving a pile of customizations.