No! Emacs does not require the user to learn any code in order to use it.

Unfortunately this is a persistent false narrative to which many new users fall victim (as I believe you have). I maintain several packages aimed at non-coding writers. I put a lot of effort into ensuring that writers never need to write or understand any code in order to get writing.

Emacs has a built-in user-friendly options UI system that provides documentation on every option and its available settings, and provides input error checking. All options are organised hierarchically, or you can search for any options matching a string.

But, there are a lot of programmers out with a desperate need to appear clever. Using the options UI is an affront to their cleverness, so they insist that writing code is the only way. It keeps them feeling clever and it perpetuates this idea that the only way to use Emacs is by learning how to manipulate its internal code.

So we have people sharing their overly complex configuration files. And worse, these horrible "starker kits" that obfuscate the extensive in-built help, and further abstract the program away from the user.

Ignore anyone pushing any of those "starter kits". Ignore anyone who says "just paste this code into your init". They're only trying to appear clever. Anyone trying to appear clever usually isn't.

Edit: here's a video where I set up Emacs from scratch to a full-featured screenwriting program, without a single bit of code: https://www.youtube.com/watch?v=Be1hE_pQL4w

This is the first time in my 29 years of Emacs use that it has occurred to me that someone out there might like M-x customize enough to hold it up as a pro-Emacs argument.

I use it very occasionally in order to discover the name of one of Emacs's thousands of user options, which option I then manipulate with Emacs Lisp code added to a file. I much preferred the (recently completely removed from Gnu Emacs after 2 decades of being marked as deprecated) vastly simpler list-options command for doing that.

For me, easy modification of one's personal software environment by adding Emacs Lisp code to files is the central argument for Emacs and cancels out the negatives such as the fact that, e.g., C-z does not undo the latest editing action.

One of benefits of online discussion of things like editors and programming languages is that it is a constant reminder of the largeness of the diversity in cognitive styles and preferences among people.

I'm actually in-between on this. What I normally do is write short bits of code (generally `use-package' forms) to install and load packages and set options that are essential to the operation of the package, are not private information, and don't vary between my different machines. Then I use `customize-group' to set any remaining options.

Customize could stand improvement in terms of widgets and layout, but it's not bad. Other than a coat of paint, it's pretty similar to VS Code's preferences interface.

I agree that M-x customize is not horrible at what it does.

On reflection, what inspired me to chime in on this thread is amazement that there exists at least one person who is enthusiastic about the fact that Emacs has thousands of customizable settings. (M-x customize exists solely to make persistent and ephemeral changes to those settings.)

At least two. The vast range of customizable settings is one of the main selling points of emacs for me, and I find M-x customize a very pleasant way to discover and tweak them

Anyway brb, I'm off to customize how EXWM assigns workspaces to monitors when I plug my laptop into the docking station.

I don't see it as either/or. I just set `custom-file` to something else to keep options settings out of the way, while I still have plenty (too much) of my own init code.

Emacs would benefit from being easier to get started with? Yes.

Emacs is held back by not being easy enough to extend, because it uses Emacs Lisp? I don't see how. I'd expect learning to write plugins for some application to be harder than figuring out enough syntax/semantics of a language to call library functions.

The fact extensions in other editors are written in Java or TypeScript do not make it any easier to write them.

In any case, learning Lisp is useful, even if you never write an Emacs plugin.

> If I have to read a whole book or learn an entire new programming language, I'm not going to put the time in.

If I actually believe that the time will be well spent, I'm willing to spend it. Having gone through the effort of learning emacs (yes, reading a whole book about it) and forcing myself to use it as my primary editor for a year, I have to say... I don't think it was time well spent. vi, however, was. It was (at least) as hard to learn initially as emacs was, but for most text-editing tasks, it's still a lot faster than any GUI editor both to start up as well as to actually perform text editing tasks. Plus, it's always there, no matter how many jump boxes you've ssh'ed through.

I'm a daily Emacs user, and happily use a 100 line init.el, mostly composed of "enable this mode".

Emacs supports customization needs to the nth degree, but I've found that this is a false economyy.

I agree Emacs needs to be easier to get started with.

You would probably be more productive in VS Code with an empty config.

Emacs fits so nicely into my workflow. I can use it, feature-rich, from terminal, within tmux, and easily switching from the editor (where I write code) to other terminal panes (where I run the code). I can also use Emacs without any mouse input at all, have a rich set of keyboard shortcuts, and where I find myself doing something repetitive, I can easily automate it. While I'm at it, I can use the very same environment for a ton of other things - note-taking, editing more file types than I could care about etc.

I can see that with different priorities, perhaps VS Code might be a better fit. But does it work in the terminal? Can I edit LaTeX and have equations rendered in-place? Can I easily switch layouts from having 3/4 panes of code and nothing else on the screen, to having various other bits around? Does C&P trivially support multiple "buffers" (registers in Emacs lingo; can copy & paste persistently to different places). Can I easily record rich keyboard macros - ones that, dunno, search second and third word on a line, replace first instance of second word with third word, then return to the starting point?

I suspect the answer is yes to some of these questions, but no to most. And this is barely scratching the surface of what Emacs can do.

I think I would be more productive with VS Code too.

But productivity isn't my only goal.

I want to give back to the community: Emacs is introspectable enough that it allows me to easily contribute.

I want to explore a different UI paradigm, which blurs the line between user and developer.

I want to support a grassroots developed editor.

> You would probably be more productive in VS Code with an empty config.

Org mode is the main productivity multiplier. How do I do that in VS Code?

Any time I read a comment where VSCode is the obvious alternative to Emacs, it's a clear sign the commenter knows little of Emacs.

Take a look at last year's EmacsConf and count how many of the talks are about SW development (hint - minority). A very large number of Emacs users do not use it for SW development, and stating they'd be more productive in VS Code is simply false.

I took a look at the EmacsConf talks and didn't see anything in particular that stood out. Mind pointing something out?

At the end of the day, Emacs and VSCode are extensible environments and editors, so there's gonna be a lot of overlap and some fringe cases that are only possible on either one.

But VSCode is definitely the more immediate of the two. I can install VSCode, sign in with my GitHub account, and immediately have my exact same environment as on any other machine. Any change I make to my environment, such as keybindings or installed extensions gets synced to other installations. I can remote into other computers and again have my same environment, developing as if I was on that computer itself. If I see a colleague with a certain behavior, all I usually have to do with VSCode is ask what extension it is, install it, and then I get the same behavior without any configuration (with Emacs, everyone has their own little custom environment). I don't ever need to be writing Emacs Lisp just to use the environment as I would expect to. You simply cannot do all of this with Emacs with the same usability and immediacy. And this alone is why I use VSCode.

I have tried getting into Emacs. At one point, I was on Windows and needed to run MIT Scheme, which doesn't really work on Windows, so I installed and ran MIT Scheme on Windows Subsystem for Linux (WSL). Through some configuration of my .emacs file I was able to get things up and running by using Emacs on Windows and then calling into WSL and Scheme (this is before the days of official GUI support in WSL). It didn't really work in the end, despite all the hackery, one reason being Emacs' terminal is its own little custom thing. So I install VSCode, install the Remote - SSH extension, and I was off and running within minutes developing in a Windows GUI with code running on Linux, as if I was just on the Linux machine. So I never looked back. Any experiment of mine for Emacs meant I spent all this time trying to configure the editor to do what I'd expect rather than doing what I actually wanted to do. With VSCode, I have found that I rarely spend time needing to bend it to my will. It basically does what I need, and if not, there's extensions or simple configurations that accomplish it. I'm almost always working in VSCode and not working on VSCode.

> Any time I read a comment where VSCode is the obvious alternative to Emacs, it's a clear sign the commenter knows little of Emacs.

This is also why people stay away from Emacs.

> I took a look at the EmacsConf talks and didn't see anything in particular that stood out. Mind pointing something out?

That most of the talks are not relevant for SW Development, and VSCode is likely not the correct thing to point existing Emacs users to. Looking at the talks from last year, is VSCode good for:

- Writing novels

- Produce sheet music

- Editing audio files' metadata and tying it to producing a web site.

- All things Org mode

- Roam-like wiki

- Gaming

- Creating fonts support for native American languages

- Reading mail/newsgroups

- Using it as a computer algebra system

- Interacting with external programs like the browser

Note: I do 3-4 of the above regularly.

I honestly have not checked if VSCode can do these things - will be happy to be informed.

Can you elaborate with examples from both emacs and VSCode on why you believe that to be the case?

If you find emacs hard to extend then i hope you never use eclipse, more on that later.

Part of the problem you raise kinda comes from the newfound popularity of emacs, people started more projects on top of emacs and now we have a paradox of choice.

That said emacs core is pretty stable, even though there an acceleration in new ideas there too, it's not breakage inducing.

About ease of extension, in emacs you can add functions, menus, buttons, libs in 15 seconds. That's less time than it takes Eclipse to "create" an empty plugin project.

emacs is not the easiest (or the neatest or any -est) but relatively speaking, it's still a good thing.

When I set out to learn Emacs in the year ~2001 or so, I just did C-h t in order to launch the builtin tutorial. IMHO that can still be a viable way to get started.

Spacemacs might be nice but it’s in no way required in order to be productive with Emacs. My personal .emacs file is only 32 lines long (28 lines of comments are not counted).

If you need a dedicated tutorial for a text editor it's a great sign that something is very wrong with its design, particularly concerning discoverability.

Emacs has no user-friendly command names (you need to memorize function names which are often meaningless abbreviations), no autocomplete, and doesn't show available functions.

Vim has a built-in tutorial too. As said elsewhere, you literally cannot get started in Vim without knowing a dozen command and grokking modes, in Emacs you can at least stumble around without knowing anything.

Equally, there's a difference in target audience. Do you need a tutorial to operate a screwdriver? No. Power drill? Arguably yes. CNC mill? Dear God please yes. I don't think you expect a fork lift or nail gun to be accessible with zero runway by anyone, or for their features to be discoverable by trial-and-error.

You could argue that this is not a worthwhile niche, and maybe that's right (at least for you and like-minded people) but it's just what it is.

> As said elsewhere, you literally cannot get started in Vim without knowing a dozen command and grokking modes

You need i, escape, :w! and !wq. hjkl too if you're feeling fancy. But i, escape, :w! and !wq is all you need to use Vim. I know because I used it like that for two years in college.

Ctrl-z followed by killall -9 vim is how I usually exited vim.

I once pissed off dozens of customers by symlinking vim to emacs on one of our shell servers (back when isps gave you login access to a Linux/Unix box...

(Yes, it wasn't very nice, but it was funny)

> Emacs has [...] no autocomplete, and doesn't show available functions

My impression is that you are not familiar with Emacs.

I have been using emacs for 7 years prior to switching to VS Code. Never looked back. It's better in all regards.

You used emacs for 7 years without learning that it very much has auto-completion, you can see available functions with fuzzy matching, and that you can easily alias any function to any name or key-binding you want instead of memorizing it?

:-O

Could name a single specific feature that somebody who uses emacs for years is missing? (perhaps, a link to a video if it is hard to describe concisely would be useful)

I've tried recently to steal some features from VS Code but nothing fundamental came up. I've discovered the gitlens' git-blame overlay feature but it is cosmetics (I use magit-blame). btw, the feature is available as blamer emacs package (just add the corresponding (use-package) elegant declaration to your .emacs).

I use tramp to run remote commands using Org-babel all of the time. Obviously, emacs can edit remote files just fine too. What am I missing?

Sorry for misunderstanding. I see now that you meant autocompletion like LSP (rather than M-x minibuffer completion). Emacs could benefit from built-in LSP, I agree.

Emacs-devel are keen for it, and eglot.el is a good contender for inclusion.

> I have been using emacs for 7 years prior to switching to VS Code.

Based on what you've been claiming I doubt that.

Emacs has user friendly command names, functions in Emacs have a full command name. Can you guess what "comment-region" does? That's right it comments out the currently selected region. Or "switch-to-buffer"? That's right, it's used to switch buffers. Obviously if you use these things regularly typing all that gets tedious so you can use keyboard shortcuts like C-x-b to switch buffers instead. Sometimes these have relation to the command they call but sometimes they don't, but neither does something like Ctrl-Z (What does Z have to do with undo?).

Emacs doesn't have autocomplete built in but it does have tab completion and if you press tab it will show you possible functions that start with what you typed if there is more than 1 option available.

I think most of the trouble people have with Emacs is that it doesn't use standard terminology or conventions mainly do to its age. There is nothing more discoverable about Ctrl-Z vs. Ctrl-/ other than that Ctrl-Z became the defacto standard. If you took two novice computer users that have never used a computer in their life I think they would have just as much trouble with VS code as Emacs.

Emacs was founded in the 1970s. There is a lot of legacy in there, but IMHO it still holds up as a very powerful and nice text editor.

“If you need a dedicated tutorial for a text editor it's a great sign that something is very wrong with its design, particularly concerning discoverability.”

I don’t agree. If it was a mass-market product for users who just wants something convenient, then I would agree. Those users are probably better served by other applications. (Word, Evernote, OneNote, Notepad++ etc etc) But Emacs is a power tool for power user. Therefore I think it’s okay that it needs a tutorial to get started. You need to invest some time to learn in. That will, in my experience, pay off greatly in the long run.

Let’s take an example from another domain:

Suppose someone wants to get started with 3D Graphics. I’m pretty sure software like Blender and Maya also needs some kind of tutorial in order to be useful.

There already exists better power tools for power users, that are easy to use and easy to customize, yet still more powerful than Emacs. It's a common misconception that if it's arbitrarily hard to understand, it must be something for power users. Bad design is not a feature.

>There already exists better power tools for power users, that are easy to use and easy to customize, yet still more powerful than Emacs.

And what tools would that be?

You need dedicated tutorials, or equivalents, for all complicated tools and machinery. The power of Emacs (with respect to text editing capabilities) comes from mastering, by committing to muscle memory, a large number of key sequences. There's no easy way to do this- it takes time and effort (100% worth the payoff imo).

That's some kind of protestant work ethic. It doesn't need to require days of busywork to be powerful. VS Code is more powerful, easier to configure, and more productive out of the box. The default feature VS Code offers make hundreds of lines of Emacs configs with dozens of custom plugins look laughable. Tramp mode is pure trash compared to remote editing in vs code. Stuff like syntax highlighting, intellisense, git integration, and other useful features are years ahead of Emacs too. Every language, including C, is supported better.

I'm keen to hear more about VS Code's remote editing strengths over TRAMP.

What is it in particular?

I see some UI operations block on TRAMP operations which is laggy and annoying.

Yes, it takes work, it's like learning how to dance, draw, or paint. My emacs config is literally 64183 lines of elisp + 2356 snippets (just checked), so I'm not really considering a major editor switch at this point.

I've used VS code as well, it's fine for what it does and certainly much more beginner friendly.

Imagine what you could have accomplished if you didn't have to spend all that time writing an entire large codebase just to make it usable. It's a false assumption that it should require pointless busywork to be useful. You're never getting back the time you've wasted on writing a config for an obsolete editor.

I love writing elisp, obviously! It wasn't some drudgery for me, it was the whole reason I even got into coding (from using R in emacs) in the first place.

I got into a habit (obsession?) of automating as much as possible everything I repetitively do on a computer by writing elisp. It's essentially my operating system.

ESS is truly a gateway drug.

> Imagine what you could have accomplished if you didn't have to spend all that time writing an entire large codebase just to make it usable. It's a false assumption that it should require pointless busywork to be useful. You're never getting back the time you've wasted on writing a config for an obsolete editor.

Isn't this precisely the kind of "protestant work ethic" that you mentioned just before? If someone enjoys writing ELisp for Emacs, what's wrong with writing 61k lines of it?

This is kind of an odd attitude. I haven't used VS Code, but I have used PyCharm extensively before. There's a) so many buttons everywhere, with hovertext that doesn't help unless you already know what you're doing, and b) so many things buried in random configuration screens.

I recently started using Doom Emacs and really like it. There's a learning curve, but in contrast to what you're asserting, every other IDE has at least a similar learning curve. Unless by "text editor" you mean no IDEs, but then VS Code is out too, and I'm not sure what we're talking about.

"No autocomplete" and "doesn't show available functions" are a matter of bad defaults, rather than lack of capability. There are great packages for them available, but even in core, there are OK options (ido-mode). I do wish that the core team would "bless" great packages and work towards bringing them into core and into the defaults.

FSF copyright assignment is a stumbling block here in my opinion.

Maybe helm (https://emacs-helm.github.io/helm/) should be installed and preconfigured by default.

This solves a lot of the shortcomings of vanilla emacs.

Helm is a little heavy-weight. Ivy is lighter, but also does a lot of NIH stuff it doesn't need to. I personally like selectrum, (https://github.com/raxod502/selectrum) because it provides the features of Ivy and quite a bit of extensibility, while still only using the built-in extension points in emacs (completing-read-function, etc.). I do wish the emacs developers would bless something and include and configure it by default, though.

There's a new builtin icomplete-vertical mode in Emacs 28, but I assume that like so many defaults, switching is deemed socially infeasible, so we are stuck turning it on ourselves.

Just because it is expensive to learn Emacs doesn't meant that it isn't worth it. Fine, you aren't "going to put the time in". But what do you get then? A mess of programs and plugins that need to be replaced, rewritten or reconfigured all the time, and its not even close compared to a well managed Emacs setup.

I think Spacemacs helps with getting started.

For a newcomer there is a "curse of Emacs", helm? ivy? ido? Wnat to do Python? elpy, lsp, etc

It's easy to get confused and just give up. Having a curated config like Spacemacs helps to get it working out of the box IMO.

Doom Emacs is very good in this regard too. Without Doom and its sane defaults, I certainly would have given up on emacs.

I never had to read a book to use emacs well. Same with vim, VSCodium, and IntelliJ.

Sometimes I ssh into a machine that has only vim installed, so I use vim. Sometimes it is faster to open a file using vim, so I use vim. If I expect to spend a lot of time editing it, then emacs.

Currently I am using IntelliJ for a Java/Kotlin project.