What is Reddit's opinion of Doom Emacs?

From 3.5 billion Reddit comments

https://github.com/hlissner/doom-emacs mentions

> A popup management system (powered by shackle) that minimizes the presence and footprint of temporary and/or disposable buffers.

I'm really curious what that looks like, but I can't find a screenshot anywhere. Does anyone know of one off-hand?

Info

• Distro: Arch
• WM: XMonad
• Panel: dzen2 + conky
• Info: Neofetch
• Music: ncmpcpp
• Term: urxvt
• Font: Fira Sans, Fira Mono
• Emacs: doom
• Twitch: mpv
• Wallpaper: here
• System tray: trayer

Still a few kinks to work out, getting the Private Use Area unicode symbols to appear in urxvt being the next thing to sort out but other than that I'm pretty happy with my current setup :)

Dots on request, I guess, because I haven't packaged them up yet.

Yes, it is.

Installing git 2.28 on ubuntu: https://github.com/hlissner/doom-emacs/blob/develop/docs/getting_started.org#git

If this upstream issue is addressed, we can lower the minimum requirement: https://github.com/raxod502/straight.el/issues/768

I thought Vim was cool until I tried writing a vim script. That same day, I turned Evil, and not long after that, I found Doom.

There is none ATM.

But I believe u/tecosaur is planning to write one (or maybe already working on it) for inclusion in his monthly org report. I've already said I'd help if he needs it.

You can see this Doom PR I'm working on for some ideas on config.

https://github.com/hlissner/doom-emacs/pull/5212

I can't promise it works ATM though, in part because I don't understand use-package very well!

The only thing Doom does is to mark all the customize commands as disabled, using the standard Emacs mechanism for disabling commands.

You could even reuse the code Doom uses to do this: https://github.com/hlissner/doom-emacs/blob/develop/core/core-ui.el#L685-L696

I had a similar story: Vim => Spacemacs => Emacs => VSCode => Emacs.

The biggest downside to using Emacs is just configuration. Spacemacs was great for that but it was too slow. So I made my own Emacs config, and it was hours of pouring over it to make it right and work the way I wanted. I went to vscode and got rid of most of that configuration. But couldn’t get by with the Vim inside of VSCode and I hate being married to my mouse. So I went back to Emacs and recently found doom emacs. It’s cumbersome to extend but it’s been my daily driver for about 6 days now and I love it. Its like Spacemacs but faster, also more opinionated which is good/bad sometimes.

> Yes! That the markdown sources should be the only source code for a series, and that Rust files, terminal sessions, even screenshots should be "build artifacts", that can all be produced from the markdown by my content pipeline.

> That's... radical? But I can already think of so many cool things this would allow, iff you don't burn out before getting it to a point where it's useful.

> This seems like a lot of work!

This already exists: emacs’ org-mode is a markdown-like syntax that supports executing and exporting a document’s code blocks, including terminal commands, and their outputs. You can insert evaluated output into the document itself and you can export source code files from an org document. You can even export source files in multiple languages from the same document and export the document itself to markdown to fit into an existing publication workflow. These are all mature, community-maintained features, not cutting-edge experimental stuff.

Of course, this is primarily useful if you use emacs, which the author does not (though the vim-keybinging/LSP workflow described early in the article is well supported); but the popular doom-emacs elisp framework includes a shell command which can be used to script the source code-file-generation process externally.

> hints for someone who is really comfortable using Jetbrains IDEs and finds emacs a bit too much of a barrier to overcome??)

yes :) https://lispcookbook.github.io/cl-cookbook/editor-support.html Atom + SLIMA is very good and getting close to Slime. VSCode has two new-ish extensions. There's an Eclipse plugin, but it's basic. Also try doom-emacs and enable its CL layer (https://github.com/hlissner/doom-emacs/).

> down in popularity and attention from the programmer's community

it's going back up today :) [1]

[1] it's true, but saying it out loud also helps make it true.

AFAIK tide is good (haven't tried it myself). For language specific setup I like to checkout doom or spacemacs. Here is dooms setup for example.

Emacs's GUI is not as flexible and as easy to tweak as those web-based text editor. However if a good GUI is not come with a comprehensive functionality set, in my personal view it's not good. The functionality of Atom's org-mode implementation is far from the "sufficient" (again, from my personal point-of-view).

My setup looks like this (using doom-emacs), with a write-mode like this, when exported to HTML, I can get something like this.

I'm not sure whether that looks OK enough for your taste, but for me it's fine. Of course if someone can replicate 80% of the current org-mode functionality in either VS code or Atom, I would be happy to give a try. However I believe that's quite difficult.

There's indeed a breaking change in the recipes because of this release. Check out this https://github.com/hlissner/doom-emacs/issues/5667#issuecomment-948229579 to work around this until there's a proper fix (which probably will imply repinning a module or three)

>I am using vanilla Emacs and have no problems here.

Same here, but why does your readme say "I have declared .emacs bankruptcy?"

>Is there any incentive for me to switch to doom?

The readme on Doom's github page does this the most justice.

To me I think the primary reason to use something like that is to take advantage of community effort and maintenance.

However, for people willing to put in more initial work and configuration vanilla Emacs provides a completely tailored experience.

I think you should check out DOOM emacs. It's got a fairly active community on discord and is closer to normal emacs in terms of feature abstraction but still extremely simple to use. Check it out

https://github.com/hlissner/doom-emacs/

I'd take a gander at what Doom Emacs does in its early-init.el and init.el.

With that, running the daemon, and byte-compilation of Elisp files, I get a startup time of usually under a second.

I don't deal with the base configuration myself. Doom emacs has that out of the box once you turn on the javascript module. I also have the web module and many others enabled.

You can take a look at the packages used and how they are configured here:

https://github.com/hlissner/doom-emacs/tree/develop/modules/lang/javascript

A lot of people are going to recommend Vim. If you don't like to tinker with things, Vim is for you.

If you want to customize your text editor, I suggest you do not torture yourself with VimScript. Instead, you can get the best of both Vim and Emacs: https://github.com/hlissner/doom-emacs

Doom Emacs is an optimized configuration of a set of packages for Emacs. The defaults are all great out of the box, and making changes is simple (you will need to understand basic lisp, though).

I love the way spacemacs uses the leader key and really enjoy the layers setup. However, I found it bloated and difficult to configure outside of what layers offer.

Recently, I switched to doom-emacs which is more configurable, less bloated, and offers a similar workflow. I am much happier with this setup.

If this sounds interesting, I would recommend giving it a shot!

Most of my biggest complaints are already here, but I'll mention these few anyway

• The GC is doo doo

Doom Emacs has you change the GC-Threshold in your init.el to get Emacs to startup faster. There's probably other examples regarding GC out there.

• You have to do some weird tricks to get faster Elisp code.

For instance having ;; -*- lexical-binding: t; -*- at the beginning of Elisp files. It's more correct, but it also speeds things up. Also usings lambdas is a no-no: use dolist or cl-loop instead. There's obviously more.

• No JIT compilation

Feel like this would help a lot of things performance wise. Not all of them but a good chunk. There have been some posts here about people trying to implement JIT in Emacs.

• Emacs27's autloading functions feature allegedly isn't any faster than Doom's.

I feel like I'm shilling for Doom Emacs. Anyway, apparently someone on the Discord channel tried that Emacs27 feature and said it wasn't any faster than what Doom does already. Kinda of disappointing honestly.

>So fellow doom/space users, what made you jump on that train ? How did you get to "master" this complex environment ?

Well, the easiest thing to begin with is to just install doom and leave everything at the default settings. (Perhaps minus evil, if you don't want it). - It's surprisingly minimal for doom, but still has some changes from vanilla.

Once you are somewhat familiar, go into `init.el` and enable a module that you want / need. See what it does. Read the documentation at https://github.com/hlissner/doom-emacs/blob/develop/docs/modules.org and the perhaps also the underlying packages documentation. (You'll need to search the internet for that one).

Then use it for a bit, see if you like it. If you like it, keep it, otherwise comment it out again.

Rinse and repeat and you've got yourself what you want.

> He pointed a discourse thread with further information I could try but I've had no luck...

By no luck do you mean you couldn't access the Discourse page, or that none of its advice helped you? I'd be surprised if the latter. Not even native-comp? Even disabling line-numbers should give you some improvement? Have you tested in vanilla Doom to rule out your private config?

Prelude. The default bindings work.

Doom is not meant for noob / starter. The readme introduction says

> Doom is a configuration framework for GNU Emacs tailored for Emacs bankruptcy veterans who want less framework in their frameworks, a modicum of stability (and reproducibility) from their package manager, and the performance of a hand rolled config (or better).

I use it and like it, but it's not for everyone.

I wouldn't call it lacking. More like some assembly required. It has LSP support and various useful packages. You'll have all the expected things like autocomplete, go-to def, rename, autoformat, etc. You can end up with functionality quite close to IDEs like VSCode.

If you don't like spending time customizing much, I'd highly recommend Doom Emacs for a fairly seamless experience.

Enable the :emacs (dired +icons) module. It'll set it up for you. How to do that

Btw, Doom does use use-package. You could use that snippet as is, if you didn't want to use the module for some reason (you'd need (package! all-the-icons-dired) in ~/.doom.d/packages.el to install it first). What Doom doesn't use is package.el (Emacs' built-in package manager). More on Doom's package manager here.

Sounds like you've installed them using package.el (e.g. with use-package's :ensure t directive, calls to package-install in your config, or straight up M-x package-install). Doom doesn't use package.el. Packages installed with it are treated as transient -- they're forgotten about when you restart Emacs.

See this section of the documentation on how to do package management correctly with Doom. The gist of it is:

1. Add (package! PACKAGE) to ~/.doom.d/packages.el
2. Run doom sync on the command line,
3. Restart Emacs.

Packages installed this way are permanent, and will not be forgotten next time you boot up Doom.

You might find Doom Emacs to be a nice compromise. It's easy to use it as a base for your own customizations, and it's a very well and actively maintained project. I know that the maintainer posts here sometimes.

I've had a great experience with Doom Emacs, LSP & HIE work out of the box. Emacs being Emacs the integration is amazing, and it's fully customizable – provided you're willing to get your hands dirty. Link to the Haskell module for reference.

(setq gc-cons-threshold 6400000)

(add-hook 'after-init-hook (lambda () ;; restore after startup (setq gc-cons-threshold 800000)))

You could also just do.

(setq gc-cons-threshold 402653184 gc-cons-percentage 0.6)

;; ... your whole emacs config here ... ;; Then reset it as late as possible

(add-hook! 'emacs-startup-hook (setq gc-cons-threshold 16777216 gc-cons-percentage 0.1))

But maybe using after-init-hook is better. I'm not sure. This is from the Doom-Emacs FAQ.

> one thing that bothers me with Vim is the lack of integration between plugins. Are Emacs modes and keybinds better integrated?

Even if you don't use Spacemacs, you should still look into how they set up some packages because they resolve a lot of inter-package issues for users. Also look at evil-collection.

If you are not interested in Spacemacs you should at least check out Doom which describes itself as "trying to be better then Vim in every possible way". I really think starter configs can accelerate your journey with Emacs (even if you eventually drop it for your own config).

The guide in the link is a little outdated. Since org-mode 9.5 there a builtin engine to handle citations.

Review these links for more info

https://blog.tecosaur.com/tmio/2021-07-31-citations.html

https://blog.tecosaur.com/tmio/2021-10-31-release.html

And this to copy some of the relevant configurations

https://github.com/hlissner/doom-emacs/pull/5290

Perhaps you can study Doom's <code>after!</code> macro.

Usage:

(after! (package1 package2 package3)
  ...)
;; or
(after! (:and package1 package2 package3)
  ...)
;; equivalent to
(with-eval-after-load 'package1
  (with-eval-after-load 'package2
    (with-eval-after-load 'package3
      ...)))

(after! (:or package1 package2 package3)
  ...)
;; equivalent to
(with-eval-after-load 'package1 ...)
(with-eval-after-load 'package2 ...)
(with-eval-after-load 'package3 ...)

Also allows you to nest :and and :or's. e.g.

(after! (:and package1 package2 (:or package3 package4))
  ...)

Could be improved to not re-evaluate ... after the first time, but that's another story.

If you don't want to join a religion, or learn another language just to write some python, Doom emacs is what you're looking for. Not too far from vanilla, but just sensible improvements all around. And a great community!

When reporting an issue, it pays to be much more specific about the errors you get. An "error in private config" is just that; an error in one of ~/.doom.d/init.el, ~/.doom.d/config.el, or ~/.doom.d/packages.el. The rest of the error message will typically tell you where, exactly.

There is nothing else that can be gleaned from your case. Please produce a backtrace from the error.

Yes, I hope so too. My goal is not that users adopt this particular stack, but rather that people come and use Emacs. Some of my packages can be seen as a modest modernization attempt of some UIs in a minimal and composable fashion, e.g., Vertico and Corfu. And I like it if people use and reuse as much as possible of the built-in infrastructure, since as I believe, this helps learning how Emacs functions. Nevertheless it is still nice if people adopt the packages - see also https://github.com/hlissner/doom-emacs/commit/c2e6db27d030f20d3aead4b2049695e4b2d942ba.

I use Emacs Doom. It starts up extremely fast, despite it having many batteries included:

Doom loaded 193 packages across 34 modules in 0.436s

Still not as fast as vi, but not slow as molasses either.

This helped me: https://github.com/hlissner/doom-emacs/issues/2195 when rustic demanded rls being available. Not sure which one exactly, cause I was throwing it a little random to `config.el`.

See https://github.com/hlissner/doom-emacs/blob/develop/modules/ui/modeline/README.org#the-right-side-of-the-modeline-is-cut-off

There are three issues here.

1. flycheck-mode is not the name of the package. It's flycheck. Even if your after! call were valid, the setq would never execute.
2. A common misconception is that after! is somehow like use-package; in that it understands :config, :hook, etc. (use-package properties). It does not. It is much simpler: (after! X BODY...) = after X loads, BODY... runs. That's all. Replace after! with use-package and it should work as you're expecting (given you've corrected problem #1).
3. Why are you activating flycheck by hand? Doom's :checkers syntax module activates <code>flycheck-mode</code> for you. Your :hooks aren't necessary to begin with.

Hope that helps.

How about Chemacs? There are some TLDR instructions in Doom's docs that may help.

https://github.com/hlissner/doom-emacs

&#x200B;

Didn't try it. However, previously I used spaceline from spacemacs and now I use doom-modeline from doom-emacs and it's objectively far, far better than spaceline ever was :)

It appears to be one more long discussion about editor. Let me add my 50 cents.

I used to use Visual Studio with Visual AssistX for c++ development, after that I had a long run of iOS and Android development using XCode (which I tried to improve using Vim extension). After that I continued C++ development under linux using CLion. But was not satisfied again - now I'm using Spacemacs + lsp (ccls) for C++.

spacemacs has integration with:

• Treemacs - file browser
• ccls - C++ code indexer, autocompletion and refactoring + plenty of other thing
• helm-make - it allows me to run make for any target in easy way
• helm-ctest -- run selected unit tests
• gdb extension allows me to run debugger inside emacs

&#x200B;

In addition I did some haskell and python development inside emacs. I'm not satisfied with a bid slow spacemacs performance (but it's faster than CLion) thats why I'm considering migration to doom-emacs. Another great advantage is ability to work remotely using ssh. None of modern editors allows that great thing besides Emacs or Vim.

As was mentioned before - Magit is another emacs killer feature. In addition to it I use SmartGit for lazy history navigation using mouse.

So I consider Emacs a great tool, but main issue is that it has lack of support and investment, like big companies do for there tools.

> eshell is fucking ghetto

How dare you.

I mean yea, you gotta do some shit to make it work fairly decently.

But how dare you!

It's from doom-emacs.

&#x200B;

See here and here.

Doom uses evil-easymotion under the hood https://github.com/hlissner/doom-emacs/blob/develop/modules/feature/evil/config.el#L159 so I'm thinking this is possibly a config option.

I'll forward this thread onto Henrik too.

My config is based on doom-emacs https://github.com/hlissner/doom-emacs/tree/develop , check out my personal config here https://github.com/fuxialexander/doom-emacs-private-xfu

For a org file shown in the image:

** Demo of ESS in Org mode #+BEGIN_SRC R :results graphics output :file ./.attach/test-r.png :session R:test-r library(ggplot2)

# create factors with value labels mtcars$gear <- factor(mtcars$gear,levels=c(3,4,5), labels=c("3gears","4gears","5gears")) mtcars$am <- factor(mtcars$am,levels=c(0,1), labels=c("Automatic","Manual")) mtcars$cyl <- factor(mtcars$cyl,levels=c(4,6,8), labels=c("4cyl","6cyl","8cyl"))

# Kernel density plots for mpg # grouped by number of gears (indicated by color) qplot(mpg, data=mtcars, geom="density", fill=gear, alpha=I(.5), main="Distribution of Gas Milage", xlab="Miles Per Gallon", ylab="Density")

qplot(x) #+END_SRC

#+RESULTS: [[file:./.attach/test-r.png]]

I don't think it's dying but it is being thoroughly mismanaged. The maintainers still cannot cope with all the external contributions (let alone bug reports) and have don't seem to have an effective plan to address this. On the other hand, slimmer, faster, stabler, and better designed frameworks like doom-emacs have learned from the mistakes of spacemacs.

I think that spacemacs will stay usable for a long time, but it is being demoted in status to "yet another configuration framework" rather than being the premier choice that it was for many years.

I use Doom-Emacs but I'm certain something very similar could be recreated using spacemacs. I split the frame into 2 windows with my LaTeX on the left and the pdf on the right. It looks like Doom uses the package pdf-tools and auctex but I would recommend just using spacemacs defaults. I have this code in my private config to enable automatically compiling the latex and refreshing the pdf when I save.

(after! latex (defun azy2/compile-pdf () (setq-local compilation-scroll-output t) (compile (concat "pdflatex " (file-name-nondirectory buffer-file-name)))) (add-hook 'LaTeX-mode-hook '(lambda () (add-hook 'after-save-hook 'azy2/compile-pdf nil 'local))))

and

(add-hook 'doc-view-mode-hook #'auto-revert-mode)

You won't be able to copy this code exactly but hopefully it gives you some inspiration.

You might want to take a look at the emacs configuration of hlissner known as Doom emacs. He has added vim bindings to every module he has implemented. All bindings are located in their own evil-only file. It would be easy to pick them up.

Here's my modeline config. It's basically a hack of the doom modeline

I agree. While I mostly use Emacs (don't hurt me), I used Doom Emacs for awhile and used it to configure my own Emacs config. Both Emacs and Neovim can be a bit daunting to configure at first (Emacs more so since of how much it does and gives you out of the box that isn't configured or immediately/obviously expressed as available).

I'm using LunarVim to write my own Neovim config. Nothing wrong with that, nor just sticking with what's given with LunarVim.

Not everyone wants to put in the effort in building out some amazing config.

Update Doom. My snippet will work for you beyond https://github.com/hlissner/doom-emacs/commit/2c5cc752ff372745ae805312d3918e72ed620591.

Before that commit, you'd have to flip the package order: (after! (ob-ditaa org) ...)

Ah okay, well I definitely suggest Doom Emacs as it's a great entry point for new users. Doom Emacs Github

Just go through the install instructions and make sure you have all the 'Prerequisites' installed on your system.

Once you have it all installed and ready to go, let me know on this thread :)

EDIT: Just be aware that Emacs and by extension Doom Emacs is extremely keyboard driven. There is definitely going to be a bit of a learning curve, but once you get the hang of it, it's amazing!

Can you reproduce this behavior in the sandbox? https://github.com/hlissner/doom-emacs/blob/develop/docs/getting_started.org#testing-in-dooms-sandbox

If not it’s something in your config and people probably won’t be able to help you. Your best course of action is rolling back parts of your config until you can no longer reproduce the behavior.

Uhh, can't tell you more but a quick search through Doom's code shows that it's integrated into this function: https://github.com/hlissner/doom-emacs/blob/c2e6db27d030f20d3aead4b2049695e4b2d942ba/modules/config/default/autoload/files.el#L40

i'll explain on discord when the tgwlg mods get back to me, dw :3 easier to ramble about stuff on there than here lol

also, if you don't wanna bother configuring all of emacs yourself, there are prebuilt distributions around like spacemacs or doom emacs as well

In Doom Emacs with evil keybindings,SPC m t is mapped to org-todo (relevant line in Doom Emacs source) and should give the option to change the TODO state using the relevant keybindings (a small buffer pops up at the bottom of the screen). I've used it for a while, and haven't had any issues with it.

Calling that function (either with M-x or just evaluating the elisp function) does the same. u/rameshgg87, try one of these methods. If that doesn't work, then use SPC h b b (which shows all current keybindings) to see whether SPC m t is still mapped to org-todo. You could also try the default emacs keybinding: C-c C-t which also calls org-todo

The behavior you're describing is supposed to happen with <S-right> , not SPC m t

Yes, I saw the blog post and it did not work for me either. However, the issue you linked had the solution.

I basically needed to add

(setq evil-respect-visual-line-mode t)

to my .doom.d/init.el, I added that to the top of the file, exited emacs, ran doom sync, started emacs again, and it's now working with the expected behavior.

For anyone interested in the exact reply on the issue, here's the link: https://github.com/hlissner/doom-emacs/issues/401#issuecomment-588502773

Thank you for your help.

I got curious and looked into this. I assume you saw this blog post based on your attempt. I tried this in my ~/.config/doom/init.el, but it didn't work.

Then I found this github issue, and it turns out this works fine if you turn on visual-line-mode SPC-t-w by default.

So you can just enable this in startup with (global-visual-line-mode t) or by mode hook if you prefer only in some modes.

Update: thanks to the straight.el devs quickly resolving https://github.com/raxod502/straight.el/issues/768 Doom can reduce its minimum git requirement back to 2.23, and has in https://github.com/hlissner/doom-emacs/commit/1a5f4afd0d8bcb311ef0b87db42c81b134cb93d3

When I switched editors a few months ago, I was tempted to jump on the VS Code bandwagon, but feared something like this would happen.

I ultimately settled on Doom Emacs (w/pyright and ipython support in org mode babel) - configuring it is less scary that emacs from scratch and allowed me to leverage my limited vi muscle memory to get around a new editor. Overall, I'm very happy.

Perhaps Doom Emacs? I have my own emacs configuration but I hear that this one comes with a lot of good initial configs that work with evil-mode (which is vim keybindings in Emacs).

geiser was changed recently and Doom's :lang scheme module had to adapt (see 32cf114). It now offers flags for each of the implementations.

You'll need to 1. update Doom and 2. enable :lang (scheme +mit)

I answered more in-depth on github, but here are the highlights:

1. Long ago, Doom depended more on byte-compilation to pre-compute expensive things (like load-path or other package.el metadata) so it wouldn't have to do so at startup. I used it everywhere I thought I could shave an ms or three.
2. Bug reports came in from users who didn't practice good byte-code "hygiene": they forget to recompile after tinkering, or would struggle to debug issues with stack traces obfuscated by byte-code.
3. I later implemented better, run-time caching and phased out our fixation on byte-compilation.

The main downside is: byte-compilation complicates things. eval-when-compile hard-codes values into byte-code. You have to be aware of it when debugging issues or tinkering your config. All that effort for negligible gain.

But maybe you can find something expensive that's worth eval-when-compileing.

These "canned configurations" are very complex pieces of software and they are not really meant for beginners. You take these and write your on configuration on top of them. They don't have the documentation quality of Emacs, not the attention to stability and backwards compatibility. These are not necessarily bad things, if you know what you do, it's not that hard to work with it and mend it when it has problems. For a complete beginner, that is also unfamiliar with programming, the config may work when it works, but it may be a huge trouble to fix it when it doesn't, given they wouldn't know how to operate a debugger, understand the dependencies between many packages these distros install, bisect problems, and configure them. Emacs itself OTOH comes with enough documentation to help them get started, learn the basics, and then some more. There's tons of additional documentation online. These distros OTOH are abtractions on top of Emacs. They are advanced tools (e.g. see doom-emacs maintainer @hlissner's reply to me here) that work great for those who don't have much trouble peeking under the abstraction when things go south.

IMHO recommending them to beginners is like telling people who are learning to drive that a TIR lorry is the best vehicle to learn on.

Keybindings-wise, standard is the way to go. It's what's in manuals, what's the common language of Emacs. If I were making an online tutorial or a video, I'd pretty much be using emacs -q unless it's something specifically about my own config. A lot of these videos use their personal setups, and while I really appreciate the effort, looking at them use Helm, Ivy, hydras, Evil, etc., as if they were nothing means there needs to be an extra translation layer to understand what they are telling if you are not using the exact same set of packages.

Did you look at https://github.com/hlissner/doom-emacs/blob/develop/docs/getting_started.org#disabling-packages ?

Doom has a great example of this - https://github.com/hlissner/doom-emacs/blob/develop/modules/completion/ivy/autoload/ivy.el#L228

It should be this line. I was also mildly annoyed by that extra quit confirmation prompt, and I thought I had commented that line out, but I just realized now that I'm still getting the prompt. I got to double check that I actually commented it out properly, and then run a `doom sync`

The development roadmap was also closed on the same date. Maybe he didn't want to keep track of so many pages.

I agree with you about ido :) But for something to displace it, it has to emulate its look and feel, as well as ship with Emacs just like ido. I guess that's what fido is for. Does Consult work with fido?

I don't know if it has been mentioned, but doom emacs is a fantastic starter configuration that makes emacs gui look like a fancy terminal, has vim keybindings installed by default, and is focused on fast startup time. Great for (vim) newcomers! https://github.com/hlissner/doom-emacs/

> I'm positive that I had a situation where I made no changes whatsoever to init.el or packages.el, and yet my modifications weren't recognized until I ran doom sync. In fact, I didn't make changes to config.el either. I made my own "package" called sbr-org (as seen in this gist) that contains all of my custom org functions, and in my config.el, I have the following:

Ah, I'm assuming you installed your local package with a package! statement? e.g.

;; in ~/.doom.d/packages.el (package! sbr-org :recipe (:local-repo "path/to/sbr-org"))

If so, then you have to run doom sync to recompile it each time it is changed (or the changes will never be seen). You can get around this by adding :no-byte-compile t to its recipe:

(package! sbr-org :recipe (:local-repo "path/to/sbr-org" :no-byte-compile t))

You'll need to doom sync one more time to apply this recipe change, but you won't need doom sync anymore (for this, anyhow).

> Do you mean that they were removed from doom or from org-mode?

They were removed from Doom..

> Thanks again for your response, as well as all your hard work!

Thanks! I'm glad I could help!

What about working on removing this package from the list of packages that can slow down emacs, according to Doom emacs. Item #5 https://github.com/hlissner/doom-emacs/blob/develop/docs/faq.org#why-is-emacsdoom-slow

> I haven't been able to embrace emacs. I'm sure you've heard that before :)

Yea, for sure. It's not for everyone. There are frameworks such as doom-emacs that make it more approachable and has reasonable defaults.

Doom does not support the use of the customize mechanism. From https://github.com/hlissner/doom-emacs/blob/develop/docs/getting_started.org#configure:

>Note: do not use M-x customize
or the customize API in general. Doom is designed to be configured programmatically from your config.el, which can conflict with Customize’s way of modifying variables.

You need to use setq to set the variables to the values you want in your config.el file.

You need to run the doom sync from your terminal if you make a change to init.el (i.e. where you enable/disable language packages)

More detail here: https://github.com/hlissner/doom-emacs/blob/develop/docs/getting_started.org#the-bindoom-utility

Doom and Spacemacs don't require Evil.

https://github.com/syl20bnr/spacemacs/blob/c7a103a772d808101d7635ec10f292ab9202d9ee/core/core-dotspacemacs.el#L103

https://github.com/hlissner/doom-emacs/blob/develop/modules/editor/evil/README.org#removing-evil-mode

Welcome aboard! If you haven't already discovered, Doom has a :checkers spell module for spellchecking functionality. If you're feeling adventrous, or you find the current :checkers spell module particularly slow, I am working on a rewrite of the module in my private config, powered by the much faster spell-fu plugin (instead of flyspell). Copy those two files to ~/.doom.d/modules/checkers/spell/, run doom sync and you should be golden. (Also, don't forget to uncomment spell under :checkers in ~/.doom.d/init.el before you run doom sync).

Good luck on your Linux and Emacs endeavors! If Doom ever gives you trouble, feel free to hop on our Discord where I am very active (much more so than reddit). I'm happy to help!

I'll die on this hill. You can use evil mode and have a vim experience in emacs. Let's not forget the genius doom-emacs either.

In my experience, Doom Emacs configs really streamline the out-of-the-box C and C++ editing experience for emacs (assuming you enable their support by uncommenting thee relevant lines in config.el).

This means you're already familiar with emacs, however, and that's a big time sink. The quickest route without a lot of upfront work is probably Visual Studio Code.

Perhaps you forgot to run <code>doom sync &amp;amp;&amp;amp; doom build</code> after upgrading? Emacs 27 is the recommended version for Doom. I've used it for the past year. Frankly, I want to drop 26 support ASAP, but it won't happen until 27 goes stable and becomes more ubiquitous among various linux distros.

You need wrap configuration for packages in a (after! PACKAGE ...) block, so that your settings overwrite defaults.

The only exception are file/directory variables, like org-directory and org-journal-dir.

See our getting starting guide.

Emacs is indeed slow. This answer in the FAQ is a good response to this question, with a few doom emacs-specific suggestions that may help a bit, but here are two more:

1. Upgrade to Emacs 27. There are major performance gains to be had for LSP users here due to its new and native JSON library.
2. Try the native-comp branch of Emacs. I haven't tried it yet, but other Doom users tell me it make Emacs dozens of times faster, by compiling elisp to native code. I'd recommend hopping on our Discord; that's where these users are most active.

Hope that helps!

Doom emacs has this feature on the spell module. You need to add these elements to ispell-skip-region-alist:

(after! ispell ;; Don't spellcheck org blocks (pushnew! ispell-skip-region-alist '(":\(PROPERTIES\|LOGBOOK\):" . ":END:") '("#\+BEGIN_SRC" . "#\+END_SRC") '("#\+BEGIN_EXAMPLE" . "#\+END_EXAMPLE"))

after!and pushnew!are doom emacs macro, so I don't know what is the proper way to do it outside doom emacs.

I love emacs with org-mode, specifically doom emacs. This allows me to intertwine the todos with the notes I am taking as well as in specific todo files. Furthermore, it allows appointments, scheduling work, tracking status and there is a great agenda view. It is super powerful, but there is a slight learning curve. It also helps that I do all my development in emacs as well. The final kicker is that everything is stored in ascii text files so I can just ripgrep the directory if I'm in a terminal. Furthermore, if emacs for some reason breaks I can still get to my data.

Hi.

You can read this https://github.com/hlissner/doom-emacs/blob/develop/modules/config/default/+evil-bindings.el

Side notes : ctrl-a and ctrl-x of vim are binded to g= in doom because C-x is important in emacs.

All movement are in doom

Register are in doom

g/search/d works

v/search/something works

Macro like vim works.

It s really impressive

Thanks you for the answer.

I checked it now, Doom have been using early-init.el about for 1 or 2 years and they don't document it or I can't found. https://github.com/hlissner/doom-emacs/blame/develop/early-init.el . If I'm not mistaken, they disabled the X resources on the early-init.el.

I'm not sure whether using X-Resources will have more advantages, it looks both of them make the same things but it's definitely worth trying and testing.

I am using Doom, so it is different.

Have a look at how Doom does it

(def-package-hook! evil :post-init (setq evil-vsplit-window-right t) (setq evil-split-window-below t) (setq evil-want-C-u-scroll t))

Note: I do neither use windows nor doom.

The error message means the program make has not been found. But you can build doom without make (see sparse guide link below).

&#x200B;

Infos from documentation:

Doom FAQ states, that Doom on Windows has been reported working. Following the link you get a sparse guide on how to install.

So, find and download a Zip archive for your Emacs version (xx) and your processor architecture (yy) with name emacs-xx-yy-deps.zip from one of the linked subfolders. Then follow the sparse guide without installing make.

Don't give me that slow shit. It's about that fucking Doom Emacs! And I'm not just saying that because I'm attempting to contribute to it but I never actually bothered to fully learn Lisp sematics until just now so I'm just sitting on ideas that I can't fully implement because I'm a Lisp-less heathen.

I really suggest emacs as well. With either Spacemacs or Doom as a starting point for configuration.

It does have a bit of learning curve, but so does everything. The good news is that all the help and documentation is built in. You can get the basics down first then slowly add things as you find them helpful, or remove things you don't like.

A program for writing screenplays is all about writing and manipulating text. Emacs is THE program for that.

You can customize almost anything and set up the environment exactly how you like it. Want spell checking? Gotcha. Expand and contract paragraphs or chapters? It can do that. Want to see every instance where a side character is mentioned, sure thing.

There's a huge package system so that installing new stuff is really easy to do.

I'm actually using emacs to write this post, using Edit in Emacs plugin for Chrome. Because posting on reddit is also all about writing and manipulating text.

The lovely people at /r/emacs will be more than willing to help out and answer any questions you might have. Some of them will go so far as to write a new module to do exactly what you want.

FWIW, here's a bit from Doom's <code>early-init</code>:

;; Contrary to what many Emacs users have in their configs, you don't need
;; more than this to make UTF-8 the default coding system:
(set-language-environment "UTF-8")

uniquify breaks persp-mode, hence uniquify-buffer-name-style is nil when persp-mode is enabled (which is, by default, in doom emacs). See https://github.com/hlissner/doom-emacs/pull/1506#pullrequestreview-253133166

If you’re using Doom, you may want to check out its biblio module. The README is not super detailed but it may be a good starting point. Also, if you’re using a recent enough version of org you can get close to what you want by just using the newish org-cite without extra stuff like pandoc or org-ref.

Here is the github page witg installation instruction.

Nowadays you only need

git clone --depth 1 https://github.com/hlissner/doom-emacs ~/.emacs.d ~/.emacs.d/bin/doom install

Mh. Good question; not sure; think so.

Probably just try copying core-keybinds.el and evaluating in vanilla Emacs.

You'll need:

• IS_MAC and IS_WINDOWS - tiny macros.
• ~~general.el~~ - core-keybinds.el has the use-package for it actually.
• which-key, maybe?
• doom-lookup-key
• Probably some more funcs/vars to track down but I don't think many.

Or you could look here and macro expand pretty print (forget func name) instead of macro expand eval the final general.el sexprs: (nreverse (delq nil doom--map-forms)). And just take those with you to normal general.el.

https://github.com/hlissner/doom-emacs/blob/master/docs/index.org

You want to be on the develop branch and read that readme. I use RLS I believe for code completion. Whichever is the first LSP based option.

Doom has a bunch of "modules" that it has and you need to enable them manually in init.el. Just uncomment or add flags to them. If you want more information about a module that's listed in init.el, you can do M-x doom/help-module to see more information such as flags to enable/disable features and how to use each module. As with anything related to things like Emacs or vim, definitely read the documentation: https://github.com/hlissner/doom-emacs/blob/master/docs/getting_started.org

If you have any question, don't hesitate to dm me.

If it's not a git repo, it has one of the following files/directories in it: .projectile, .hg, .bzr, and .project.

If it is not one of these, then it is likely detecting one of the root files in projectile-project-root-files (see C-h v projectile-project-root-files to see its value). e.g. Cargo.toml, Gemfile, setup.py, package.json, etc. Note that these have lower precedence over the version control + .project(ile)? files above.

For a summary of the steps projectile takes to "determine the current project's root", see these comments.

I would recommand startring with https://github.com/hlissner/doom-emacs

It has vim out of the box

It expose a way to configure it (read readme)

Then, when you get enough knowledge, remove doom and build your config.

That s the only sane way I found to enter in emacs.

I'll just pile on needlessly:

There are no rules you have to follow to configure Emacs, do whatever you want. (Recently David Wilson did a live stream on how to create the worst Emacs configuration). That said, it is recommended that you:

1. make sure it works well,
2. make it so it stays easy to debug when you change things.

Well obviously, but how to achieve this?

Since you came from VS-Code which is more opinionated than Emacs on how it wants to be configured, and since you want Vim keybindings, I highly recommend you use Doom Emacs, which provides you with an easy-to-use configuration system. The &quot;Getting Started&quot; guide is excellent, please read it!

You can take a look at the default init.el file for Doom emacs here, as you can see, there is a :lang section where you can uncomment support for commonly used languages. Although you generally don't change the init.el file too much, usually, it is there to load your actual config files. If your language is not supported out of the box, there are ways to add packages (a.k.a. "plug-ins") in packages.el. And you can add customizations in config.el.

I can indeed; however, I'm using this org-tangle script based on the doom-emacs' version here. Should I just enable the mode in the script?