The other thing is that Emacs is really slow to start as soon as you have a few plugins, compared to vim.
"$(brew --prefix)/opt/emacs/Emacs.app/Contents/MacOS/Emacs" --daemon ;; 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)
(server-start)
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.)
I use the "ec" script show here: http://emacsformacosx.com/tips
will give you a more helpful alias.
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.
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.)
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.
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?
M-x customize-theme
M-x package-list-packagesAlso, 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.
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.
Instant on.
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.
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.
What's wrong with the normal haskell-mode? https://github.com/haskell/haskell-mode
(interestingly another commentator here claims that Emacs' Haskell indentation is superior to VIM's https://news.ycombinator.com/item?id=7111521)
> It's not great at doing version control [...]
Have you tried magit? It's probably the best version control support I've ever seen in an editor.
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.
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.
It's a bit unfortunate that there have to be three separate indenters, but most people find that one of them is good enough.
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.
[1]: https://github.com/chrisdone/structured-haskell-mode
[2]: https://www.youtube.com/playlist?list=PLlzKKtH5TyE-R-k86na3b...
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.
(setq custom-file "~/.emacs.d/custom.el")
(load custom-file)
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.
[1] http://flymake.sourceforge.net/
[2] http://ergoemacs.org/emacs/emacs_spell_checker_problems.html
C-0 M-x byte-recompile-directory
(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)