If somebody is looking for a nice Emacs theme and feels that the OP is a bit too minimal, have a look at my Emacs conf (I know, shameless plug) here 
There's also a screenshot 
This configuration is kinda optimized for Emacs+Evil to be more like Vim, so you may just want to have a look at the theme / plugins.
The other thing is that Emacs is really slow to start as soon as you have a few plugins, compared to vim.
I use the "ec" script show here: http://emacsformacosx.com/tips
will give you a more helpful alias.
"$(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)
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.)
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?
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.
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.
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.
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.
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.
(setq custom-file "~/.emacs.d/custom.el")
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.
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."
(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))))
(message "Auto-%scompiling %s..."
(if (file-exists-p elc-path) "re" "") path)
* Emacs can wrap lines at word boundaries, while intelligently preserving/extending indentation (something like this: https://gist.github.com/anonymous/8581161)
* If you're using emacs on the mac, it's worth taking a look at the railwaycat fork ("brew install emacs-mac"). Some improvements over vanilla emacs: Emoji (and other fun unicode) display works, fullscreen and maximize work better, scrolling with the trackpad works in a reasonable way.
For sane trackpad scrolling in vanilla Emacs I use this:
'(mouse-wheel-scroll-amount (quote (0.01)))
brew install emacs-mac
brew tap railwaycat/emacsmacport
Also, I didn't know about the wrap-while-keeping indentation, that's something I always wanted. Will try it out later. Thanks!
Other features that were important to me were
- Org Mode (I'm using it for all documentation now)
- Usability: As described below, every function in the editor can be accessed with a quick command (with pattern matching to find the correct one) vs. knowledge of arcane commands in vim. Also, most modes offer convenient access to all their features in the menu bar. So when I'm using a Clojure mode, and I can't currently remember the correct command / keystroke for changing the current Repl namespace to my current file, I click the menubar and there it is. All neatly listed. Makes it a lot easier.
- I like the Emacs way of having all in one window. I have one big fullscreen window with multiple buffers, and in there I have a terminal, a repl, multiple code windows, html documentation. So I never have to leave that mode. Keeps me productive. That is also kinda possible with tmux and Vim, but then I always had overlapping keyboard shortcuts for switching windows. All in all Emacs works better for me here.
- Lots of small things, in general Emacs feels like a much more solid editor, with more configuration options to fit it to my liking.
Lots of people dislike vimscript and although I think you can also write plugins using python, it also seems more difficult to interface with.
I know that you can have a big fullscreen window with multiple buffers and a terminal and a repl in terminal vim without tmux. I guess you are not interested but you could see multiple buffers with :vsplit or :split to get vertical and horizontal splits, respectively. There are plugins for a terminal/repl.
Org mode sounds interesting to me, one of the things that I miss from eclipse is that I could see the javadoc when I held the mouse over an object/method/function, is that what Org mode does?
Thanks for the reply.
Org mode is a very sophisticated Todo and documentation and wiki and calendar and management and literal programming system for Emacs. I haven't found anything that compares to it. It is really really good.
The java doc thing is something entirely different, and that's usually made possible by the various language modes.
If I ever do make the switch, I'll definitely still be using Evil mode though. I can't drop vi-editing, and don't want to anyway.
It mostly works as well as in Vim, except if you're using Code folding, which confuses it a bit.
I use (non-relative) line numbers quite often though, and it when I need to tell my colleague that there is this function in some file, on line 323, with a some interesting statement between lines 330 and 336. This makes it extremely easy for them to get to where I am and see exactly what I see; and on the other hand I don't need to move point to those three lines to read their numbers or - absolutely nightmarish - to count the positions manually - they are just there, for me to see.
It would be better to show and hide linum with some simple binding, but I'm already used to them, so it's not a big deal for me.
Move cursor to ninth line above: 9k
Delete from here to seventh line below: 7dd
Copy thirteenth line above after second line below: :-13t+2
Having line numbers always visible (either relative or absolute) helps for doing this operations quickly.
Line numbers are also useful, for example, when doing web development, and hunting down the line that's mentioned in a stack trace. Absent integration between the browser's debugger and Emacs, which is something I've fiddled around with (based on mozrepl) but never got working, that's a good second best.
The original can be found here:
Another nice theme is Cyberpunk:
As jbeja answered, I'm using powerline with the default theme for the status bar:
Can't recommend it enough. Beautiful monospaced font for terminal and editor. And the light version works great on my 11" Macbook Air as it consumes less pixels and therefore allows more code to be visible.
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.
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)
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.
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.
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.
It's correct that we don't want our current packages to build off non-master tags or branches, and that's because we've a bigger picture in mind. It's a concrete goal of MELPA is to provide two parallel archives of packages: the existing one, filled with "bleeding edge" packages, and a new archive containing "stable" packages which have been built from the same upstream sources, but using existing version tags found there. We're making progress with this goal: see https://github.com/milkypostman/melpa/pull/1407, for example.
If we can pull this off, this will yield the best of both worlds: users will get known-good versions of packages, and at the same time they will be confident that the stable packages came from the upstream developer's source tree (which isn't at all assured with Marmalade). It will also make releasing a new stable package as easy as tagging a source repository.
Recent versions of `package.el` allow packages to be pinned to specific package archives, which lets those concerned about bleeding-edge breakage pick and choose between "stable" and "unstable" packages on a case-by-case basis.
Even though it is "manual", i prefer stability of my programming environment over the ability to install packages "quickly".
Don't you want a nice Nyan Cat in that modeline in the sky? ;).
And don't you want the current weather to go alongside your Nyan, thanks to an Emacs minor mode inspired by a Hacker News comment?
Mind if I grab a copy of this image, to use with whatever attribution you like, on the repo README? I don't use nyan-mode myself, and it'd be nice to have the screenshot to show people who find the repository.
I'll put link to and/or a screenshot of your project somewhere in the Nyan Mode page/readme, as you wrote it was inspired by a comment about Nyan Mode ;).
It's silly and I'm glad you made it.
Could you tell me (or open an issue on Github) how it breaks other plugins?
Meh, I have lots of changes to add, but I keep procrastinating here on HN instead...
On the other hand, I love the simplicity of the UI of emacs. But I don't love how it's decidedly focused on text-only and its GUI is a second-class citizen. (Try scrolling per-pixel rather than per-line, and consider that tabs can only be implemented as a complete hack based on the ruler area.)
I love that Emacs Lisp compiles to bytecode and is interpreted natively. I love the simplicity of the language and its implementation and how it's integrated with Emacs. But I don't love the language itself.
I tried writing it in C and Objective-C. But this isn't cross platform for starters. Plus, C is really hard to extend cleanly using a scripting language.
I've deleted the project since, but there are probably forks floating around. I'll probably give it another shot one day when I learn more.
I know I'm keeping an eye on lighttable (I'm an emacs users since forevs) -- it's definitely the only modern editor that seems geared to possibly being a match for emacs in the flexibility and customizability departments.
But of course, historically, emacs just incorporates whatever's interesting in other editors and continues on, more powerful than ever.
It's the borg of editors.
LightTable shows great promise as an editor and it's design makes it well suited to being an environment in the future.
I'm just worried that before LT gets to become what I want it to Emacs will already have what is attractive in LT. For me it's ClojureScript and much more flexible UI. If Emacs gets Guile as it's scripting language (and I think: Scheme > Clojure > Elisp) and it's UI somewhat reworked (and threads, and easy bindings to compiled code - all of which is being worked on or at least seriously considered), the decision to migrate to LT will get much harder.
Anyway, LT is the only possible choice for me other than Emacs. There is no other editor which could replace Emacs for my use cases and I don't see new ones emerging.
As a side note: I have some hope for editor embedded in Pharo. It got much better this year and continues to evolve, and being a part of Smalltalk image it is very easily hackable. Having strong editor with things like Moose/Roassal/Glamour natively integrated would be a huge win, but that's probably something I will need to do myself :)
I would really like to contribute somehow to Pharo development, it's absolutely fantastic piece of software. I went through tickets on official bug-tracker, but there are many of them and it's hard to tell which are important and which are being worked on. (BTW: Komitter is a very nice idea!) I didn't write to the mailing list, because I don't have (especially lately) enough time to do anything substantial; I just wanted to get some simple regression (for example) which I could fix in a couple of minutes/half an hour. The section of bug tracker with tickets like this would be a great help. Otherwise I'll certainly try to get involved more once I have a bit more free time :)
wait, let me back up for a moment wrt the original article. that screenshot in the article is not emacs. i can't give you a screenshot of emacs, because emacs doesn't even depend on a windowing system for near-maximum awesomeness. it is my go-to text editor, and i very likely will (progn several of these snippets into my .el files.
that said, we do have have windowing systems now, with some better ones on the way, not to mention touchscreens. i haven't tried out lighttable yet, but i intend to, and i greatly hope that either (1) lighttable follows in emacs footsteps of being fully scriptable (as opposed to the adopting a plugin model that's so typical of java ides) or (2) emacs devours all of that beyond-code-folding -- how best to say it? -- code-exploding (?) awesomeness that lighttable attempts to bring and that, to me, appears to map perfectly onto this new world we find ourselves in where computers are not giant boxes attached to printers anymore but are, instead, whole buildings attached to touchscreens.
doesn't matter if your program's a crocodile or wildabeast: adapt or die.
To me, LT could be Emacs with better rendering.
I really enjoyed learning Emacs, its a great design, like an open-world game. I want more apps to capture that.
Inline documentation doesn't seem all that desirable in the first place; from the screenshots I've seen, it looks like it would get in the way, which documentation in a separate buffer doesn't do. (I'm half tempted to implement inline documentation for Emacs Lisp mode as a proof of concept, mind you, but I really don't see the point of it.)
Fwiw, it was added in Emacs 21 (2001): http://www.gnu.org/software/emacs/manual/html_node/efaq/New-...
Previously that had been one of the differentiators between GNU Emacs and XEmacs, the latter more enthusiastically adopting GUI-, image-, and mouse-related features. I believe XEmacs got inline-image support sometime in the mid-'90s, and showed it off by including a display of the XEmacs logo in the default startup buffer.
Well, except for every time you start Emacs :-)
(Yes, assuming you haven't disabled the splash screen)
Emacs finally has a really nice package manager, so I'd love to see a version with minimal default packages. Do I really need java-mode if I never, ever will use Java? Calc when I have R? SMTP support? No, I need absolutely none of this.
I don't get why this is a problem - almost everything that comes with default Emacs installation is not loaded by default and so you don't even need to know it's there. Or you can just remove these modes altogether from your installation, no problem. On the other hand, if something made it to the Emacs core, it's probably more stable and easier integrated with other plugins. There are many plugins in the wild which do a great job by themselves, but fail miserably in the presence of other plugins enabled, and such plugins are not in Emacs (or I didn't see them yet).
Stock Emacs also seems to want to open up a minibuffer when I've told it "please just edit this set of files". It's also got some idea that I want to to suspend the shell I launched it from (er, no, not ever).
The argument I see on forums is: "Well, the right way to use Emacs is to just start it and then never leave, so you only have to get that stuff out of the way once."
So I spend 30 minutes figuring out the right elisp stuff to disable so I can get rid of the crapware.
Crapware in Emacs. What's next, AOL sponsorship splash screens?
I automatically run
In my .zshrc and .bashrc files, I use the aliases
alias e='emacsclient -t'
alias vi='emacsclient -t'
I'm not sure if this addresses your problems entirely, but it does keep you from having to deal with all of the crap that loads on startup.
At this point, I'd be happy if I could just embed iTerm2 in a buffer and be done with it.
The only vi command I know is :q!
Just startup emacs (24+) with the init.el and it will download dependencies from elpa. Will have to restart once afterwards to make the theme right.
Screeshot : http://i.imgur.com/2wmxir5.png
In a perfectionist "must be a pure gem, no imperfections allowed" sense, ton of seemingly unnecessary libraries is the only thing that actually bothers me about The Editor.
I like getting rid of toolbars and such, but still like to keep the modeline and gutters.
"C-M-%" is pretty much impossible in the terminal. You have to do "M-x query-replace-regexp", or make some other custom binding.
A lot of interaction then happens with a type-out buffer which comes down from the top and disappears when not needed.
Because obviously it would deprive a reader to explain how to remove GUI widgets from an emacs frame [window], without making a metaphor of the window as a naked female, and the widgets as clothing, and the process as a striptease. This is exactly how a mature team of mixed-sex professionals discuses emacs widgets. An HN thread on removing emacs widgets without overt sexual analogies  would be a unnatural, stilted place full of repressed sad people.
This could just as easily be a man, woman, android or RMS himself stripping (and considering that the whole post is at the backdrop of an RMS quote taken deliberately out of context, I wouldn't be surprised if it was meant to evoke the latter).
When I started reading, I was worried that this is what the article was going to be about.
This is actually a great feature in online debates when you want to find something to argue about. In particular, this feature doesn't force the first party to explicitly state offensive things in order for the third party readership to take offence. I call it, offence inference. Can a sentence be interpreted in an offensive light, by anyone? The offence inferer will find the implicit offence!
Personally I thought "striptease" was a much richer metaphor for what the linked article showed - the removal of "dressing", piece by piece. But then I'm not a prude with a stick up my ass.
Alas, I must confess that I have written Visual Basic (VBscript) code in Emacs.
A while back I was screwing around with a project which attempted to generate, via the Windows speech synthesis API, output vaguely resembling SHODAN from the System Shock games (example: ). The most I can say for it is that I didn't entirely fail; despite having access to a quite good female voice (NeoSpeech "Kate"), and despite SAPI 5 offering what I found a surprising degree of flexibility, there's only so much you can do with it; I got closer than I expected, but not close enough to think it worth releasing. [a]
In any case, VBScript is the handiest way I could find to screw around with SAPI, and it turns out there is a Visual Basic mode for Emacs ; I found it to be remarkably not bad. Nothing could make working with Visual Basic other than painful, but Emacs comes as close as anything else I've ever used.
[a] I've just unearthed it, and it hasn't yet succumbed to bit rot; maybe I'll throw it up on my Github account just for the hell of it.
Anyone know how to achieve a "fringe" on the top and bottom? And also how to do it in xterm windows?
This option specifies the size of the inner border (the
distance between the outer edge of the characters and the
window border) in pixels. That is the vt100 internalBorder
resource. The default is ``2''.
Scroll bars and menu turned off. Theme solarized and transparent background. I feel good when I am programming :)
I take for instance the most common commands I use in Vim to edit with that I use 95% of the day and they're rarely more than a single character or 3 at the most.
I recently discovered an emacs package that lets me type M-x and then the first letter or two of a command that I used recently and it completes it for me from there (smex.el). That's even easier than coming up with a new keybinding.
Just to try and help you understand how emacs users see it, your most common vim commands that are a single character are actually sometimes a single character and sometimes they need to be prefixed by an ESC to get you into the right mode. That inconsistency is what killed me when I tried to use vim. In emacs every command is always the same, no need to keep track of what mode I'm in.
./configure --prefix=/usr/local --program-prefix=t --without-x11 --without-all \
&& make -s bootstrap && sudo make -s install
It looks great when it combine it with amber-on-black Glass Tty in my xterm.
For vim I like to use
" remove the toolbar
" remove scrollbars
autocmd GUIEnter * set fullscreen
Until I break the habit, thank God for undo.
;; these patterns allow a new frame to open for their matches
(remove-hook 'same-window-regexps "\\*info\\*\\(\\|<[0-9]+>\\)")
(remove-hook 'same-window-regexps "\\`\\*Customiz.*\\*\\'")