4 ms·

I switched to Emacs a year and a half ago when I started using Clojure, and customized it heavily for the first few months. But I avoid customizing it any more.

I switched to Emacs a year and a half ago when I started using Clojure, and customized it heavily for the first few months. But I avoid customizing it any more. I'm never truly satisfied with what I end up with, and I hit too many frustrating walls trying to make it just right. One major problem for me is the plugin ecosystem. There's Melpa which is easy to use and has the most up-to-date packages, but they're built off of HEAD which makes them extremely brittle. Many plugin authors decry Melpa and say that if you installed their package from it, then you're on your own. There's also Marmalade but I haven't found it to have nearly the same scope of packages.

bzg 13y ago
Actually, I'm also on the "less configuration, less trouble" side. That's why I like some minor mode to let me get rid of what I don't want to see, sometimes.
- pivo 13y ago
  Agree with the less is more idea when it comes to configuration. An additional benefit to this is that it's more comfortable to use vanilla emacs when you need to work on hosts you don't typically use.
FraaJad 13y ago
I like this approach to package mgmt. https://github.com/overtone/emacs-live https://github.com/overtone/emacs-live Even though it is "manual", i prefer stability of my programming environment over the ability to install packages "quickly".
NigelTufnel 13y ago
I walked almost the same path. For the first couple of months I was customizing the hell out of Emacs. Then the things started falling apart and I've switched to the 20-line long .emacs and empty .emacs.d (well, almost empty if you don't count key-chord/ace-jump-mode combo which makes file navigation a mindreading experience)
- kirubakaran 13y ago
  Thanks for mentioning ace-jump-mode. I thought that I had a pretty extensive Emacs setup, but it is now much better with ace-jump-mode.
dotemacs 13y ago
Are you sure that MELPA has issues? I've been running with it since it started and one thing that I can say about it is that its been a joy to use. Hats off to milkypostman & sanityinc for maintaining it. If you do have an issue, I suggest you open it on MELPA's GitHub issue page and I'm pretty confident that you'll get a quick response. As for tweaking Emacs' config, yea, I have to admit, I've spent time on it too and things can always improve.
- sdegutis 13y ago
  The issue Melpa has is that it builds from HEAD, whereas many package authors treat HEAD as a working state that should not be used directly. Melpa doesn't (or didn't last time I checked) have support for building off tags or non-master branches, which would solve this. And if I remember correctly, when I raised this issue, he disagreed on some philosophical grounds. So it's an inherent problem in Melpa.
  - technomancy 13y ago
    On IRC we get a steady stream of confused users (in both the #emacs and #clojure channels) who added melpa because some library recommended it in their readme and they didn't realize it would cause every package they use to also pull from the unstable branch. It is a huge support headache. However, these days I only very rarely find packages that aren't available on Marmalade. When I do, it's usually enough to ask the maintainer nicely and they start publishing to Marmalade; it's not a difficult process by any means.
    - sanityinc 13y ago
      Hmm. Is there a particular repeated source of breakage? I only use MELPA, and apart from the recent nrepl->cider migration (which was intentionally piloted on MELPA) I've not had any instances where my work was hindered by package issues. And as a maintainer, I update my packages daily.
    - dotemacs 13y ago
      Fair point. But one of the issues with Marmalade is that anybody can fork your project (patch it or not) and just push it. With MELPA, they try to get the original authors to submit the projects. If you've got patches, they are pretty strict about it and encourage you to get them merged in the package rather than accepting a fork.

bzg 13y ago

Actually, I'm also on the "less configuration, less trouble" side. That's why I like some minor mode to let me get rid of what I don't want to see, sometimes.

pivo 13y ago
Agree with the less is more idea when it comes to configuration. An additional benefit to this is that it's more comfortable to use vanilla emacs when you need to work on hosts you don't typically use.

FraaJad 13y ago

I like this approach to package mgmt. https://github.com/overtone/emacs-live https://github.com/overtone/emacs-live Even though it is "manual", i prefer stability of my programming environment over the ability to install packages "quickly".

NigelTufnel 13y ago

I walked almost the same path. For the first couple of months I was customizing the hell out of Emacs. Then the things started falling apart and I've switched to the 20-line long .emacs and empty .emacs.d (well, almost empty if you don't count key-chord/ace-jump-mode combo which makes file navigation a mindreading experience)

kirubakaran 13y ago
Thanks for mentioning ace-jump-mode. I thought that I had a pretty extensive Emacs setup, but it is now much better with ace-jump-mode.

dotemacs 13y ago

Are you sure that MELPA has issues? I've been running with it since it started and one thing that I can say about it is that its been a joy to use. Hats off to milkypostman & sanityinc for maintaining it. If you do have an issue, I suggest you open it on MELPA's GitHub issue page and I'm pretty confident that you'll get a quick response. As for tweaking Emacs' config, yea, I have to admit, I've spent time on it too and things can always improve.

sdegutis 13y ago
The issue Melpa has is that it builds from HEAD, whereas many package authors treat HEAD as a working state that should not be used directly. Melpa doesn't (or didn't last time I checked) have support for building off tags or non-master branches, which would solve this. And if I remember correctly, when I raised this issue, he disagreed on some philosophical grounds. So it's an inherent problem in Melpa.
- technomancy 13y ago
  On IRC we get a steady stream of confused users (in both the #emacs and #clojure channels) who added melpa because some library recommended it in their readme and they didn't realize it would cause every package they use to also pull from the unstable branch. It is a huge support headache. However, these days I only very rarely find packages that aren't available on Marmalade. When I do, it's usually enough to ask the maintainer nicely and they start publishing to Marmalade; it's not a difficult process by any means.
  - sanityinc 13y ago
    Hmm. Is there a particular repeated source of breakage? I only use MELPA, and apart from the recent nrepl->cider migration (which was intentionally piloted on MELPA) I've not had any instances where my work was hindered by package issues. And as a maintainer, I update my packages daily.
  - dotemacs 13y ago
    Fair point. But one of the issues with Marmalade is that anybody can fork your project (patch it or not) and just push it. With MELPA, they try to get the original authors to submit the projects. If you've got patches, they are pretty strict about it and encourage you to get them merged in the package rather than accepting a fork.