dsdshcym / dsdshcym.github.io

https://yiming.dev/
1 stars 1 forks source link

Compare Doom-emacs, Spacemacs, and vanilla Emacs - Yiming Chen #12

Open utterances-bot opened 4 years ago

utterances-bot commented 4 years ago

Compare Doom-emacs, Spacemacs, and vanilla Emacs - Yiming Chen

undefined

https://yiming.dev/blog/2018/01/22/compare-doom-emacs-spacemacs-vanilla-emacs/

goofansu commented 4 years ago

Nice post, thanks. I searched with "spacemacs vs doom" and found the the post , I think I'll give doom a try.

AtomicNess123 commented 4 years ago

Hi, have you tried Prelude? I am having this idea of whether it is best to just fork a distribution that I like and build on top, since the updates always are going to bring uncertainty.

goofansu commented 4 years ago

@Gahamelas If you are familiar with Vim, I recommend doom-emacs.

AtomicNess123 commented 4 years ago

I'm actually not familiar, just been using Emacs for a couple years. Would that be alright? What is different?

dsdshcym commented 4 years ago

@Gahamelas Sorry for the late reply.

I only tried Prelude once, but it doesn't support evil very well so I didn't use it for long.

That being said, I would not recommend to fork a distribution and build on top of it. Because merging from upstream with your customizations is a lot of work.

Instead, I'd recommend:

  1. if you want a stable experience, build your own configuration and stick with it. (When I use my own configuration, I only update it once every few months, and it's really stable to me)
  2. if you want regular updates but don't want to manage it, try different distributions and choose the one whose default makes the most sense to you. (I chose doom-emacs because it matches my expectation and I only need to build a very thin layer upon it)

Hope these opinions can help!

AtomicNess123 commented 4 years ago

Thanks. So you recommend not forking because (as I learned today) when a original repo is deleted, its forks are also deleted, right? But what about cloning it? The idea wold not be to merge from upstream, becasue if I work on it, then it makes no sense to merge changes into it made by others. This is the same as you suggest: build your own config and stick with it. The only difference is that my confif is a clone of a existing distribution, on top of which I build more.

dsdshcym commented 4 years ago

@Gahamelas

when a original repo is deleted, its forks are also deleted

I don't think this is true. Because one usage of fork is to keep a repo alive if the original one is deleted.

I don't recommend forking because the maintenance work is a lot if you want to keep up-to-date with upstream.

If you don't merge from upstream, then it makes total sense to build upon it and it's the same as building your own config.

So go for it and maybe share your experience here :)

AtomicNess123 commented 4 years ago

Yes, you are right. Here says that:

When you delete a private repository, all of its private forks are also deleted When you delete a public repository, one of the existing public forks is chosen to be the new parent repository. All other repositories are forked off of this new parent and subsequent pull requests go to this new parent.

You got the idea: one can fork and use it as their own never pulling from upstream.

smallwat3r commented 3 years ago

In Doom Emacs you can easily exclude unwanted packages using the disable-packages! macro in your packages.el file.

For instance:

(disable-packages!
 solaire-mode
 evil-snipe
 better-jumper)