[xedrac]

I'm happy to see these improvements. One thing that has always been annoying with Emacs is how much configuration is required to get a modern editor going. Things like Doom Emacs, and Spacemacs try to solve that problem, but both feel far removed from vanilla emacs. I wish Emacs came with several presets so with a single line, you could transform the editor to different base points. For example, most devs want treesitter highlighting and LSP enabled by default. Why not have a preset like (preset-base-ide-1), so we don't need 200 lines of configuration before we can function? Instead we could build off of a much closer starting point.

[skulk]

This comment shows up on every single emacs thread and for the life of me I can't understand why. It takes one line in a shell to pull down a premade config and if that were to be built on, who would decide what gets put in? I don't think it's worth anyone's time to decide what everyone needs in a premade config.

[tpmoney]

The problem isn’t so much the difficulty in finding a pre-made config, it’s a combination of:

A) which premade config to choose

B) what half of those settings even do (and do you need them)

C) a lack of “sane” defaults that use the built in abilities

Realistically walking through the article authors “emacs from scratch” config and seeing what can be done with the built in packages and how is hugely instructive but even then you only get that from walking through the config one line at a time and reading “help” documentation for most of it.

At this point emacs is so old that fixing the problem of “sane defaults” is probably near impossible if only for how much it would break existing configs. But it might be a good addition to the tutorial to provide a set of questions and answers (possibly with demonstrations) that allow a new user to generate their own config with some nice defaults. We can assume these days that most new emacs users are coming from some other editors, so asking questions like “do you want auto complete suggestions in an inline drop down like VSCode” could be a perfectly reasonable question and then it could add the correct configuration settings to config for you using just the built in functionality

[coldtea]

>if that were to be built on, who would decide what gets put in?

A small number of people with taste and experience.

Like one hopes to be the case for every opinionated preset profile set.

[rhaps0dy]

Yes. That's why you should use Doom Emacs.

[throwaway27448]

Doom emacs might as well be a completely different editor—it completely changes the keybindings.

[kccqzy]

You are just worrying for no good reason. Doom Emacs and Spacemacs are both very good; being far removed from vanilla emacs is not a problem to be worried about.

[cmrdporcupine]

Both of those are modal editor configs. Which... No thanks?

[didibus]

Same, I use Spacemacs in holy mode, which is spacemacs with normal emacs key bindings and not vi modals, but still I wish there was a good config that was straight up emacs bindings and didn't pull in evil at all.

[bryanlarsen]

Both Doom and Spacemacs work fine without the vi bindings.

[tmtvl]

Doom doesn't, it defaults to vi bindings and you can't turn that off easily. Spacemacs does offer a choice, though.

[bryanlarsen]

Last time I looked it appeared to be as simple as disabling evil mode and configuring a new leader key. But you're right, it's not a straight configurable.

[iLemming]

Huh? Emacs is inherently a modal editor - transients, isearch, keychords, M-x - these are all forms of modality. Vim-motions simply organizing that all into nice set of patterns - memorable and very practical. Besides, both Doom and Spacemacs absolutely can be used without Evil layer.

[cmrdporcupine]

This is a ridiculous collapsing of the sense of what people by "modal editing" into a homogeneous conceptual soup.

The core editing components of non-Evil emacs are direct manipulation, not modal. That there are modal aspects on top of that for doing things which practically/genuinely need a modal switch (command entry, search entry, etc) doesn't make the default emacs configuration a "modal editor" in any sense of which people actually apply those terms.

By your definition of modal, almost every application can be described this way. The point is not whether a system has modes, it's whether it makes its core emphasis and interaction modal.

You can see vi's motions as elegant and purposeful. I see them as an accident of history stemming from the poverty of the number of keys and capabilities of the dumb terminal it was designed on.

I encountered both editors in the late 80s and chose emacs precisely because it didn't have the "barely a step up from a teletype" interaction model that vi had.

As for Doom and Spacemacs without Evil.. yes... but why? Their original and state purpose was a packaging with a modal default. It's trivial to toss together your own init.el that brings in the same set of packages these days and with very little effort.

If the goal is an easy packaging of emacs with sensible defaults.. and then you have to go modify the defaults to make it what most people (yes, most) would consider sensible... No, that's not meeting the state use case.

[iLemming]

> You can see vi's motions as elegant and purposeful.

Sure I do, and there's so much tacit knowledge that I can't ever explain verbally or in writing that goes into it, to the point that arguments like yours, challenging my "choices" would ever feel less disingenuous. It's like forcing a left-handed kid to hold the pen "correctly", due to religious dogmas. It just works far more naturally for me and thousands of other people, and just because you don't get it, it doesn't make the model useless. Try to see the other side, sometimes "dumb" ideas do work, and shit that works maybe ain't that stupid.

> Doom and Spacemacs without Evil.. yes... but why

Great question. Now maybe you're trying to learn something despite of "years of the opposite experience" feeding to your hubris. Doom offers a set of Lisp macros that come very handy - map!, add-hook!, defadvice!, undefadvice!, add-transient-hook!, etc. - they genuinely can slash the inevitable boilerplate in the config. It's much easier to experiment with advising and instead then writing ad-remove-advice with different syntax, repeating the symbol names, etc., you'd simply prepend `un` to the form and eval it. add-hook! allows binding multiple fns to multiple hooks. And these are just some examples.

Also Doom does some tricks to make the startup blazing fast. Many times I have compared my config (that pulls over 350 packages) with someone else's vanilla. Doom demonstrably starts much faster.

[mystifyingpoi]

I think it is cultural. It's kinda like building your own lightsaber as a Jedi. The part of Emacs/Vim initiation is building your own configuration that works for you. Setting up plugins, keybindings, colorschemes etc. It's part of the fun of it (at least for me).

[noufalibrahim]

Oh yes. What other software allows you so much to make it your own? Yes, I know the yak shaving argument etc. But what's the fun in opening up some computer/OS/software that looks and feels exactly like everyone elses? An Emacs (and vim) setup is something you can actually have a discussion about with someone else.

[tmtvl]

KDE, various window managers (i3, awesome, xmonad,...), the Linux kernel (there's so much stuff you can configure through sysctl alone, and that's just 1 single customization facility), SystemD, your shell (whether it be bash, zsh, csh, ksh, or something else), and the list goes on.

[cyberpunk]

And then slowly over 20 or so years deleting all of it.

I think I'm down to about 110 lines of ~/.vimrc now :}

[wtetzner]

But without building it all up and then slowly deleting it, you wouldn't have known which 110 lines were the ones to keep ;)

[tmtvl]

There's Bedrock, Centaur Emacs, Witchmacs, and more; even if you don't like Doom and Spacemacs there's plenty of fish in the sea. Though there is the issue where preconfigs tend to have edgelord 'Dark As My Soul' themes which make text absolutely unreadable, which is a bit of a pain to deal with.

[skydhash]

> Why not have a preset like (preset-base-ide-1), so we don't need 200 lines of configuration before we can function? Instead we could build off of a much closer starting point

First you need to define what is that much better starting point? Something VSCode like? I find VS Code a bad example of software development tooling (anemic file management, integration with external tooling is cunbersome, VCS integration is flimsy, Code viewing is poor,…).

VSCode is a swiss knife. It has a few tools that are handy for occasional needs. But Vim and Emacs provide a complete toolbox. Learn it once and be set for life.

The only reason we still have IDE is kafkaesque ecosystems that requires expansive and custom tooling just to make sense of it. People can use vim to write code for the Linux kernel but needs XCode for a 5 screens app.

[bitwize]

IDEs exist to allow teams or entire divisions to hit the ground running with development, with a standard interface that everybody on the same team uses (a huge boon for collaboration), without a lot of time spent configuring or integrating the tools. All the integration is done by the vendor, often better than you can do it; the debugger integration in full-fat Visual Studio is still second to none.

Grooming a personal .emacs or .vimrc is fine if you're working alone, but when you're on a team of professionals working on an application built on a commercial platform, a standard workflow for development is essential and an IDE supplies all the tools, integrations, and conventions to cover the basics of such a standard. Do not underestimate their value.

[skydhash]

I don’t mind IDE per se, Just like I don’t mind Game Consoles. It can be truly useful, as you say, to have something Plug-and-Play to hit the ground running.

But they often use subpar components (code editors, file managements, VCS,..). They are tailored to a specific standard and any deviation to that standard result in a lot of pain. So I much prefer documented tooling subset that can be integrated however you want than an IDE.

Also you usually spend more time using a system than learning it. Aiming thing to beginners increase longterm discomfort.

[pritambaral]

TV dinners have their value, but a cooked meal is often better. And, just like meals can be cooked for a team, so can emacs configs.

[quibono]

Indeed. I myself am on Doom Emacs but I've increasingly been thinking of moving over to vanilla Emacs. I'm a bit worried about the transition period due to all the keybind differences but I'm sure it's not too bad.

[bryanlarsen]

Tell your agent what parts of Doom Emacs you actually use, and ask it to build a minimal init.el containing only those parts. You're probably only using ~2% of Doom, so the resulting init.el will likely only be a few hundred lines, and most of those lines will be comments and key bindings.

It won't be a perfect transition, but it will make it a lot smoother.

[fridder]

I'm also a Doom user, albeit a new one. What is making you consider the switch?

[quibono]

Don't get me wrong, I'm loving Doom and have used it full time for a few years now. But over time I've started being uncomfortable with the fact that I don't fully understand the editor, don't fully appreciate the difference between what comes in as part of vanilla Emacs and as a Doom feature, and I feel like I am depending on a huge bunch of code and configuration I might not really even need.

Selfishly I wasn't willing to spend the time to master Emacs proper back then, but with the LLM craze now I find it much easier to hack on my configs.

[iLemming]

I've had multiple config bankruptcies over the years until settling down with Doom. I'm considered "experienced Emacsian" - built and published packages, etc. I'm still using Doom but only the core of it. I don't even consume almost any of its "official" modules - I have my custom ones instead. I have considered building my own config from scratch (yet again), but I like Doom's core macros - map!, add-hook!, defadvice!, undefadvice!, etc. I'd probably inevitably end up borrowing them and structuring my new config just like I already have, so I see no point.

> I don't fully understand the editor

Going vanilla will not help you there - well, not completely anyway. Moreover, it may even obscure some features that were easily accesible before.

> I don't fully appreciate the difference between what comes in as part of vanilla Emacs and as a Doom feature

That is not very difficult - learn how to use built-in features - profiler, edebug, describe-, apropos-, hooks and advising, etc.; Start writing Elisp code (with understanding it). In the end, it won't really matter - whatever runs in your Emacs, there's always a way to get to the source. And if you ever need to disable any feature of Doom - there are multiple ways to do that.

[kristjansson]

Emacs is not great software because it has good features. It’s great software because it conforms itself and those features to the user’s needs and preferences. If one of those preferences is short, canned config, we’ve got a way to express that (spacemacs and doom). But if one can’t be arsed to express their preferences even in those frameworks … emacs might not be the software for them.

[emil-lp]

What are these things you have that makes Emacs a modern editor?

I have cua-mode and don't show startup message. What else do I need to modernize Emacs?

[kickingvegas]

For your consideration, two Elisp packages I've written that focus on feature discoverability and use: Casual and Anju, both available from MELPA. You can read more about them at the following links: https://github.com/kickingvegas/casual https://github.com/kickingvegas/anju

[cmrdporcupine]

Vertico feels like a must-have to me these days. I also like to have treemacs installed.

Apart from that, I don't have a lot I insist on, and my used emacs package space keeps shrinking.

That said lately I use lem more than I do GNU emacs.

[quibono]

treesitter (with easily installable grammars - a big pain point) / LSP integration OOTB / themability

Plus now agent integration (aka GPTEL)

[b5n]

These are all trivial to implement?

`treesitter` grammars _are_ easy to install.

`eglot` is available OOTB, `lsp-mode` is easy to install and configure if you prefer.

`gptel` is easy to install and configure.

[chipotle_coyote]

I'm getting pretty good with Emacs, but I find its Treesitter handling a bit obtuse, and the auto-installation package I found slowed the editor down a lot for reasons I can't determine. (I mean, everything slowed down, and it all sped up again when I uninstalled the package.) I'm looking forward to revisiting this when Emacs 31 comes out, though.

I also don't think I'd ever call configuring Emacs "trivial" compared to more modern editors. Matching the out-of-box experience of something like VS Code or Panic Nova requires some work. This isn't really a knock against Emacs, but I think Emacs fans -- myself included -- need to be honest about that. It's quite possible I would have picked up Emacs years earlier if I hadn't been given the impression that it was just super duper easy, especially once you picked a starter pack. It is not, it probably never will be, and I've come to believe that starter packs are actually a bad idea for most new users. If you don't understand just what it is you're putting in your init.el file and why, then if you run into problems, it's going to be way harder to figure out how to fix them.

[coldtea]

Being many things, even if "easy to install" individually, can add up to a hassle to pick, research, install, and configure them.

[b5n]

Why even use `emacs` if you're not willing to learn the basics? There are plenty of alternatives that cater to that preference.

[nehal3m]

As a Vim user (just admitting to my ignorance here), is it not feasible to make something like this yourself? Emacs is said to be flexible and extensible enough, or at least I’m under the impression that it has that reputation.

I imagine it would take a lot of time, maybe. Any greybeards that do this?

[tmtvl]

It is fairly trivial to make something 'like it', but what people advocating for this stuff want is for it to be shipped with regular plain old normal GNU Emacs so they can set it up quickly and easily in an Emacs installation on a work laptop (and it may make it easier to convert people to Emacs for those who care about that).

[sukuva]

I spent a lot of time making my own elisp config for a custom emacs experience and ended up getting something similar to Doom Emacs. So, I just switched to use Doom :)

[egorelik]

This is how I justify not switching back to vanilla, despite not really being an evil user. Doom's module system is really great for organizing a config.

[emodendroket]

Yeah, it'd be easy, but the hard part is getting people to agree what the standard will be.

Plus, frankly, a lot of people (myself included) who want a richer experience are pretty much just happy turning on emacs keybindings in VSCode or IntelliJ or whatever.

[worthless-trash]

Richer in vscode, i'm not so sure.

[psadri]

Claude: configure my Emacs such that … has worked pretty well for me lately.

[__patchbit__]

Ask Claude to reprogram the Emacs graphics display engine to provide 3D wireframe object relations to see Popper's World abstraction navigating World 3 to 1 and backup.

[0_gravitas]

Bedrock Emacs is pretty much this, its what I finally used after I declared config-bankruptcy with Doom, and it gave me the room I needed to get my own setup together

https://codeberg.org/ashton314/emacs-bedrock