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.

▲

skydhash 16 hours ago | parent | next [-]

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.

▲

layer8 15 hours ago | parent | next [-]

The keys I enumerated are sufficient to discover and execute all available operations in that style of TUI. You don’t have to type commands or command-specific keyboard shortcuts, like you have to in Emacs. It’s analogous to how in a traditional GUI you can discover and execute everything just using the mouse.

Like in the GUI analogy, you can then choose to remember and use the displayed keyboard shortcuts for frequently used operations, but you don’t have to.

	▲	skydhash 15 hours ago \| parent \| next [-]
		It’s easy when you have a small amount of commands. And distributions like Doom Emacs is fairly discoverable too. But emacs have a lot of commands and while it offers menus, it’s only the surface level of what’s available.
	▲	JoelMcCracken 15 hours ago \| parent \| prev [-]
		For most fundamental operations there are menus available. Most heavy emacs users opt to turn them off however. You can even see the menu atop the screen shot in the article, with the familiar names etc.

▲

marssaxman 13 hours ago | parent | prev [-]

It's possible I might once have given emacs a try, if the way people talk about it did not sound like such baffling moon-language: when I encounter stuff like "so I C-x C-f’d into my init.el, M-x eval-buffer’d, then C-c C-c’d an org-babel block before C-x k’ing the scratch buffer" I just want to back away slowly and leave them to it, whatever it is they're doing. Y'all have fun with your C-r X-wing mork-butterfly porg fluffers, I'm going to edit some code over here, using a text editor, that edits text files.

▲

skydhash 10 hours ago | parent [-]

So you don’t ‘git clone’ and ‘git commit’, or ‘mkdir’ and ‘grep’?

	▲	marssaxman 5 hours ago \| parent [-]
		Not following you; how does that question relate?

▲

JoelMcCracken 15 hours ago | parent | prev [-]

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.

▲

layer8 14 hours ago | parent [-]

It’s a good question to what complexity (volume) the approach scales, but dialog boxes can get you quite far, and menus are fundamentally “just” a tree like keyboard shortcuts are.

Emacs has Elisp commands first, then keyboard shortcuts for them, then maybe (not as a rule) menu items, and rarely dialog boxes. The Turbo Vision approach, from its design philosophy, has menus and dialogs first, then keyboard shortcuts for them.

One approach isn’t strictly better than the other, nor are they mutually exclusive. Ideally you’d always have both. My disagreement is with the “I think Emacs still does all of this” above. Emacs is substantially different in its emphasis, presentation, and its use of dialogs.

	▲	JoelMcCracken 10 hours ago \| parent [-]
		Yeah that’s fair. In many ways the spacemacs/doom model is more akin to what you describe, with a lot of caveats; it’s not a total rework of all key bindings. In emacs novice affordances are usually an afterthought, not part of the core design and community norms. Of course, I must say there is a trade off here: you can design for novices or for advanced users, but very often not both.