Master Emacs in one year | Hacker News Reader

Master Emacs in one year

github.com

145 pointsdgellow116 comments

Once you have mastered Emacs, you are good at all other editors

I haven't found that to be true at all. I find that due to archaic idiosyncrasies and the customization possible with emacs, the more time I spend with it the more difficult it becomes to use different editors.

Yes, I had the same impression. All people I know who use either Emacs or Vim on a regular basis are bound to them.

On the other hand, they run everywhere and are open source, so it's probably no problem.

I can't tell you how often this happens to me:w:bd

I haven't found that Emacs has made it harder to use other editors. It's just made me realize how horrible it's always been to use them, hammering away at the arrow keys, using the mouse way more often than should be necessary, spending time on fixing whitespace that should be spent writing code…

Then there's the fact that Emacs really isn't an editor. If anything, it's a shell that runs elisp programs, chief among which is a text editor. Programs like magit and ansi-term (and gnus and compile and dired and TRAMP and…) are good examples of this.

I say it's a dynamic Lisp environment with a UI based on textual buffers. Compare it with Squeak, for example.

That's similar to what I joke about it being when people complain about it being bloated: It's a LISP VM, which happens to have a thriving ecosystem of utilities that run on it.

Germane to the conversation that emacs make you "good at other editors" (nb: Are other editors as programmable/versatile as Emacs and vi -- certainly edtiors need to be able to rise to a level required by the operator... I haven't worked w/ textmate or sublime, etc., etc.) -- I've recently shelved Emacs for vi to "level-up" my vi skills. I'm as I delve into vi, I'm finding facilities that I really hadn't imagined in my previous episodes w/ vi, and I think part of it can be attributed to my years w/ Emacs, and the attitude that it instilled: "There has to be a way to do what I'm imagining".

I spent 5 years learning and using vi (n perhaps a dozen different Unix-like OSes, so they were all different, meaning I could only use a core set of features.

I then spent a few years working on Windows where I had Vim, but other editors I used were, well, 'standard'.

Then ViEmu came along and I now move between Vi-like editing in VS and Vim, and 'normal' editing in other apps.

It's not too bad, to be honest. I'm editing in a non-vi-like-manner in this comment box. I could probably install something to make Chrome do vi-like editing here, but my brain is happy to switch modes, if you'll forgive the pun.

True I rarely have a problem editing in web text boxes, I never really committed to using emacs as a word processor. But I'd be lying if I said I've never accidentally closed a browser tab when absent-mindedly trying to do a backward-kill-word ('ctrl-w').

I was thinking more about programming and system administration. After years of using emacs, I find it harder to adapt to the popular mainstream tools like Visual Studio, TextMate, etc.

Ctrl-w as “backward-kill-word” is a Unixism from the classic Unix TTY, you can’t blame Emacs for that one.

Indeed. Ctrl-w in Emacs is actually "kill-region".

Vimium is really good for mouseless vi-like browsing in Chrome though. https://vimium.github.io/

There's also uzbl which is a browser that natively supports vi-like browsing http://www.uzbl.org/ but beware, there were some bugs with the TLS validation process iirc, not sure if they're fixed yet.

I use It's All Text! (Firefox) to edit text boxes on the Web with my text editor if what I'm going to write is longer than a paragraph.

Not directly relevant, but for Firefox users: I highly recommend pentadactyl (you have to install the nightlies for compatibility with recent FF)

There is a browser with VI key bindings https://opensource.conformal.com/wiki/xombrero

After seeing TextMate struggle around the jump from version 1 to 2 and yesterday reading Sublime Text to struggle going from version 2 to 3 (to 4) I became more afraid of the sustainability of newer editors. Maybe it's time to hold stronger to your emacs, (or vi).

I've been using Emacs as my day-to-day editor for coming up on 15 years now. There is a lot to be said for picking up a tool with that kind of longevity.

> I've been using Emacs as my day-to-day editor for coming up on 15 years now. There is a lot to be said for picking up a tool with that kind of longevity.

To amplify your comment: I'm going on 33 years, and one of the great things about emacs is how it has changed with the times.

>I'm going on 33 years

Your comment made me realize I'm about the same (ouch.)

I started on TECO EMACS on a DEC-20, then Gosling Emacs on Unix, then GNU Emacs on Unix, then various mini-emacs on PCs, finally back to GNU Emacs.

>how it has changed with the times

Heh, even a glacier will surprise you.

I'm a vi user, having learned it when I had to admin dozens of flavours of *NIX in the 90s.

I moved to Windows ten years ago for my day job, and had to use many editors which didn't support vi keybindings, so ended up learning to work with only the keys on the PC keyboard.

This has worked out quite well, as these days I have vi keybindings in some Windows apps (thanks ViEmu!), but when they're not available, I can fall back to 'no help' mode and still be comfortable enough with most editing tasks.

Still more<esc>bimuch <esc>ea productive with vi keys!

>more<esc>bimuch <esc>

Don't you mean "bcw"? ;)

His would be: Still much more productive with vi keys!

Yours would be: Still much productive with vi keys!

Derp, you're right. It seems I can't English this morning. :)

>I became more afraid of the sustainability of newer editors [such as Textmate].

I'm not afraid. After 22.5 years on Gnu Emacs, I'm considering a jump to Textmate 2.

(I probably would not be considering a jump, however, without the boost to sustainability caused by Textmate 2's having been open-sourced. ADDED: also, being able to edit files on remote hosts is not important to me.)

I gave Sublime Text a shot (20 years emacs), but ran into the same thing that has kept me from using emacs x11 for more than a few weeks at a time, which is that I spend maybe 30% of my time editing files on remote machines, connected over ssh, often through complicated tunneling arrangements that make using Tramp a pain to use.

I keep thinking that what I really need is to switch all the machines I use to Plan9 to abstract away the remote sessions, I guess then I'd have to learn Acme :)

I've had trouble using Emacs to edit remotely via SSH/tramp, but the following ~/.ssh/config settings helped me a lot:

  # stop ssh connections from freezing
  KeepAlive yes
  ServerAliveCountMax 10
  ServerAliveInterval 10
  
  # Lets you bounce through an arbitrary number of hosts.
  # ex: ssh 1sthost/2ndhost/3rdhost
  Host */*
  ProxyCommand ssh $(dirname %h) nc -w1 $(basename %h) %p

Reading guides like these makes me think about how I sound like when I implore novices to try out the command-line.

Why should I?

I'll peg myself as a half-competent developer, the kind who codes everyday and can lose a weekend to a spontaneous side project. I am completely in agreeance that tool mastery is vital for enjoying and being productive in programming, I just have no concept, not from this guide, and not from many others, why Emacs is better for me than Sublime Text, nevermind why I should consider taking a year (an eternity in technological time) to master it.

And I realize that's a question that requires an unfair amount of trivial knowledge (e.g. the way I work and design)...but that's kind of the core concept for me...I feel pretty productive in ST3, I can sense the shortcuts and power tools I haven't taken the time to master and where they would help me, and for the most part, I design my projects in a way that fit the ST3 navigational flow...which I imagine is a side-effect of ST3's overall excellent design. In general, though, the bottleneck for me in programming isn't the typing of code or navigating through files, it's the sitting and thinking...rarely do I ever feel that ST's navigational functions cause me to lose context or concentration.

So all things considered, what value does Emacs bring me? Is it better in general programming situations? Or for ones in which a highly customized environment is needed? In that case, then fashion the argument properly...I would never argue that Ruby is the best language for all purposes, but I could certainly argue that it's a great contender for specific domains, and as a "glue" code.

Maybe the OP lists some compelling use cases further down in this document, but I pretty much stopped reading at this line, which gives me low confidence that me and the OP share the same worldview of how things work:

> No job ad will list Emacs as a required skill. That’s actually a good thing. It ensures that only honest technical guys exist in Emacs community.

> nevermind why I should consider taking a year (an eternity in technological time) to master it.

I don't want to proselytise, but maybe that hints at one of the core appeals of emacs. A year is nothing in terms of the span of time emacs has been around, and so time invested in making emacs your editor is effort that won't be discarded in the next technological cycle.

The other aspect is what I mean by "making emacs your editor"; emacs has had a lasting appeal because it is so general, and so malleable. Emacs becomes a construction material for your personal editor, and everyone who uses it seriously ends up with something idiosyncratic and ad hoc, in the best senses of those words.

Visual Studio, or Eclipse have been around for a fair while as well now. Its not like they will disappear with the next text cycle. And you can get productive with them in far less than a year.

I think you can also be quite productive in Emacs in a much shorter time.

The difference is: the flexibility of IDEs stops after a while, and then there's nothing new to learn to become more efficient. With Emacs, you can keep on learning and optimizing your work environment.

Disclaimer: I work with Eclipse almost exclusively these days, also because for Java it's so much better, IMHO.

Emacs still runs on more platforms than VS and Eclipse, using fewer system resources, and is applicable to a larger diversity of programming / work tasks. There are not so many tools that are both that ubiquitous and long-lived.

Every five years or so I decide to give whatever editors/IDEs are in vogue a decent shot, to make sure I'm not missing out on anything (better still is to work along side of someone who is really productive in a radically different environment, like acme). Usually I come away from it with a few tweaks to my emacs configuration, but I have yet to be compelled away from emacs.

For example, I gave Visual Studio another shot recently (VS2013); and I mean, I read books on using it productively, I read the various tip blogs, advice for customization online, et cetera; I used it extensively. Unfortunately, I just don't see what people see in it. From my point of view, it's still slow, cumbersome, expensive (for any version with features that are actually useful), much less featureful than (customized) emacs, and doesn't run on most of the platforms I use to develop software. In theory, I could dedicate a few years writing extensions for one of these IDEs to duplicate all the emacs modes I use, but I'd probably never be able to fix, for example, buffer switching, or all the places where the mouse is the preferred form of interaction, or where modal dialogs steal focus (let alone all the dialogs that inexplicably aren't resizable). Meanwhile, the nice features like Intellisense and so on are the kind of customizations I've had in emacs for most of my prefered languages for years anyway.

As with all things, if you don't like it, that's okay. If you're productive in ST3, great!

For me, it was the realization that emacs can be configured to do anything you want. If you don't like how it works (and you probably won't), you can change it. Do you wish that Alt-<left arrow> would delete all of the whitespace in front of your cursor and translate the rest of the line to piglatin? You can to that. Do you want to send a copy of your file to an ftp site in addition to your local disk when you hit 'save'? And also push to github? Go for it. I guess you could say that you get out of it what you put into it. I sometimes find the auto-complete in emacs a bit lacking and I'll try another editor/IDE, but once I find something I don't like and I can't change it, I'll go back.

That being said, I think you're probably right that it is better in general and other tools can be better in specific situations.

So what you posted here...this is what I want to see in the OP's otherwise well-intentioned guide. I can say "yes" to a lot of those things, and "maybe" to the others...Don't get me wrong, I love learning new things, especially languages...but in this case, we're talking about a tool that is critical for me to learning other things...when writing an evangelism guide, the saying, "show don't tell", is even more urgent.

That said, I'm going to hold off of emacs at the moment. My goal has still been to learn vim :)

I think the learning curve of Emacs is much easier than vim. You still have a GUI that exposes most of the important functions, and can learn the key bindings as you go. You can start using Emacs for basic editing without actually knowing how to "use" it.

Like gvim or macvim.

I remember back before I knew how to use vim (I was an Emacs guy then) it was a nightmare when I would forget to set my EDITOR variable and get dropped into vi to write commit messages; I couldn't edit my way out of a paper bag and could never remember how to exit without saving, though after a while ':q!' became the only vim command I knew.

Also, and this is weird, you can get vi bindings in emacs through editing modes like viper-mode or evil. So if you want, in emacs you can have both.

In contrast, you will never see emacs inside of vim.

Hah! The way vim extensions are going you'll have emacs-in-vim soon enough. Not that I think it's a good idea, mind you. People spend too much time in vim as-is. (it's fine for emacs; that one's essentially a desktop environment)

> So all things considered, what value does Emacs bring me?

The value in emacs is all the language specific modes and utilities that will allow you to turn emacs into a customizable IDE where you can run your builds, tests and debuggers from inside the editor.

There are "proper" IDEs out there but all of them are more or less language specific. Emacs is a general purpose text editor and can be used with any language, and customized to the tools and conventions around that language.

I use so many tools and languages that having a single language IDE (or many of them) is not an option. And I don't want to go back to running a simple text editor and running my builds on the command line separately.

I've been a Vim user for quite a long time but I'm slowly making the transition to emacs and evil-mode (I recently started doing some symbolic math Scheme code in emacs). Vim is a great editor but tool integration is the weak spot. Especially debuggers don't really play nice with Vim.

> why Emacs is better for me than Sublime Text

Do you use a text editor only for programming? Or do you use your text editor to edit all kinds of text, including emails, letters, notes, to-do lists, etc.? I do the latter, and the last time I evaluated text editors, Emacs was the best choice for editing all the text that I work with daily.

For example, the last time I evaluated Sublime Text, it didn't have package nearly as powerful as Org mode for Emacs. Org mode is the best note-taking tool I've ever used.

In addition to note-taking, another example is email. format=flowed is one of my requirements, and when I search the web for "Sublime Text" "format=flowed", I get fewer than 744 results, and none of the top results are relevant. When I search the web for Emacs "format=flowed", I get 135,000 results, which includes many relevant results.

I was half expecting you to realize that you answered your own question before you asked it (why do you implore novices to try out the command-line?). But what the hey, I'll throw out some links that go better into why Emacs is still a very viable contender for your editor of choice.

Steve Yegge wrote a classic programming read "Tour De Babel"[1], which has a bit on Emacs under the Lisp section. He also wrote "Effective Emacs"[2], which just the intro tries to explain why you should use Emacs. Lastly, there's Vivek Halder's "Levels of Emacs Proficiency"[3] which will either amuse/awe you or scare you.

[1] - https://sites.google.com/site/steveyegge2/tour-de-babel

[2] - https://sites.google.com/site/steveyegge2/effective-emacs

[3] - http://blog.vivekhaldar.com/post/3996068979/the-levels-of-em...

By not learning Emacs, you're missing out on the joys of RSI.

At last, a reason to check G+! I also need to learn about smex.

Interesting to see he uses evil-mode. I've just started using it, and so far the jury is out. I have yet to find an equivalent to move by sexp (move by sentence [()] doesn't do the same thing for me) for instance. I'm less interested in an exact replica of Vim than a more efficient editing experience. Perhaps this will ease with more experience.

A developer who is curious enough to try Lisp is possibly more intelligent than average

This is the kind of exaggeration that makes a lot of people to avoid even trying Lisp. Any programming language that uses a different programming paradigm than the one you are familiar with will make you a better programmer.

I don't really have any desire to try lisp, and every time I see that kind of lisp advocacy I have even less.

If you do decide to try a lisp, don't start with Emacs Lisp. It's a mess. Go with Clojure, out of all lisps it's one of the least self-congratulatory about how awesome they all are for using lisp.

Well, Clojure also was a mess when I tried it (2 years ago maybe?). Leiningen (a/the build system) was pretty slow, and I couldn't find a way to use the language in a more lisp-like way easily, like editing a few files and (re)loading them into a running REPL (other than iterating through all buffers in Emacs and loading/evaluating them manually; there may have been other problems as well, I don't remember). You know, like you can edit a few Java files in Eclipse, press shift-ctrl-s, and have the new code hot-deployed into your debugging session.

Maybe the people who wrote the Clojure tutorials considered that question to be SO natural they didn't even mention it, but I found it very unintuitive. And running a very slow tool on every code change and waiting for the build and then starting the program is very unnatural and un-lisp-like.

Common Lisp is a bit old by now, but it's always been very stable and fast. Maybe Racket is a more modern+mature Lisp family member that's nice to try.

I also tried getting into Clojure around that time. I was coming from CL where we have nice things like conditions and restarts, dynamic variables, and CLOS -- being able to hit an error in the debugger, inspect the slot of the instance of some object that caused the error and recompile the class definition to fix the error without restarting the program is really nice (all of the running instances are updated). I was not used to Clojure's unhelpful tracebacks.

I don't understand what age has to do with anything... CL is still a good language.

I'd also say that one might do well to explore it, even if you don't plan to use it for everything. I'm definitely a Lisp neophyte (Scheme in college, no Common lisp, and then ~6 years with some lisp-like proprietary framework), but there are some things I really miss from it.

As some have said, it's worth learning because of the way it can change the way you think about things. It sounds hokey and trite, or like someone's trying to be smug ("I'm in the secret lisp club!"), but I genuinely feel profoundly grateful to have been exposed to Lisp. (To be fair, I also really like programming in Python for _many_ of the same reasons I enjoyed programming in Lisp.)

Yes, it's very cheesy, but maybe rephrase it as "people who are open to trying new languages are more open-minded by definition, and they keep a flexible mind and learn to think about problems in different ways."

I mean, however cheesy some Smug Lisp Weenies(tm) may be, why not learn something new? Lisp (the language family) is really cool, you should try it. elisp may not be the most exciting family member, though.

There's a big difference between "no interest in lisp" and "no interest in learning something new."

But then you're judging something you haven't learnt yet.

Just saying... I assume you have your reasons to refuse Lisp.

I don't really understand this reaction. It just seems a little immature to me. It's like "I'll show them!! I'm NOT going to try lisp. haha"

Whether or not lisp is worthwhile to learn has nothing to do with how some people advocate for it, right?

That quote is taken out of context and was written by someone who's first language is obviously not English. I took the paragraph to mean that Emacs users are possibly more technical because it attracts those who are curious enough to research less mainstream programming languages.

The entire paragraph is about Lisp if you read carefully. The mother tongue of the author is irrelevant, he clearly thinks that Lisp is a superior language for a possibly more intelligent coder:

Emacs is developed by Lisp whose syntax is different from common programming languages. A developer who is curious enough to try Lisp is possibly more intelligent than average. Lisp is often the third language he/she learns (Java/C/C# is the first, a script language like Bash/Python/Perl/Ruby is the second).

Currently I use Sublime Text 3 with the Vintageous plugin, I'm proficient with Vim but I find myself preferring Sublime Text due to the multitude of packages available to it as well as the UI being in my opinion better and more customizable. I'm most interested in moving to Atom once it matures a bit more and the Vim style plugin also matures. That being said, I've tried using Emacs tons of times now and it just doesn't click with me. More power to you if it's your preferred editors but I'll take Vi(m) over Emacs if I have to use a legacy editor or Sublime Text with Vintageous for everything else. Hopefully soon Atom can replace Sublime Text for me and I can stay on Open Source software.

I started with purcell's config as well. I did two separate attempts at getting started from scratch, and it was just too much. Using purcell's config made me somewhat productive in a week.

Now I'm starting to do my own changes to his config, but there's still a lot of stuff I'm afraid to touch. I'm thinking of declaring ".emacs bankruptcy" soon, or maybe start from something more minimal like the Starter Kit linked in the article (I wish I knew about it before starting with purcell's)

Biggest thing I miss when I moved from Vim was tmux. Window management in Emacs is a nightmare, and the shells suck as well.

I started with nothing. I believe that just like every Jedi must build their own light sabre, every Emacs user should build their own dot-emacs. Conversely, thus spake the great French philosopher: "hell is other people's .emacs"

Emacs is a stern taskmaster, but she repays the investment in multitudes.

Glory be to the thermonuclear text editor.

https://duckduckgo.com/?q=thermonuclear%20text%20editor

I use emacs with tmux, why do you have to leave tmux if you move away from vim? about the emacs shell, yeah I don't use it, use tmux or screen ;)

Can anyone share what they feel are their top 3 greatest workflow improvements in productivity going from a point and click IDE to a shortcut based IDE like emacs?

1. Doing funky things with symbol under cursor. In past lives ive had documentation for things like assembly instructions, opengl apis etc displayed inside emacs.

2. Emacs macros.

3. Lack of hopping between terminal and editor.

The improvement for me:

* speed of typing : I really appreciate not having to take my finger off of the main part of the keyboard to use arrows or the mouse, I also don't like the 2 stack (2 mode) switching for vi. Somehow I find it easier to remember the few keyboard cords the toggling of modes.

* works in a terminal : launch with emacs -nw and you can work across an ssh terminal with same syntax highlighting, same shortcuts

* available for most OSes : my co-workers use fancy new editors except they have to rsync code from the server back to their latest Ubuntu, OSX or Windows just to edit it.

* people like to customize it and there are modes for all kinds of esoteric languages and build systems : i don't fiddle much with my .emacs so it is not benefiting me personally but others swear by it

For me it's less about productivity and more about comfort. When I first started using Emacs I felt like it was a lot easier to move the cursor around and manipulate text with shortcuts consisting of keys that were already near where my hands were on the keyboard.

I use vim now though, and I find that the keybindings feel much more natural, being based on the positions of the keys rather than mnemonic-based ones in Emacs (e.g. ctrl-n for "next line").

What's a "point and click IDE"? Eclipse and Visual Studio are "shortcut based". I've never seen a "point and click IDE" except maybe SQL Windows/Gupta/Centura.

1. On-the-fly keyboard macro generation. I use M-[, record, M-]. f9 to execute. (C-x e, e... if function keys not available) Even very small, one-time, but repetitive tasks can be automated.

2. First-class functions that can be bound to anything. I always bind "goto-line" to a single key (like f7). That alone saves me lots of time. And custom functions work the same way. You can put a macro to insert that if __name__ == '__main__' in python scripts with a single keypress, or with a "M-x <function_name>".

In addition to language boilerplate, you can use these facilities to help enforce arbitrary coding standards. I have a function template for C that adds a comment "/* end <function_name> */" after the close bracket, for example.

These facilities apply to any file you might want to work with. This is in addition to whatever editing modes might already exist for the language.

3. Working in text-only terminal on a remote server is only slightly different from working on my desktop. Not having to manually sync files or mess with X configuration is a huge win for me.

Eclipse has emacs-style key bindings. So you can have the best of both worlds.

EDIT: Sorry, I realize this doesn't really directly respond to "IDE replacement" - honestly I don't write much code any more so some of the below doesn't apply to that. When I wrote code, the main benefit of emacs was that it abstracted me a bit from the nuances of different IDEs for different languages / platforms and was good at generalizing interactions with the compiler / errors / objects. A really good IDE would be better at many certain things than emacs, but emacs was marginally better all around. I used it for C, perl, and a little C++.

1) "the kitchen sink" thing, which is commonly cited as a drawback, is (to me) emacs most compelling feature. If this isn't compelling to someone, then a lot of the rest of emacs probably won't be, either.

There's a learning curve to doing everything in emacs. I've written some guides on it before to ease the transition to starting to use it (basically introducing a few very important basic concepts that introduce major and minor modes, keybindings, and how to investigate those and customize them), but when you have that core understanding down, when you realize that you can apply those same concepts to everything you do - it's incredibly, incredibly powerful and you understand why people want to live in emacs.

eshell or shell-mode for your shell interactions is amazing. searching through a shell buffer with emacs' regexes or incremental search is fantastic. Running your whole shell in that buffer and being able to run simple but useful commands like "occur" (essentially letting you grep through multiple preceding lines of output) is something I use all the time. The commands to jump up / down through the buffer to prior prompts in the shell history - all of that stuff is great.

Similarly, using dired (directory editor) as my shell browser is great. If I need to do a batch file rename, I could jump through some hoops to do this with shell script one-liners or something, but putting dired into editable mode and then treating the file names simply like text and using search & replace operations the same way I would on regular content in a file is a natural, fast, and powerful operation.

And of course all of these are the same commands and same environment as I have for editing text.

I don't do everything in emacs but I do as much as I can in it. And I didn't mention org-mode but I use it for 100% of my note taking and publishing to HTML - it's incredibly awesome.

Emacs is not an IDE- its a text editor. It would be nuts to use Emacs to edit Java compared to Intellij or even Eclipse. Having said that, it is no more productive than any other text editor at editing text (as compared to Vim or Sublime Text 3). Even if that weren't true, would you really invest years into learning a new editor to make editing text a few percent faster? Programming is limited by thought, not typing (common pain here is solved by plugins anyway). The benefits of using emacs are as follows:

1. terminal based 2. key chords 3. (e)lisp 4. open source 5. stable 6. extensible

Last I looked Emacs comes with a million lines of Lisp code extending Emacs way beyond normal editing.

Emacs easily is a text-based IDE. I for example use the SLIME extension with GNU Emacs to make it into a Common Lisp IDE.

Now we can ask if the depth of GNU Emacs makes sense and if the UI usable. But there is little doubt that Emacs is WAY beyond being a simple text editor. See ORG mode, GNUS, ...

Perhaps a naive question here, but I'm interested in emacs now, and I need to ask: does your left pinky finger get used to all the CTRL and ALT key combos, or do you change the key bindings, or are there special keyboards meant for emacs use, or what? Two minutes into the tutorial I was already thinking about whether there should be some sort of hack to use CAPSLOCK instead of CTRL...

I use xmodmap on Linux to remap caps lock to ctrl: http://www.emacswiki.org/emacs/MovingTheCtrlKey

honestly i have no idea why people complains about the ctrl and i actually love how accessible ctrl is. i use ctrl all the time, ctrl-c, ctrl-v, ctrl-a, ctrl-e etc ... ie; ctrl-xs ctrl-xc just rolls off my finger like nothing. i think capslock thing was just a thing of the past when capslock was where ctrl was/is now.

only thing i had to do was for macs, i had to switch option key to my command key. there was no way i was able to use option key for the emacs meta key.

I tend to lean on the control key with the corner of my palm rather than pressing it with a finger tip. (Though I don't use a normal home-row style of touch typing, either, so YMMV.)

I always rebind capslock to control. That's essential. The other thing is adjusting the bindings to your taste; for example, I change a number of standard bindings to better suite a dvorak layout.

You should absolutely rebind Caps Lock to Ctrl.

I guess it's time once again to mention the Kinesis Advantage keyboard on HN. You can rebind every key. You can rebind control and meta to keys that are under your thumbs, and put one copy under each thumb so you don't have to use the same thumb all the time. And everyone who walks by your desk will have an excuse to start a conversation about your incredibly strange keyboard.

Looks interesting, but at $269 I don't think I'll be able to try one out. Maybe after I make that first million. Glad to hear my instinct about capslock isn't crazy.

If you think that's bad, don't get me started on chairs and desks:

https://news.ycombinator.com/item?id=105026

(Incidentally, since writing that N years ago a physical therapist talked me out of the Aeron, which has poor upper back support. I've got a Steelcase Leap now.)

If you ever find yourself getting a job as a programmer, convince them to buy you a fancy keyboard and a proper chair and some Ergotron products. These things all last at least half a decade, so it's not as if you're spending that money every month.

Or buy them yourself... But if your company can't be convinced to budget $750 per year to keep you healthy and happy as you sit at your desk all day pounding out code for them at ludicrous speed, I've got bad news about your company.

I'm a competent Lisp developer (and fanatic), yet I use Vim. I've also met Vim-bashing Emacs fanatics who didn't know the second thing about Lisp (the first thing, of course, being all those parentheses).

A great reference with some pragmatic advice.

I've heard that one of the main benefits to emacs is that it can be used to tool itself to one's needs; curious to know if that's what others have found?

Yes, emacs is wonderfully customizable, but there's a deeper idea underneath. By investing time and effort into learning it and buying into its conceptual view of the world as text buffers that can be manipulated, you gain a level of mastery over your environment that's simply not possible with an IDE or specialist tool. And we are all deeply motivated by mastery. Some authors like Dan Pink say that mastering something is the biggest motivation of all, even above recognition and money.

Many IDEs are pretty veneers on sequences of complex commands that must be learned by rote. Emacs gives you text buffer interfaces to whatever you want to do, a mostly consistent model for dealing with them and the programmability to change whatever you like.

A friend of mine asked me this recently: are there many young programmers investing in emacs? I only know a few... it's kind of depressing.

I'll be using emacs as the sole text editor with my students in September, so there'll be a few more young programmers learning how to use it.

I hope you will be teaching Intro to Emacs. Why else would you impose a text editor on students?

I don't know who Marc is teaching, but you would be astonished by how many undergrads in a computer information systems course do not know what a text file is. They'll take a programming course with C# in Visual Studio, and come away thinking that you can only program in Visual Studio with Visual Studio files. Then you get them in a database course the next semester and assign them some SQL, and they'll try to write their scripts in Word.

Can't blame them for not learning what the previous teachers didn't teach, but I'd sure blame myself if they got to day 2 in my class and I didn't correct it. Now I tend to start my classes by haranguing them to install Notepad++ or whatever alternative exists for Mac users.

I'm getting a little sick of Notepad++ and this thread has me thinking I should give emacs a try. (Probably not for my students though!)

Intro to programming with any kind of Lisp as a language could be a good reason to do this. Unless the Lisp in question is Racket - DrRacket is quite nice Lisp IDE if you remember to enable a few options (like auto-pairing of parens, which I have no idea why would be disabled in any Lisp environment by default...).

I'm confused as to why I wouldn't teach students how to use a text editor. What else would you suggest they write their code using?

You aren't teaching them to use a text editor. You are teaching them to use emacs. A choice based on your personal preference that wastes lots of their time learning what is a very complicated environment. You need to write lisp just to make emacs auto indent on return.

Nano or gedit in comparison would be sensible choices if you were interested in teaching students about the language rather than indoctrination in the editor wars.

Unless of course it's a lisp class in which case Emacs is a sensible choice, but i think you would have mentioned that if it were the case.

> You need to write lisp just to make emacs auto indent on return.

I wanted to say that it's not true, but fortunately I went and checked and found this (in my programming-mode hook):

    (local-set-key (kbd "<return>") 'newline-and-indent)

in my Emacs config. I thought that it's configurable via `customize-*` interface, which is as nice as any other editor "settings" dialog, but apparently it's not...

OTOH I'd rather write Lisp than JSON or Python for editor configuration, but you're right in that it's personal preference.

Anyway, I wouldn't recommend making Emacs the required editor for any programming course (if not using Lisp). Just disallow using IDEs and let the students choose their editors. Make a list of mandatory features, like syntax highlighting, and let them use whatever they feel comfortable with. That way you can focus on teaching programming instead of teaching how to use an editor.

23 year old third year computer science student. I only know of two students (me included) that are emacs users.

Same here. The intro course taught us emacs and vi in the first course. Then kinda left it up to us. Only a small handful stuck with them. People either loved it, or hated it.

I graduated from undergrad last year working at AWS. Of ~30 engineers on the team, there's 2 of us using emacs. The other guy is around his mid 30's.

I'm a current undergrad at MIT and I still see it (and use Emacs myself). Vim and Sublime are more popular though. Vim and Sublime are probably around equal, followed by Emacs.

Yes, at least in my circle of coder-friends. Younger people seem to be using some new-fangled thing like Sublime more often, but there's still plenty of us using and hacking on emacs. Don't worry, we won't let it die.

Why is it depressing?

I have asked before if I will gain anything moving from Eclipse / Aptana to Emacs or VI. It will take a lot of learning, and while Eclipse is far from perfect, I have wrestled with it enough to know what I am doing. And it has lots of plugins.

(I am a not especially young programmer).

-> "I believed Microsoft Windows was only platform worth to develop software."

This sounds like the first line of a Kafka-esque horror story.

Out of curiosity, and this is a real question not a troll :

What can emacs and vi do that a regular IDE can't ?

for me one of the important feature is the ability run in a terminal over ssh on a slow link.

vi: runs everywhere, installed by default on most linux distributions.

emacs: incredibly customizable, you can re-write the way your editor works. Some features that I find important: editing files remotely over SSH, running a shell inside the editor (so the same editing commands work in the shell), easy to write custom file finding functions for searching different parts of a codebase, git integration (a semi-GUI interface to git), and if another editor has a feature, someone has probably created a package that adds that functionality to emacs. Also has tetris and pong.

vi: combinations of commands.

http://stackoverflow.com/questions/1218390/what-is-your-most...

I used Visual Studio, Zend Studio and Komodo IDE in the past. Some (it's not exhaustive list) of the things Emacs can do and mentioned IDEs can't:

Receiving and sending emails. Being an IRC/Jabber/others client. Displaying images and pdfs directly. Bulk editing of many lines, even from different files, at once. Drawing ASCII-art diagrams. Playing tetris. Being an amazingly powerful "calculator" (http://nullprogram.com/blog/2009/06/23/). Transparently editing file on remote machines, also executing commands on remote machines transparently. Formatting ASCII-art tables. Editing outlines/todos with support for semantic movement inside it (Org-Mode). Working in a terminal. Working in a background (--daemon mode) so that new instances just connect to the backend, reducing startup time to almost zero. Dumping a whole Emacs into single binary - all the memory Emacs uses is written to disk and next time you run it it starts very quickly, because you don't need to compile,, load and run any libraries; it's like suspend/hibernate for OSes. Having a decent mode for almost every file format out there. Displaying info about currently running OS processes, like top (proced). Multiple cursors. Rectangular selection and manipulation of rects. Registers for storing pieces of text, locations in files and others. Easy running of external commands, with or without capturing their output. Find&replace with an Elisp function as replacement (quick and effective way to transforms more complex files). Being a terminal emulator (you can run mc inside Emacs, although it's not the best possible experience). Being a shell (Eshell). Easy integration with external REPLs (like IPython, with colors and all). Displaying and working with IPython Notebooks. Splitting windows horizontally and vertically as many times as you want. If you made a bit too many windows (these are Emacs windows, they live inside one OS level window) you can enable tiling window manager for them. Easy integration with external linters for many languages. Displaying man and info pages. Having easily reachable docstrings for all the functions implemented in the editor. Hierarchical keymaps. Semantic editing of sexp (any lisp) code.

And probably much more - I still learn about some new, crazy useful feature at least once a week.

IDEs win in the autocompletion department and project navigation, but that depends on a language being used. For example editing Python with Jedi and Jedi.el (and Rope) in Emacs feels like working with full-featured IDE, with very accurate, context sensitive autocompletion, refactoring support, visual debugger and others.

Emacs and Vi are not IDEs. They operate on strings, not ASTs. Intellij Idea is an IDE for Java- it allows you to eg change the name of a method and have all call sites be updated. A text editor forces you to do this yourself with a string based find/replace. Having said that, text editors are easier to extend.

Sounds like you haven't used emacs in a few years (or longer). There are tools like CEDET that allow building language modes with AST-level understanding of the source code. I don't know about the vim world in general, but I use omnisharp in emacs to provide C# refactoring tools like you describe, and that was originally built for vim.

Any one know how Sublime Text's Command Palette alternative in emacs?

not too sure if I understood, it's been a while since I used sublime text. meta-x is probably the most literal analog of the command pallet, but you might be asking about packages, in which case using meta-x to bring up the 'command input' and typing package-list-packages might be what you are looking for.

maybe smex? http://www.emacswiki.org/emacs/Smex

I use Smex + ido-vertical-mode which looks like this: http://klibert.pl/ido-vertical.png. It's closer to how the "command palette" looks like than the normal ido. It doesn't display keybindings next to commands like Sublime does, but if you have `suggest-key-bindings` set, Emacs will show you command binding when you execute it: http://klibert.pl/suggest-key-binding.png

Helm (https://github.com/emacs-helm/helm) is another way of doing this, although I don't use it (yet - I'm going to check it out sooner or later).

The "command palette" (M-x or <esc>: in Emacs/Vim respectively) is a very useful tool for both exploring and working with the editor. It's kind of sad that people forgot about it for a few decades and only rediscovered it recently thanks to Sublime and similar.

Are there any decent books out there on emacs?

The official GNU Emacs Manual is good. I've slowly been working my way through it. It's a free download:

http://shop.fsf.org/product/Emacs_Manual_24/

I may be raging, but if you need one year to master an IDE/Text editor there is something wrong.

Maybe your definition of "mastery" is different than the author's. To help us better understand your definition of mastery, please list for us all of the things that you believe you have mastered, along with the amount of time you devoted to mastering each thing.

It takes a year because you learn it over time. Learning a tool progressively is the best way to go.

There is a wonderful presentation called '7 Habits For Effective Text Editing 2.0' [1] explaining this philosophy. The idea is to get the basics down upfront and then get more proficient gradually over time. When you use the tool you stay aware of what you are doing. When you find an inefficiency in the way you use the tool, find a quicker way and make it an habit. This is the most efficient.

If you only care about the code you have to type right now and never read the editor's documentation nor learn new commands you'll keep using only basics commands and never will gain proficiency. Not efficient.

If on the other hand you try to learn every feature immediately you'll waste time learning things you won't use and forget most of them anyway. Not efficient.

[1] https://www.youtube.com/watch?v=p6K4iIMlouI#t=2085

You'll be productive in a far shorter time than one year, but the ceiling on what you can do is far higher.

FTFY Get Emacs pinky in one year

I did mention evil-mode.

Whatever problem you got, Emacs has a soluton.

Reply on news.ycombinator.com