The Sorry State of Emacs Lisp Package Archives
blog.jorgenschaefer.de
blog.jorgenschaefer.de
Sure, there are problems, but they'll be fixed eventually.
One of these times was yesterday, when cider-test was added to cider. Melpa excludes files ending with -test.el by default, so a file was missing. I grabbed the file manually from github and went on with my evening. An hour or so later the pull request fixing the problem was merged.
For developers, the criticism against MELPA is just FUD. If anything goes wrong you can fix it easily enough.
(The author of the article makes elpy, an excellent Python development environment, where occasionally, a component gets modernized. This is the case right now with the refactoring logic. MELPA gives you a broken elpy, joergen has no reasonable way to override it even for people who also subscribe to his personal package index, etc. :-))
Maybe this is just me being stuck in my ways....
http://inversethought.com/hg/dotemacs/file/b1915cf8617c/pack...
Like you, I'm probably stuck in my ways too. I just don't trust any package manager but Debian's apt. I also don't like this trend of having one (or more!) package managers per programming language.
Probably.
By default Emacs is passable Elisp IDE and nothing more, really. Sure, it has a bunch of neat (disabled by default, mostly) built-in plugins (also tetris and doctor mode), but its main strength lies in how easy it is to extend and customize it. With plugins you first promote Emacs to absolutely outstanding Elisp IDE, then you get beautiful Elisp stdlib (strangely missing from core distribution) and from that point onwards you're already in editor heaven, because you can very easily install and modify every conceivable piece of functionality.
Right now I have 143 packages installed with package.el, about 30 packages installed via git (and cedet via bzr, I also build Emacs from bzr repo for ease of dumping it), 3051 lines of my own Elisp scripts, one package I installed from package.el but later rewrote completely (fuzzy-find-in-project, another 423 loc), another 254 loc in custom-set-variables and dependencies on thousands of lines of Python, Ruby, JS, Clojure, C (for example the-silver-searcher, among other more standard tools) and others.
The thing is, I'd probably have exactly the same Emacs config as you instead were it not for package.el. It's a scary thought for me now - going back to vanilla Emacs (I sometimes use Zile instead of Vim on remote machines) feels like I reverted to using notepad.exe, the difference is just that great. Without an easy way to install and experiment with packages I would probably install manually a few plugins I knew I wanted (because I used them before in Vim) and I wouldn't have moved forward at all.
For example, there is this wonderful info+.el by Drew Adams. Take a look at its Emacs Wiki page - to install it you need to manually download and require some 5 files (which is good, modular design and should be encouraged) which is a pain by itself. I probably wouldn't install it out of laziness. Then I'd never read absolutely fabulous Emacs, Emacs Lisp, Org Mode or Fugitive (cover to cover!) Info manuals, because really, documentation in black-and-white without syntax highlighting just isn't my thing any more (my eyesight getting worse and all). In effect, my Emacs would still be just Emacs instead of being MY Emacs, and I'd probably left it sooner or later (but now I'm being vendor-locked-in with myself being a vendor for most part, which is kind of scary too ;)).
The Emacs I use beats Sublime in terms of features easily and has - after a year of using it - literally thousands of little (and bigger) functions which make me more productive, more comfortable, better informed and plain happier than I'd be with vanilla Emacs. And it was package.el which enabled me to make my Emacs like this.
To my eye, that's a bit of an overstatement. I used a mostly unconfigured Emacs for years to write C, Lisp, and Scheme and found it to be quite suitable.
My approach to customizing it has largely been to identify pain points and then work to find low impact ways of working around them. At first, it was relatively simple things like binding filename extensions to modes and tweaking buffer coloring. Later on, I realized that I wasn't using any of the GUI widgets (toolbar, menubar, and scrollbar) and disabled them entirely. That was shortly followed by an OSX recompile that added a full screen mode, prior to OSX having the feature natively.
I've done some larger scale customizations too, but those tend to be shorter lived and focused on specific projects. When I ran more on Windows, I had cygwin enhancements running in Emacs. I'm doing more Oracle these days, so I have SQLPlus mode linked in. I also work with Clojure mode (essential) and js2-mode (nice, but I could live without it). Because I use git, I tried magit mode, found it to be slow and cumbersome, and switched back to the git command line.
The two longer-term customizations I've found to be useful are a enhancement to org-mode that I wrote to keep a personal notebook/wiki, and a simple elisp wrapper I wrote around Maven for building Java projects. I wrote these to address specific common use cases in my work flow, and as I find pain points, I try to find cheap and easy ways to file them down. Honestly, I tend to keep the customization code as simple as I can, because I'd really like to spend as much of my time on 'real work' as I can, and the editor is just a means to that end.
If you're interested to see what that looks like in Emacs Lisp terms, I've maintain my .emacs here for the last few years. (Prior to github, I just copied the files around, which was as painful as it sounds.)
https://github.com/mschaef/.emacs.d
> Its main strength lies in how easy it is to extend and customize it.
Agreed, but for me, the brilliance is that it makes it easy to write small customizations that are still quite powerful. Eclipse is fully extendable in theory, but the barrier to entry is high due to the complexity. While Emacs does support a lot of that kind of 'big' customization, it also makes it easy to gain small point victories with small amounts of code and complexity.
Another quick example of this is that about ten years ago I was writing a small unit test library for a scheme system I was developing. I really wanted the ability to jump to the source of the failing tests. Getting this done in Emacs was as simple as modifying the format of the test failure messages to match one of Emacs' compile error message formats. Then, the 'next-error' function just did what it should. It took an hour or two of effort and a half dozen lines of code to make a huge difference in my daily productivity at the time.
As it is, I only use one non-ELPA repo to avoid the mess that results from enabling more repos. I would prefer to use e.g. melpa stable, but it supports only git packages, which means many of my favourites are left out.
Homebrew is a joy to use. APT is beautiful. Arch Linux is doing interesting things with pacman. Every scripting language that matters uses a standard, widely known packaging recipe (setup.py, Gemfile, package.json, etc.) that developers can understand in about 15 minutes.
Emacs? Emacs doesn't introduce its package management system until Chapter 47 in the manual. The default repo has so few packages I thought there was an error the first time I saw it. The entire packaging ecosystem screams "this is an afterthought!"
It isn't 1994 anymore. Package management may not be a "solved problem," but it isn't exactly a new problem, either.
I know the Emacs shibboleth is to do everything in Emacs, but we can't be afraid of other options if they've proven themselves to be better.
The built-in tutorial is great for learning to edit with emacs, but I'm looking for something that will quickly explain the state of the nation with regard to emacs package management.
The emacs distribution comes with everything under the sun, plus the kitchen sink already. And I mean it literally.
Loading more packages, without understanding elisp and/or how emacs generally work, doesn't translate to "more productivity" in my mind.
That's how you would approach packages in a sane way:
- you start using emacs - you start tweaking a mode that you use often - you decide the tweak is still not enough and/or you envision a better way to do things - you look up online for an alternative emacs package/mode - you install it
The built-in package manager helps you only with the last step. And to be honest, there's not much that you have to do if you want to install it by hand, because at this point you should be at least familiar with elisp and emacs.
Another important note: elisp packages are mostly "stale". There are some big packages which are continuously improving, but whenever I read some mode sources, I discover they were last updated years ago, and didn't really need any changes.
I used to check for a couple of big packages manually on a year basis before using "package". Now I can automate the task, but I actually only update whenever I have a bug I noticed or I have time to read the full changelog.
You don't want your editor to have different behavior between updates, really.
No it doesn't. There is no php-mode which is nothing other than a leadership failure given that PHP it is a decade(s)-old, top-5 language.
That being said, on debian/ubuntu, php mode is "php-elisp" as an official package that you can install system-wide.
Tricks and tips for experienced users: http://whattheemacsd.com/
General Emacs blogs and news: http://planet.emacsen.org/
I have recently started using Android Studio and it so quick to give you code suggestion aka code completion. It has literally reduced the amount of time I have to spend writing code by many folds. Is that possible in Emacs?
Over the past few months, I have developed an opinion that Emacs is more suited for old school guys who hacked early computers. As someone who started programming with IDEs on modern computer, one isn't really aware of lackings of IDEs, if any.
I used jEdit for a few years, but eventually I needed to program in a language for which there wasn't a good jEdit plugin available. That's when I switched to Emacs. It took me several full days to make the switch, much shorter than I expected it would, but I was far more experienced at that point than I was when I first heard of Emacs.
I wish I had switched to Emacs sooner, mostly because of Org mode, which has changed my life. Even if I were to start using an IDE because of a job requirement or whatever, I would still use Emacs for knowledge management.
FYI, I don't code in Java, and many people who do prefer IDEs, even some Emacs users.
My personal wiki consists of thousands of documents and it's powered by Emacs' Org mode. There are numerous benefits to having a knowledge base stored as plain text files that are managed using a powerful text editor, such as the ability to refer to any document in my wiki in under two seconds. I use my wiki hundreds of times per day, and the thought of using LibreOffice or Word to manage a similarly-sized knowledge base is unpleasant.
Is there a better way?
(mapc (lambda (package) (package-install package)) '(dired+ zenburn-theme))