Oddly, I think you will make Emacs appealing to users when you start asserting it is appealing to users. Few changes really needed. Just stop intimidating people before they get involved.
> I think you will make Emacs appealing to users when you start asserting it is appealing to users
I've worked with a lot of Emacs fans but everyone describes it as having a hefty learning curve. If you tell people it's appealing and the first experience is unpleasant, all you're going to do is convince them that you aren't a reliable source of advice. I think it would be much better to focus on easing that initial stage and explaining it a powerful tool which requires some up-front investment.
Remember that Emacs is competing with things like Visual Studio Code, Atom, Sublime Text, etc. If you tell people that it's easy they're going to try it, bounce off, and conclude you have no idea what you're talking about. If, instead, you tell them what you like about it more than those others they might find they agree with you.
Speaking as someone that has bounced off the likes of notepad... I think you are overstating the case.
I'm not saying to merely claim it and call it a day. I'm saying claim it while showing people how to use it. Make it a dialog that doesn't begin with, our way is harder. It isn't harder. Just different.
Exactly. Whenever a new developer asks what editor I use, I emphasize that while I use emacs, it has a huge learning curve. It has different conventions than any other text editor, because it predates those conventions.
I would like to understand why vim does not seem to have this problem? I guess as stated below, it's just they way it is marketed. Because the way I see it, emacs is much easier to start out with than vim.
If I start emacs, I can navigate around the text with the arrow keys, the way I would expect from most other text entry systems. Then I can just type stuff. I can click at points in the text to navigate there, just like in notepad or anywhere else.
OTOH in vim it is nothing like that. Nothing is even remotely familiar. Yet there are much more vim users than emacs users. So I don't buy it that the learning curve is the problem.
> I would like to understand why vim does not seem to have this problem?
That’s seriously begging the question — I mean, there’s a pretty popular running joke about quitting vim and it’s been many years since I’ve heard any recommend it as easy to get started with. In the 90s people suggested it due to Emacs hitting memory constraints but most CPUs now have more cache now than those computers had.
I know, people are joking about how it's not usable. But still there are a lot of people using it! So maybe it's not actually an issue for adoption, so I wonder why this argument comes up with emacs then, which, in my opinion, is OOTB not as weird as vim for someone unfamiliar with either of them.
To some degree, I agree. I've been playing with Doom Emacs[1] recently and it has been pretty smooth, the configuration and such more so than my regular Vim setup.
My experience with Emacs has been a steady upward trajectory, gaining understanding and access to functionality. I now use CIDER and TRAMP every working day, and no true equivalent exists for any other editor (though many are catching up to CIDER, due to Clojure being the better lisp!).
The biggest problems with Emacs, to me, are the rendering performance, the lack of sufficient threading, the default keyboard-accessible windowing commands, and Elisp being unergonomic and sad.
The course I'd chart for an ideal Emacs would be rendering with something like Alacritty†, some default windowing commands similar to tmux, and phasing out Elisp in favour of a Clojure dialect; the last bit would help a lot with introducing some basic sources of concurrency.
† Plus smooth scrolling surfaces, since a text editor generally does not have enough surfaces that the memory overhead of tiled surfaces is a serious issue like it is for general-purpose renderers like web browsers.
Many years ago I implemented JEmacs (http://jemacs.sourceforge.net/) - a proof-of-concept (i.e. very incomplete) port of Emacs to the Kawa framework. Kawa is primarily an implementation of a nice if-I-say-it-myself dialect of Scheme compiling to the Java VM, but it can be used to compile other languages - specifically Emacs Lisp. JEmacs is long dead but Kawa (https://www.gnu.org/software/kawa/) is still actively used and maintained. It has a number of niceties and ideas worth checking out.
While elisp has lots of warts and weirdnesses stemming from ages long ago, I find it quite suited for its task as an editor scripting language.
For instance, the global namespace is great to play with and learn commands in the scratch buffer.
Also the custom datastructures and generally the emacs lisp abstractions around editing are a joy to use.
I agree though that the rendering is too old fashioned. I'd love for Emacs to get smooth, animated scrolling instead of that tty-esque line-by-line movement of the text. That really makes it hard to keep track when scrolling throught large documents.
Likely a polar opposite of Clojure, but there is an attempt to add Guile (a Scheme dialect) to Emacs[1] which aims to provides a faster Elisp backend, and support for using Scheme to program Emacs.
At least when I've written elisp, the default datastructures have involved a lot of work to construct and manipulate, and when you do it right, the ones you've chosen for convenience may perform so poorly that you have to go back and change them to get your program to complete in time.
Namespaces for vars and functions being not a language feature is inconvenient. Unless you are using fakespace or intern-symbol (it seems hardly anyone does), every symbol in your program needs to include its namespace information in order to avoid it being accidentally invoked by somebody else, or accidentally convincing somebody that it's part of the base distribution.
In Clojure, it's many little things:
Keywords are callable, allowing you to evaluate a keyword on an associative collection like hash-map, or traverse, in an obvious and intuitive way, into a nested associative structure with the threading macros "->" and "->>".
The default data structures are fast (for what they are) and hard to misuse: unless you ask politely, you are not going to mutate something your function was passed passed without noticing. seq, the interface for sequences (vectors, lists, pairs from an associative structure), pairs well with destructuring in let and macros/syntax that does binding.
Things like 'let' don't use more parentheses than necessary, which has a greater impact on readability than you'd think. The use of vector syntax for bindings rather than list syntax adds a little bit of syntactic texture that makes reading programs more ergonomic.
I think Clojure may not be as unfamiliar as it seems at first to a person who's written other lisps before, but I have yet to meet somebody who prefers the experience of writing Scheme or Common Lisp to Clojure; nor anyone who prefers Elisp to Common Lisp.
I like to tell the story of how secretaries in the 70s learned how to use and customize Multics Emacs with Emacs Lisp; they were told they were simply customizing their editor, not programming it.
That's the really cool thing about Emacs. The only difference between "simple variable settings" and "proper lisp programs" is a difference of scale, not a difference of kind. Variable settings are just as much code as anything else in Emacs.
Indeed. (+ 1 2) is a "proper Lisp program". By having all that power available from the start, users can use as much or as little as they need and shape the tool on the fly as they work with it. It's the difference between an extensible text editor and a completely malleable one.
I tend to agree, too. It is really no worse than any other complex application, and far better documented than most.
An an occasional user of both Excel and Emacs (mainly a vi guy), I waste at least as much time figuring out where "that tool" in Excel went or how to get in to one of the weird graph editing modes as I do with the more obscure Emacs features I use sometimes.
Getting started with Emacs and having basic skills (load, save, cut, copy, paste, search) is WAY faster than with vi. I don't use more than a tiny fraction of emacs's capabilities and likely never will, but the initial part of the learning curve is way easier than it is with something like vi.
But emacs is not against vi. When I taught a class where I started by introducing emacs, the first question I got was how to make it have this color text and that hentai page background.
I generally use aquamacs when I need emacs these days (especially since Catalina no longer includes the terminal-based emacs by default). It offers a lot of customizations through menus for the appearance, not to mention that it supports standard cmd-whatever shortcuts for the basic functionality.
