* Sticky modifiers: I don't know why it took me so long for me to activate these. The difference between holding Ctrl while hitting another key or just hitting Ctrl once before the next key makes a huge difference for me.
* Got an old-styled Thinkpad keyboard with the trackpoint buttons below the spacebar? I mapped the left button to C-x and the right one to M-x. These buttons are PERFECT for this purpose. I would have mapped them system-wide to Ctrl and Alt but didn't find a solution for doing that in Debian (console/tty).
* Helm: Incremental completion and selection narrowing. Makes it a lot easier to find those commands which you sort-of-remember-the-name-of:
* Sunrise Commander: MC-ish file explorer, based on Emacs's Dired:
My emacs skills are still probably only 1% of his, but after working that short time with him I have never been able to fully feel comfortable using textmate or sublime text. I always come back to emacs, even though the learning curve even years later is still there. Just feels like the right tool to me.
> I always come back to emacs ... Just feels like the right tool to me.
Sounds like a mild case of Stockholm Syndrome... ;)
The Pai Mei school of teaching. http://www.youtube.com/watch?v=fCbf4DjlHuM#t=0m31s
Gruff old professor explained that using H J K L was the True and Proper Way and the arrow keys were a work of the Devil, so to make sure we were not tempted by the Dark Lord of cursor motion, he had the department's system administrator recompile vi on the department's (pathetically overworked) Sun to remove support for the arrow keys.
(As an aside, if you've never tried working interactively on a Unix box whose load is higher than its CPU speed in MHz, you've really missed out.)
Rather than get used to using H J K L, I spent that evening waiting for a new vi executable to build in my home directory.
Laziness will find a way.
Doesn't sound like laziness as much as it sounds like the thinking of an obstinate youngster who secretly is uneasy with learning new things.
One thing I'd recommend adding in the introduction is that even though Emacs can be daunting to learn in the beginning, the effort is worth it because it will eventually become your editor for everything, not just Clojure.
Have to start programming in a different language? Emacs is there for you.
Want to write an e-mail message? Emacs is there for you.
Want to keep a TODO list or a calendar? Emacs is there for you.
This fact was lost on me when I first started with Emacs many years ago. I had come from using "easier to use" editors like EditPlus and Visual Studio. After trying to use Emacs for a week, I gave up in frustration and didn't touch it for another year. I've been using Emacs for about 11 years since then and I think I wouldn't have dropped it if I had been told "I know it seems hard now, but it's extremely powerful and it can become your one program for everything, on any platform you will ever use".
My advice to new users is to start simple and try to only add in extensions/modifications when you hit pain points. I added some universally useful/specific ones early on like AuCTeX, a solarized theme, turning on syntax highlighting, haskell-mode, and so on, but I've found that piling on a ton of plugins and getting away from the 'default' behavior makes it much harder to create a comfortable workflow. This is also why I'm not a fan of stuff like Prelude or emacs-starter-kit.
I imagine that nobody who's terribly accustomed to either editor will switch unless they've got a specific need their current editor doesn't meet.
So I suppose I actually switched without a specific need except for curiosity and boredom. I'm glad I did though, since Emacs has improved my life quite a bit since then.
Emacs also has modal editing that allows for per mode based keybindings.
Where Vim wins out though on the keybinding game is with its grammar that enables a great deal of mnemonics and the ability to bind keys based on key sequences that do not all have to be prefix keys except for the last key in the sequence, which is the case with Emacs currently.
That opens up a lot more options for generating terse keybinds that are simply not possible with the way Emacs binding system currently works, and coming from Vim I found the system extremely confusing until I read how Emacs keymaps lookups work in greater detail.
That spills over into what is possible with Evil-Mode bindings as well to a degree because of the prefix key requirement with the sequences.
And in Emacs, because of its keymap hierarchy system it is extremely easy to have custom keymaps shadowed and overruled by a higher ranking mode mapping, which again coming from Vim is not obvious what is happening there and how to overcome that behavior.
Even though I now grok how Emacs processes keymaps, I still much prefer Vim's system that allows for any key sequences to be interleaved to make very terse sequences.
The workaround to the situation with long chord sequences that use the Meta and Control keys is that I will bind the frequently used command to the hyper or super keys which are largely not used by modes nowadays and are much less crowded as a result.
There is no inherent reason why Emacs could not move towards a key sequence rather than a chord sequence binding scheme, so resolving the quagmire is at least tractable.
I do use Emacs chords where they are reasonable though rather than changing states just to interact with a REPL or a VCS mode, and in the context of working with Lisp I always use Emacs' chords as paredit obviates the need for any of Vim's grammar, which by default lacks a sexp object or ways of transposing objects well.
BTW, "M-g g" (goto-line) is also bound to "M-g M-g" which I find much easier to type.
Another thing I discovered way too late about Emacs was the "q" key. When you're in a read-only buffer like a diff, a man page, an Emacs help page, or an info page, pressing "q" will bury the buffer and close the window (if it wasn't open before the buffer appeared). I find this tremendously useful.
Having used emacs on linux, windows and now mac I disagree with this - though aquamacs introduces some (annoying, to me) functionality, you can simply turn these off and it works just like emacs in any other environment.
I have found aquamacs works better with ansi-term + with full-screen functionality than vanilla emacs, and I use both these functions enough to not want to go back.
I'm using that many hours every day and have zero problems.
Regarding fullscreen, if you use a recent build both native and non-native fullscreen are supported.
I'm pretty sure I had other issues too, but I can't remember them.
To be fair, I've not tried the cocoa version or any other for some time, so things may have changed.
However, I still think OP's point was unfair on aquamacs - other than some (annoying!) quirks regarding autofonts and tabs (I instantly turn those off), it's no different than emacs anywhere else, in my experience.
I highly recommend it, and have been very pleased to see it get better and better over the past year+.
Fonts and color schemes do matter, specially nowadays with the likes of Sublime and Textmate. Even more so for new users.
Solarized seems to be the de facto theme these days. I always wanted a theme that had some kind of "science" behind it. It also looks pretty good.
Another good emacs guide that I came across recently is:
Additional resources I found helpful:
Plus, check out the videos from Magnar Sveen's emacs rocks:
One downside though it that it will leave users wanting that in all languages, something which is sadly not available elsewhere as fluidly. I find myself thinking,"this is great, but what would really improve this situation is if it was inherently structured so that I could exploit that" in other contexts.
It would be nice if someone made a nice starting package that would set it up more sanely for all the IDE-oriented people (basically take what modern IDE can do out of the box and setup Emacs that way). Something similar to what Ubuntu did for Linux. I have seen lots of personal configs on Github, and read lots of Emacs Wiki on how to set this and that, but it's still quite a struggle for me. Part of the struggle is that there are too many options sometimes.
Maybe someone will have a good suggestion regarding this.
Edit: Someone mentioned Prelude, didn't know about it. That looks good, like something I wanted.
It is better just to start emacs do C-h t and start learning, then add and configure when needed. You'll need to start out rough but after a while you'll learn how emacs works and be a better emacs user because of it.
Though if you don't invest in emacs and just need it to finish your thesis or because a professor won't let you use anything else then the starter kits could be fine as they are pre-configured.
And with the tutorial - I have a pretty low opinion of it. I mean, it starts out talking about how to navigate up and down one screen - who cares about that when they're starting to learn a new editor? Who? Emacs already has a reputation for being obscure and difficult, and the tutorial does not help.
This frustration isn't directed at you, of course - I appreciate the comment. In general, though, I think that Emacs instructions would be better if they had a little more empathy for the learner. As a new person, I don't care about hearing all this magical stuff about emacs right off the bat - I can't even make sense of it because I have no context. Just show me how to actually do real work.
Another thing I struggled with was some hints how to actually write and structure your own configuration files. For example, is it good to use the configuration inside Emacs? Where this section should go into the config? I had issues figuring out how to load packages etc. In what order should configuration be specified? What if I use multiple computers, can I share parts of configuration? Etc.
Similar for keybindings. What keybinding can I use for my private stuff that are unlikely to conflict with other things?
The tutorial is more of a get you started and make sure you can actually edit text in emacs.
The most important parts of the tutorial are the how to save (which most people get to) and getting more help which is probably what people don't get to or understand. It isn't the best thing but it is okay if people make it through the end.
But you're right if you don't want to mess with your editor and `learn` emacs go for a starter kit or go for another editor with bells and whistles included.
I disagree. It's not true for most IDEs, why should it hold for Emacs? This argument was also raised about Linux, but then Ubuntu came along and proved it was wrong. This seems to me like a religious stupidity - you have to use it for everything or it won't work at all.
My main motivation to use Emacs is org-mode and Common Lisp. That's already real work; although I try to use Emacs for everything, but using it for just one of these things would be perfectly valid use case for many people.
It's not that I wouldn't like to mess with the editor either; in fact I did a lot. But it still was not enough for it to work decently. I will have to try one of the starter packages yet (probably Prelude), though.
And I don't have big requirements either - I just need some sort of project management (being able to work with multiple files), grep, diff, syntax highlight, ability to indent/unindent and comment/uncomment block on a hotkey, more sane undo and maybe a little bit of completion and language documentation integration.
I can program in Notepad++ and be happy. So if it would be configured to do what that is doing out of the box, great.
Another problem I have, when I want to rebind a key, how do I figure out what keys are used and in what modes? Is there a way for the system to give me a suggestion for a key?
The Emacs help system is a marvel and an astonishment. It's the second thing to explore after running the built-in tutorial. And it's the first thing to master.
Don't neglect the hyperlinked, highly navigable Info Manuals, which you read right within Emacs. They are among the most literate technical documentation I've ever read.
Also, it would be nice if I could easily remap all keys with the given prefix. Maybe someone wrote library for these things already, I don't know.
C-h f - describe a function
C-h k - describe a key binding
The help system in Emacs is wonderful.
Agreed. Plus the often maligned GNU info is actually good when you're browsing from within emacs.
More good help:
C-h i - Browse GNU info
C-h m - "describe-mode": Gives keybindings and help for the current major mode and all the active minor modes.
Activating the "Use option as meta key" isn't a good solution because I sometimes need to type accented characters that require the option key.
How do people deal with this when using Emacs in the OS X Terminal app?
(setq mac-option-modifier nil
Having option as meta is useful outside of Emacs, as "bash" (and other shells) use Emacs keys by default (M-d, M-f and M-b are all essential for me when I'm using bash).
I wish the OS would let me use the Fn key for doing fancy unicode characters (maybe Fn+option or something)—that way I could have good unicode input and my precious meta key.
M-x 8 ` e -> è
M-x 8 / a -> å
M-x 8 E -> €
M-x 8 RET "Em dash" -> —
M-x 8 RET "Hebrew letter double vav" -> װ
 I just saw the comment where you're more specific about what you're looking for. This isn't it, but having gotten a reply already, I don't want to delete this comment. It won't help you, but maybe it will others :P
I've used Option as Meta for years (been using Emacs since (gulp) 1977 on ITS/TOPS-20) and never had any trouble. You can use the M-x insert-char (M-x ucs-insert) and type in the code point or Unicode name of any character.
I want to hold down the option key and press another key to get the character I need. That's why using Terminal's all-or-nothing option of mapping option to meta doesn't work.
That lets you set up things like you want with M-x customize-group ns
I'm using CMD as meta there and CTRL as control, option stays option.
I now use a kinesis keyboard, which has two giant thumb keys for your left hand, I use those for control and meta. Before that I used control at caps-lock and meta using Ctrl+[, which worked well and pain-free for me for years.
Though I replaced my CAPSLOCK with CTRL and I mapped C-x C-m and C-c C-m to be equivalent to M-x. This dramatically reduce my usage of Alt.
What also helped is a tip borrowed from Steve Yegge  to bind C-x C-m to M-x (also C-c C-m, in case you miss the x). This avoids my most common use of Meta, allowing me to use the more comfortable Control (bound to Caps Lock).
[super] - [left meta] - [left control] - [space] - [right control] - [right meta]
Having control and meta right next to each other also makes C-M-* combinations easier to reach.
How do I do that?
Thanks for the guide by the way!
For C-x I generally hit Control with my left pinky and X with my left middle finger: since C-x is a "prefix" key, there's going to be another key I hit later and that will generally be hit with my left index finger.
However for the C-x C-s sequence I use my left index finger on X and my left middle finger for S. Same with C-x C-q.
For M-x I use my left thumb on the Meta key (my Mac's "Option" key in my case) and my left index finger on X.
Just like playing piano, there is no "right" way to map your fingers to the keys (everyone's hands are different, after all). If something feels wrong or is hurting, try using different fingers.
I almost added some other claims but I couldn't put them into words correctly, so I'll just leave it at this :D
From Editor War on Wikipedia
I don't think there is any one axis that clearly marks Vim or Emacs superior. Both are awesome, geeky, sophisticated and powerful.
Sublime Text and Vim or some other text editor can be, however text editing is a small component of emacs' utility to its users.
The reason is that emacs is an environment for running emacs lisp applications, and those target pretty much every imaginable niche.
There exists decades of development in that vein for emacs to the extent that for some domains it is an entirely self-contained ecosystem for that space.
The environment homogeneity is distinctly different from any other app which targets a subset of the tasks associated with an overall workflow; if we narrow the domain to just development a possibly valid comparison would be Visual Studio because of how the environment absorbs every interrelated aspect of development from communication to debugging etc. within one overall application.
Light Table may one day be similarly versatile though and a possible emacs alternative.
But to answer your question. This has been said a million times, but here's another angle. In a recent talk, Rich Hickey was talking about the design of electronic music modules:
> In other words, there's a human interface and a machine interface to the same
> things. And the machine interfaces were there all the time — in fact, they were
> first. And then the human interfaces come. We have to remember that as a
> design thing. What's wrong with SQL? What's wrong with SQL is there's no
> machine interface to SQL. They only designed a human interface to SQL, and
> we've suffered ever since, cause we have to send these strings around. You can
> always build a human interface on top of a machine interface, but the other is
> often disgusting.
http://www.infoq.com/presentations/Design-Composition-Perfor... (at about 41:00)
Emacs is built on a machine interface first (elisp). Even the mouse actions in emacs are processed with elisp. So the human interface is not hard-wired. That's why hackers like it.
PS: Also, leaving the keyboard easily breaks the flow, specially when you are in the "damn, delete this whole line and start again" frenzy that is just milliseconds away from your neat idea. C-a C-k (this also works in most text boxes in Mac OS, though) is extra fast for this kind of things.
As for leaving the mouse, that's not the point. I'm a heavy emacs user, but my latest dwelling with Go have been using Acme (which is a mouse-heavy text editor) and it is very enjoyable, as a change of pace. But being in emacs is not "for the keyboard" as much as being in Acme is not "for the mouse."
TRAMP mode: http://www.emacswiki.org/emacs/TrampMode
I do plenty of work over ssh, and this saves me the headache of dealing with screens and multiple terminals.
I'm not really convinced I should invest time in using emacs.
With Emacs directory navigation you can navigate into archive files such as .tar, .tgz and .zip without having to extract them.
Another Emacs benefit that Sublime may or may not support is that the editor's code can be customized simply by placing cursor at the function and typing a keystroke. Your code is then immediately active with no restarts or reloading.
Emacs works just as well in a OS window on my laptop and remotely running in a terminal. Being able to use the same editor locally and on a headless server is huge if you do server work at all.
You can run bash (or whatever) shells in emacs buffers. The full benefit of this is hard to describe, but once you try this you'll probably use it all the time.
In the end, you'll probably never be convinced by people advocating for Emacs, the best thing to do if you're really interested is to give it an honest try for a non-trivial period of time. Emacs can take time to learn but I think the payback is well worth it.
Sublime is an excellent text editor. Emacs is an ancient book of magic spells, with a strange, hoary culture surrounding it. It is phenomenally powerful, and also very, very weird.
I still use Sublime for 'editing text', but for a mixed workflow with compilation, git commands, REPLs and shell scripts? Emacs. I suspect once I finish rolling Emacs into the precise form I want it, I will more or less stop using other tools.
A few weeks ago, I spent pretty much an entire day configuring Emacs, installing packages, themes, etc....In the end, things didn't really work awesomely. Key-binding issues on my OS X, certain short-cuts not working completely in org-mode, etc... (when not using an external keyboard, I absolutely abhor pressing the "option" key on my MBPro keyboard.)
Then I tweaked out Sublime Text. I appreciated how simple it was to change the themes, and install packages (though with emacs 24 m-x install-package was pretty simple, too), and it seems there's a package for anything (including a super-basic org-mode). And spending $70 on cross-platform closed source is probably worth my time that I save in configuration.
Though, who knows....I know enough VIM to edit server config files, maybe it's time I look into that for JavaScrip/Python development.