I try out emacs every few years. Every time, I get discouraged whenever I attempt to do something simple (change the theme, etc) by the amount of configuration necessary. I may try your repo, since it seems to have a lot of stuff already configured.
The other thing is that Emacs is really slow to start as soon as you have a few plugins, compared to vim.
Slow emacs startup isn't a problem thanks to the new emacs-server stuff. Running emacs with the "--daemon" flag will cause it to do initialization, fork into the background, and become persistent; now edit files using commands like "emacsclient $filename". Eamcsclient will connect to the daemonized emacs server and have it open $filename, bringing it forward either in an existing frame or (using the "-nw" or "-nc" flags) creating a convenient new frame to edit with. Not only does this give you the ability to get into emacs without going through init, the server will maintain all of your editing in the same process so you don't have to manage editor instances.
I run Emacs on Mac OS X as a server. What I don't do is "emacs --daemon". I launch Emacs and then "M-x server-start RET". This seems to avoid any weird issues.
Huh. This works for both -t and -c in emacsclient, with a vanilla build of pre-24.4. It didn't for ages, so thanks for getting me to check this out again!
I'm not very familiar with OS X, and I've had a lot of trouble finding the magic invocation that'll get an Emacs daemon running with the same behavior to which I'm accustomed on Windows and Linux. This looks like it should do the trick, thanks! Now if only I could get emacsclient to behave sensibly in the dock, I'd really be cooking with fire...
I wish I could muster the energy to figure out how going that particular route is flawed. I just know that it's one of the ones I tried, and I learned the hard way that it's got problems.
If you run it with --daemon, the server process doesn't create a frame of its own, but only listens for connections from emacsclient instances; IIRC it also rebinds C-x C-c to delete-frame (also available at C-x 5 0), and the daemon process stays alive through everything short of M-x kill-emacs or similar.
;; schedule starting of Emacs server after everything else is loaded (5 min
;; *should* be anough for startup :))
(run-at-time "5 min" nil 'server-start)
in my .emacs - this way I get both a window and a "daemon" server for use with emacsclient. I think it dies if the first frame is closed, though.
at the end of your init file, and it'll behave more or less as you intend; if you've got a lot of stuff hanging off after-init-hook, you might do well to hang server-start off it as well.
That said, yeah, it will create a window which if killed will shut down Emacs, so I tend to prefer invoking it with the --daemon option instead; that way, I don't have to worry about accidentally killing Emacs if I kill the wrong frame. (I also call server-start in my init file, but I'm not actually sure that is necessary when invoking Emacs with --daemon.)
If you're on a Mac (as I am) it leaves an Emacs application running (complete with menu bar and app switcher icon) that you can't interact with. But otherwise, --daemon works great.
I'm on Mavericks running Emacs 24.3 installed through `brew`. I invoke `emacs --daemon` once when I start work and I have an alias and an Automator workflow to open files in GUI `emacsclient`s. No problems at all. What sort of issues are you seeing?
When, a few years ago, I really started to get serious about using Emacs, I spent three days or so going through the customization options for pretty much everything, or at least everything I could figure out at that time, and adjusting it to taste. Since then, I haven't had to touch it except for minor tweaks. Emacs is what they used to call "a moby frob"; some initial investment is required, and it took me three or four tries before I had the perseverance to stick with it, but the payoff has been handsome indeed.
As for slow starting, the best way to solve that is by running an Emacs server, and creating and killing client frames at need. You only pay the startup cost once that way, and all your editor instances share history, buffers, and everything else, which is sometimes handy, and doesn't get in your way otherwise.
The slow emacs startup problem can be mitigated by lazily loading custom modes as much as possible. The two big things to use here are autoload (instead of require) and eval-after-load.
On my machine, a vanilla emacs startup is ~70ms, and one with my fully-loaded .emacs is ~240ms. Still not as fast as I would like, but not terrible. (You can benchmark emacs startup from the command line with "time emacs --eval '(save-buffers-kill-emacs)'").
(Of course, even a 70ms startup for vanilla emacs is arguably pretty bad -- it's way slower than the ideal of "instant"; I just checked and vanilla vim is something like 8ms, for example, which is just-shy of imperceptible.)
Using the Customize interface also helps. Variables that are customized go in a big list and don't get set individually, nor do they require their library to be loaded before they've been set.
A few years ago I went through my 10 years of accumulated .emacs cruft and switched everything I could to customize, and everything I couldn't to the technique you describe. I sped my emacs startup time from eight seconds down to one.
On top of that I switched to using emacsclient which makes startup instant.
Nice, I didn't know customize was faster. I'll have to try that.
emacsclient doesn't really work w/ my workflow -- when I want a new emacs, I really want a new emacs. Also worth noting you get something similar "for free" when using the gui emacs on MacOS, via open -a Emacs (I use an alias).
I wonder if you couldn't somehow snapshot the state of emacs and dump it for a truly fast startup?
If you try my repo, have a look at the custom keys that I defined, that helps things a lot.
Also, the one great feature about Emacs is MX (which I bound to CMD-.
This opens the minibuffer where you can execute arbitrary EmacsLisp functions. Everything you do in Emacs (even arrow up, left or right) is bound to an Emacs function. So if you start out, and you want to do something, but you don't know the shortcut, just do CMD-. and start typing. The naming is really good. Say you want to deactivate line truncation. You go into MX and type "truncate" and among the results will be "toggle-truncate-lines" you go there, hit enter, and you're done. This is a bit more difficult in stock Emacs, as it has no wildcard search for MX but I'm using the Helm plugin, which offers this feature and makes it really really easy to find functions. I hardly ever use all these Emacs shortcuts like C-c C-e ... I just hit MX and type what I need to do.
Sadly, startup is still really slow for my configuration, which is why I have a Vim config with similar keys for quick Terminal usage. I start Emacs in the morning and keep it open all day. When I need to quickly fix something in the Terminal, I use Vim.
An excellent point; having a command line in your editor is something whose value is hard to recognize until you've tried it, and hard to overstate once you're used to it.
It might, though, be worth using the typical Emacs nomenclature for key sequences, i.e. M-x where you use 'MX' and (assuming your Command key is bound to Meta, as is ordinary for OS X Emacs users) M-. where you use 'CMD-.' -- your choice of preferred nomenclature is of course up to you, but using the standard forms makes it easier for other users, particularly neophytes such as the one to whom your advice here is directed, to understand what you're describing and relate it to the Emacs manual and to whatever other resources they're using.
I changed this because I found M-x to be really really difficult to type. It may be my hands or my fingers, but I have a hard time doing that key sequence correctly. Apart from that I think that you're absolutely right. I shouldn't have advertised this as it will probably confuse users.
Well, there's nothing wrong with rebinding M-x; that key combination requires a lot of hand scrunching, which can get uncomfortable after a while. Nothing wrong with talking about it, either! I'd just recommend describing it in accord with the conventions for Emacs key sequences, is all.
I switch between Vim and Emacs depending on mood. It's a very hard deal: Emacs is a plateform that can do a lot of things besides editing, but it requires a lot of configuration fiddling, and is a bit too slow on the old machine on which I'm using it (must be a single core Pentium with Mandriva 9). Vim has a lot of things right off the box and is fast, but you have to use other programs to have a comfortable environment (mc, screen, ...).
Anyway. The trick with Emacs is to customize incrementally. Also, use customize-option as much as possible instead of editing your .emacs; too often people make you insert lines in your .emacs when already customization exists. Also, use the package manager (list-packages) that Emacs acquired recently instead of fetching from emacswiki or a github repo. It compiles automatically stuff, so it might help with startup times.
I switched to Emacs after being very impressed with nxml-mode. I found no better xml editor on Linux.
Emacs is great if there is a mode that's written for what you're doing--for instance, nxml-mode. I can imagine it's also great for C, for instance, because that mode is old and has seen lots of work. For lisp I'm sure Emacs is peerless.
Emacs is not so great if there's not a good mode for you. I grew frustrated trying to edit Haskell in Emacs; there are a bunch of half-baked modes out there. The problem is that without a good mode, even basic tasks like indentation are painful in Emacs, while Vim will indent anything well without a specific mode.
Often cited as Emacs' biggest advantages is how it integrates with other tools or, perhaps, how Emacs can become those tools. You can run your debugger in Emacs. You can read mail in Emacs. You can do version control in Emacs. The problem is that Emacs is never truly good at any of those other things. Running a shell in a buffer has problems. (You can run a shell inside a real terminal emulator in Emacs, but by that point you might as well just use a real terminal outside of Emacs.) Emacs is not a great mail reader. It's not great at doing version control and, what's more, it doesn't keep you from having to learn your underlying VCS, so now you have to know two ways to do things. Same goes for dired--it's a completely different way to manage files, but you still need to know how to use a real shell, so it just ends up being too much trouble to learn dired.
The thing is, when you strip out all the other stuff Emacs is supposedly good for--managing files, being a terminal, etc.--all you're left with is a middling editor with a good lisp interpreter. That other stuff is supposed to make Emacs great, but it all ends up being middling too.
So I have switched back to Vim. It excels at being an editor and doesn't try to do other stuff. In some ways Emacs is still better (for instance its support for multiple "frames" is something Vim can't get close to.) But with Vim I spend less time fiddling with the editor and more time editing text. If I ever need to do something for which there is an outstanding Emacs mode (edit XML, for instance) I will load up Emacs for that. But without a good mode Emacs is not worth it.
The indentation doesn't work well. It gets the indentation right maybe 80% of the time, but missing it 20% of the time is a big deal when you have to deal with the "tab-cycle." I spent so much time fiddling with indentation that I turned off auto indentation...and Emacs without mode-based auto indentation is much worse than Vim with manual indentation.
I also had problems with inferior-haskell-mode. I could have tried to fix them but I was fed up with futzing with Emacs, especially when I can go to Vim and just use ghci in a terminal.
A response might be "but you can use ghci in a terminal and still use Emacs." Which is true, but then I'm using a not-so-great editor that's not fulfilling its promise of integrating other tools. What's the point?
> Have you tried magit?
Yep. I still need to know Git and its command-line interface. With magit I was spending time learning magit, but not getting functionality beyond what the Git command line offers. Not worth it.
It seemed to me I was spending time learning tools in order to justify my use of Emacs. That's backward, so I stopped. I could have kept using Emacs without the other baked-in Emacs tools...but then you're just left with an editor. In that case I will pick Vim since it's the better editor.
Yep, tried all three, and looked at at least one mode that someone else is developing to see if it had better indentation. I don't remember the names of the three indenters being all that distinguishing, so I had to keep notes in my .emacs just to tell them apart.
One good indenter (maybe with options to select how to style your code) would be better than three. I remember reading a blog post about how hard it is to indent Haskell automatically. It breaks my chain of thought though to have something automatic that works only most of the time. It means I routinely have to stop to fiddle with the editor to make it indent correctly.
I see where you're coming from here. But my conclusion was that Emacs with Evil is just as good an editor as Vim. And as a bonus I get the complete customizability of Emacs.
So when you say "I will pick Vim since it's the better editor," what Vim features in particular (beyond modeful editing, which Evil provides) make you say that?
This is exactly my point. The Emacs mentality is that Emacs can do everything...it can even be Vim. Why should I do that when I can just use Vim? Maybe Emacs can do anything, but it doesn't do anything well unless you've got a dynamite mode. Evil is not going to be as good of a Vim as Vim. I can tell that even with a glance at the Evil website. One of the best things about Vim is the extensive documentation. Evil just has a 22 page PDF manual...lots of which is filled with Emacs Lisp. So if I use Evil, I then need to spend time learning Evil and how to customize it with Emacs Lisp. Or I can just use Vim.
I was hoping I could get a "minimal" setup to edit Python code, and even that was too much to ask for. "Code folding? What's code folding precious? What's code folding?" --Smeagol
Apparently "minimal" doesn't apply to Emacs. Being complex is in its nature. It wants to become everything.
The worst was how every time you open a different file, your `CWD` always changes to that file's location.
Interesting, I consider that a great feature. That always bugged me in Vim. When I open a file in a different location, most of the time I want to be in that CWD. I guess it depends on how people work.
Oh, yeah, that drives me crazy too. Usually, I cd to the root of whatever project I'm working on, and I want all paths to be relative to the root of that project (though since I started to use ctrlp[1], it's less relevant).
> The other thing is that Emacs is really slow to start as soon as you have a few plugins, compared to vim.
This just mean you are "doing it wrong". Your .emacs file should not be loading anything, but instead setting things to be loaded when needed using autoload, eval-after-load and auto-mode-alist.
Also make sure all your plugins are byte-compiled, this can shorten loading time significantly. Not a problem for elpa/package.el plugins, but I have quite a few plugins managed manually (I'm still not using el-get, shame on me) and the way I byte compile them all at once is to place a cursor on a directory with them in dired and issuing:
C-0 M-x byte-recompile-directory
The C-0 prefix arg causes it to recompile everything without asking for confirmation for every file.
You could automate this with a function hung off the after-load-functions hook. Here's something off the top of my head:
(defun foo-compile-if-newer (path)
"A function suitable for hanging off `after-load-functions',
which will byte-compile an Emacs Lisp source file for which there
is no pre-existing compiled file, or there is a compiled file
older than the source."
(and (save-match-data
(not (null (string-match "el$" path))))
(let ((elc-path (byte-compile-dest-file path)))
(if (or (not (file-exists-p elc-path))
(time-less-p (nth 5 (file-attributes elc-path))
(nth 5 (file-attributes path))))
(progn
(message "Auto-%scompiling %s..."
(if (file-exists-p elc-path) "re" "") path)
(byte-compile-file path))))))
(add-hook 'after-load-functions
'foo-compile-if-newer)
Adding an exclusion list, if you feel the need for one, is left as an exercise for the reader.
It's possible that both of you are actually right, depending on the package. For example, "plugins" (such as Flymake, or modern variants) can indeed cause the editor to slow to a crawl. Likewise, I had to turn off real-time spelling checking for LaTeX documents in Emacs for this very reason -- on dissertation-size documents it was simply unbearable, and every few sentences the editor would just spin for a bit [2].
The other thing is that Emacs is really slow to start as soon as you have a few plugins, compared to vim.