Kinda strange.
Emacs is so inherently keyboard-focused that I fail to see the point of this... nor the need for it?!
Emacs is so inherently keyboard-focused that I fail to see the point of this... nor the need for it?!
This is what makes Emacs more flexible than Vim to the point where there's a very faithful reimplementation of Vim for Emacs. Couldn't do the opposite, even if you wanted to.
This claim seems at least suspect to me. Vim scripting isn't fun, and vim certainly isn't centred around it like emacs is, but it's possible. Usually making this claim would challenge people to solve it themselves, but I suspect that vim users care significantly less about welcoming emacs users into their environment than vice versa.
(Also, the various vim implementations in emacs are almost-but-not-quite there, to the point that I believe really experienced vim users fall into an uncanny valley.)
Emacs out of the box comes with a menu system. This is very good and useful for newcomers because it not only gives a familiar feel, it also helps discovering functionality. However, it is no coincidence that a lot of power-users turn off menu and toolbar, as evidenced e.g. by Steve Yegge's "effective emacs" tips (https://sites.google.com/site/steveyegge2/effective-emacs#it...). Now, not every user is a power-user, there is of course a spectrum, but to me it is fairly clear that the way Emacs is designed, mouse-based usage would be a limiting factor.
Your example of auto-completion is actually a good argument in favor of keyboard use since I cannot think of any other modality where a similar functionality could easily be implemented.
That said, I'm not arguing that keyboard-based interaction is per se superior to any other form of input. But to me, it's undeniable that Emacs is de facto a keyboard-centric editor. And let's not forget the history of the software: it was originally developed when terminal-based interaction was the norm, (wide-spread) use of mice came much later.
Those that take interactive strings, maybe - but for those that take buffer positions or regions, which seems to me like a plurality if not majority, I would love to be able to invoke a command and then click+drag somewhere I want to apply, rather than having to set the point there and pop it back when done.
Or the other way around, select a region, right-click to get a choice of commands that work on regions - this could even be auto-generated by looking at the keymap stack for commands that work on regions.
As for the rest: maybe some of the features are nice to have. I don't really care for tabs, and standard shortcuts are usually a non-issue, since everyone ends up using whatever they prefer ("standard", Emacs, or Vim). In any case, most advanced functions are usually accessed by name, whatever the editor.
The important takeaway is that every Emacs user should acknowledge the fact that the mouse is underutilized. We may not need it, but it's a huge barrier to overcome for new users.
Simple interfaces are especially useful for newcomers, I agree to that point as well. At the same time, most power-users of Emacs do not use the mouse at all. While not everyone aspires (or even should aspire) to become an Emacs power user, the question might be asked at what point it would be wise to switch from mouse-based use to keyboard-based use as you progress? Does it even make sense to first learn an interface you're better off ditching at some point as your expertise raises?
Though, not sure why the mouse-driven features are also wrapped up making shortcuts match VS-Code etc. That makes it a lot less useful.
But it's true that there might be a certain class of users with impediments for which a different input modality setup could be very beneficial. However, note that standard Emacs already provides menus and mouse support, it's just not what is commonly the focus of the editor.
A gui is a nice way to make a lot of functionality discoverable.
But it is easily discoverable ?
I literally just do M-x and can I get a buffer open with _all_ emacs commands and their explanation, and can do a fuzzy search on that, e.g., so if I type "M-x align re" I get only one command highlighted that can just execute "align-regexp".
That's the main thing I like about emacs. I don't have to remember a million shortcuts, just what things are possible, and then I just type a description of what I want to do and hit enter and that's it.
A GUI / having to use the mouse would push me completely out of "the zone".
Emacs tends to have its own names for many concepts, making things even more obtuse.
But yes, to be frank, my productivity in Emacs really took off once I started memorizing things with flashcards. I currently have 603 cards for Emacs (including elisp).
(And telling a newbie that would cause a lot of despair!)[2]
The other thing that really helped is I started using/making hydras.[1] So now when I encounter a new, interesting mode, instead of memorizing lots of command names or keybindings, I just build my own custom menus.
[1] https://github.com/abo-abo/hydra
[2] But it really shouldn't. Emacs, with all its packages, and modes, is like a language with all its libraries, and not just the standard ones. Remembering all the commands/keybindings is akin to expecting someone to know all the APIs in all the libraries. It's OK if you don't. Most people don't.
In emacs I can use "apropos" (i.e. "c-h a") or "c-h v" for example to search for ways to accomplish what I'd like to do.
I just yank into a new buffer, set it to xml mode, "M-x indent" reveals the command to format xml (indent-region or indent-buffer or something like that), enter, yank it back. Done.
In an editor with a gui, I would just go to "Help -> Search" and do pretty much the same, which would reveal the menu item to click to achieve something. I find emacs ido/helm workflow for this much better. Never need to memorize anything.
These helps are also available in the GUI menu bar, for example Help > Describe > List Key Bindings, which also mentions the keybinding `C-h b` to the right of that.
How is discoverability of keybindings lacking?
A GUI also introduces other problems, but the ability to just point at what you want to know more about or do something with has been a cornerstone of discoverability since the introduction of the mouse.
transient-mark-mode just allows you to see what you're selecting. If you don't have it you don't see what's being selected until you release the mouse. You need that more with a mouse than a keyboard.
Yeah, no. It's a modal state, and since Emacs doesn't support modal interfaces directly, it touches tons of separate commands (anything using `region-active-p`) and means it's tremendously difficult to find out all it does!
Many commands change their behavior when Transient Mark mode is
in effect and the mark is active, by acting on the region instead
of their usual default part of the buffer’s text. Examples of
such commands include M-;, M-x flush-lines, M-x keep-lines,
M-%, M-%, M-x ispell, and C-x u.
To see the documentation of commands which are sensitive to the
Transient Mark mode, invoke C-h d and type "transient"
or "mark.*active" at the prompt.
But I'm no expert!
Try explaining "yank-pop" to somebody who's only ever used sublime/vscode.
Use your imagination and build a different editor.
Easily configurable under Linux with xcape, and (iirc) karabiner for Mac. For Wayland there is also a tool.