Hacker News new | comments | show | ask | jobs | submit login
Why Emacs? (batsov.com)
169 points by bozhidar on Nov 19, 2011 | hide | past | web | favorite | 128 comments



> A very trivial example is the fact that most IDEs don’t even have keybindings optimized for touch typing - they require you to move your hands often from the home row (such a waste) and have mouse-centric UIs.

what? ... and Emacs has optimized key bindings for touch typing? C-x C-c!

Personal notes here - I know emacs-vs-vim is war, but I'm interested in the cognitive aspects of why one works for some people and why another works for others.

My own preference - vim - is driven by memorability of commands. Though I used to use emacs for a long time, remembering commands was a problem for me.

When I tried vim, I found many of the commands I need frequently to be memorable because they are compositional.

Here is what I mean - if I learn the concepts "delete = d", "change = c", "copy(yank) = y", "in = i" and "around = a", I can construct "delete around (" = "da(", "yank block" = "yank around {" = "ya{", "change array contents" = "change inside [" = "ci[" and so on.

So do long time emacs users just remember the keystrokes or have some kind of logic like that for them?

edit: I know emacs is much more than that, but my usability question is purely about the keyboard interface.


> Here is what I mean - if I learn the concepts "delete = d", "change = c", "copy(yank) = y", "in = i" and "around = a", I can construct "delete around (" = "da(", "yank block" = "yank around {" = "ya{", "change array contents" = "change inside [" = "ci[" and so on.

Vim is super cool in how it lets you combine commands. There's nothing quite like it in emacs. Emacs generally takes a more interactive approach, where each part is a separate command that can be interactively repeated. It's left to the user to combine them either by recording (and saving) a macro or by taking the function names for the commands and writing their own command. Emacs is rarely fewer keystrokes by default. For people who like vim editing commands there's viper, vimpulse, and evil.

da( = C-r ( RET C-w

My C-w is customized to cut the appropriate thing at point if there's no region. Without that you'd need a C-M-SPC before C-w

I would often do C-M-u repeatedly as it would cycle me through [, (, and {.

ya{ = C-r { RET M-w

Again I'd normally use C-M-u instead of C-r {, but if you know you want a { this is better. The difference between emacs and vim approach is clear here. Emacs separates the things and makes each step interactive, so you don't have to think before hand how many { are between cursor and where you want to start yank.

ci[ = C-M-9 C-k

C-M-9 is my custom which goes inside [, (, or {. C-k is is paredit's kill, which goes to closing item instead of end of line.


Aha! I think I see the difference now. It's (in all earnestness, I swear) the difference between OOP and FP. Vim is verb-first and emacs is noun first :D 

My vim preference correlates with my language preference. How about yours? Do you prefer OOP languages?

(this is just preference I'm talking about, not superiority of any sort. I read this somewhere - "talking about object oriented programming is like talking about pants oriented clothing". I concur.)


That's an interesting observation, and I'm glad I'm not the only one who has thought this. From what I've seen (as an emacs user, and a functional programmer), typically people in the FP camp tend to use emacs, and people in the imperative camp tend to use Vim.

(Aside: Really, most of the people I know use IDE's these days, even if they are a vim or emacs user. The FP guys are the only ones who don't, to be honest, and that's mostly due to a lack of IDE's for functional programming languages.)

Something I've thought was that Vim was for the most efficient possible editing of text data, whereas emacs was not concerned with efficiency so much as ability to edit _structured_ data. Emacs' paredit-mode is a great example of this. Should you be unfamiliar, paredit _prevents_ you from creating an unbalanced parenthetical structure in your code. For example, if you have (Harpo (|Groucho Zeppo)), where the | is the cursor, pressing delete does nothing! Instead, I should press M-s for paredit-splice-sexp (I think), which will result in (Harpo Groucho Zeppo). The structure is more important to your text editor here than your ability to edit the text.

Vim, on the other hand, lets you drive unsafely. It lets you make your own speed limit (metaphorically, more than literally. emacs and vim are both quite fast methods of editing once you get used to them, I do think vim is faster though). It wouldn't ever do something like prevent you from deleting a paren just because it would cause an imbalance on the page. Object Oriented and imperative languages, C++ in particular, have always seemed the same way to me. They do what you say, and don't question the soundness behind it's logic.

I have a lot respect for people who can code like that, because I can't. I like my text editor or my programming language telling me when I'm being a fool.

Sorry for the long and somewhat off-topic post, it's a subject I've given a great deal of though to in the past and it sprung forth from my mind onto the page before I could stop it ;)


Use vim's visual mode when the noun is uncertain. Or just select the smallest possible block and . repeat.


> Vim is verb-first and emacs is noun first :D

I'm not sure I agree with this comment. I think vim and emacs are both verb-first, but they operate on different nouns. Vim focuses on manipulating text, whereas emacs focuses on manipulating code. I think both approaches are valid :)


So do long time emacs users just remember the keystrokes or have some kind of logic like that for them?

A bit of both. There is muscle memory of course, but they attempted to lay out the default key bindings logically: Ctrl-k is "kill" and Ctrl-y is "yank", Ctrl-h is the "help" prefix so Ctrl-h k brings up the "help" for a specific "key" binding and Ctrl-h f brings up the "help" for a specific emacs "function". Ctrl-a goes to the beginning of a line (a is at the beginning of the alphabet...) and Ctrl-e goes to the "end" of the line. Alt-a and Alt-e go to the beginning and end of a paragraph. Ctrl-b goes "back" one char at a time, Alt-b goes "back" one word at a time. Ctrl-f and Alt-f go "forward" by one char/word. Etc.


> what? ... and Emacs has optimized key bindings for touch typing? C-x C-c!

I can type C-x C-c faster than switching to a new "mode" or moving the mouse pointer anywhere.

As for memorability of commands, I really remember them using my finger motor memory. If you are stopping to think for what the command is before using, might as well start moving the mouse.

The question is then, how does one get to that point? And that what you are pointing out I guess, when learning, it is hard to remember. The trick though is to do it, step by step.

If you just know how to save and quit the program you can use the editor in a very basic way. Use arrows, and type. Then you can learn commands as you go along.


If you are stopping to think for what the command is before using, might as well start moving the mouse.

No, because over time you will pause less often, and for less time, until it becomes automatic.


That is true initially, and one has to go through that process. But eventually it reaches a point when it is automatic and then the ease of memorizing the command doesn't matter (provided the person stuck with it and didn't decide it was too much of a pain to learn).


This seems to depend on the nature of the command --- "move to the word I'm looking at" is often faster with a pointing device (though I haven't regularly used a _mouse_ in years, I use a trackpad on the left and a digitizer tablet on the right). For most other text-related commands one uses often, I'd agree (though I've never used a stopwatch to test it, and "the easiest person to fool" is often one's self in these sorts of "efficiency" contests --- perception can mislead).


provided the person stuck with it and didn't decide it was too much of a pain to learn

That's the key. If I can pause for a second and typically deduce the correct action I'm more likely to stick to something than if I typically have to pull up a help file to know what to do.


I don't know emacs, but I'm guessing C-x C-c can be done in 3 keystrokes and that it saves. In vim, I save in 3 keystrokes too: ;w<CR> (I have ; remapped to : since it's so common). Of course I could remap a shorter combination to save too, and without having to switch modes.


C-x C-c in standard bindings quits Emacs. I think the first reply above (aufrek3) was making a joke.


>what? ... and Emacs has optimized key bindings for touch typing? C-x C-c!

Pretty much, yeah. You just need to have CTRL in a sane position (hint: CAPS LOCK). If on a Mac, also make sure Emacs sees your CMD key as META, and you're a go. No need to move your hands from the home row for 99% of the stuff you need to do.


It's pretty much muscle memory for me.

I tried to learn vim for a while after a particularly bad bout of emacs pinky, but I couldn't get any of <whatever vim has instead of major modes> to work, and that was pretty much a non-starter.


Did anyone else try "M-x butterfly" after reading the comic strip in the blog post? I just tried it out of curiosity and it seems like an easter egg :D

1.) M-x butterfly

2.) The mini-buffer asks "Do you really want to unleash the powers of the butterfly". I entered "yes".

3.) A new buffer opens up and then there's this text-based animation with the text "Amazing physics going on..."

4.) The mini-buffer says "Successfully flipped one bit!"


m-x find-function butterfly

  (defun butterfly ()
    "Use butterflies to flip the desired bit on the drive platter.
  Open hands and let the delicate wings flap once.  The disturbance
  ripples outward, changing the flow of the eddy currents in the
  upper atmosphere.  These cause momentary pockets of higher-pressure
  air to form, which act as lenses that deflect incoming cosmic rays,
  focusing them to strike the drive platter and flip the desired bit.
  You can type `M-x butterfly C-M-c' to run it.  This is a permuted
  variation of `C-x M-c M-butterfly' from url `http://xkcd.com/378/'."
    (interactive)
    (if (yes-or-no-p "Do you really want to unleash the powers of the butterfly? ")
        (progn
          (switch-to-buffer (get-buffer-create "*butterfly*"))
          (erase-buffer)
          (sit-for 0)
          (animate-string "Amazing physics going on..."
                          (/ (window-height) 2) (- (/ (window-width) 2) 12))
          (sit-for (* 5 (/ (abs (random)) (float most-positive-fixnum))))
          (message "Successfully flipped one bit!"))
      (message "Well, then go to xkcd.com!")
      (browse-url "http://xkcd.com/378/")))


Yeah, they added it to Emacs in the next release after that comic.


I've recently (~3 months) started using emacs "full-time" for org-mode, text notetaking, Python, and Octave.

Here is a (small) list of things I'm sure emacs can do:

- Integrate with git;

- Run my Python and/or Octave code inside emacs;

- Perform autocomplete on my Python/Octave code;

- Become my blog publishing platform using a combination of the above features;

- Replace my email, twitter & RSS clients;

- Read and post to HN from within emacs

Here is a list of how many of those things I, personally, can actually do using emacs:

-None of them

I love it for a text editor, I love the keybindings and commands, I love the theory of how extensible it is. But by god it's a nightmare to set up and configure. For all the "guides to emacs" there are out there, it would still take me about 2 or 3 days to get it running like the well-oiled machine I'd like it to be.

I'm sticking with it, but when I'm learning Octave, to learn about Machine Learning, to get better at programming — having to stop to learn how to use my text editor is just one step too far.

One day work will settle down and I'll have more time to stuff about getting emacs to do exactly what I want; but for now I feel like I'm using IBM's Watson to help me beat Words With Friends.


magit and org-mode were two of the reasons I started using emacs a couple years ago. magit is still an emacs app I use very heavily. I can do things in it easily that are quite difficult to do without (and I know git very well).


I don't think a lot of those things are worth learning. I would never consider using git from anything other than the shell or email from anything but my favorite client. It's all personal, of course.

> Perform autocomplete on my Python/Octave code

.. except for auto-completion, who doesn't like that? :-/

Try the 'dabbrev-expand' command for auto-complete in any mode (naive match on other words in the buffer): M-/

Then check out 'C-h a expand' and 'C-h a complete' (apropos searches for commands related to code completion).


Don't dismiss the value of Git integration in your editor until you've tried Magit in Emacs. I hardly ever need to run git at the command line anymore. I particularly like how easy it is to stage individual hunks in Magit.


Magit is probably my favorite piece of software. It's truly epic. It alone would keep me from ever switching to something else. Although emacs has plenty of other things to keep me around.


Also check out http://porkrind.org/commit-patch (with commit-patch-buffer.el) for an alternative to magit's hunk staging which is also works with a bunch of other VCSs (it's heavenly when you're stuck with something old like CVS or SVN).


Now you've got me interested, wonder how something improves "git add -p". Will check it out.


The power of emacs is also it's biggest flaw - it's a tremendously powerful piece of software but it's hard to master.

I think it's a matter of discoverability.

A simple program such as Microsoft paint delivers a nice inital experience - my mom will be drawing moustaches on her pictures in no time. The reason for this is that it has great discoverability: Click on the little pencil and start drawing. Nothing to know, nothing to remember, just start using the program. This, of course is also it's biggest drawback - as the complexity and possibilities of a program increase it becomes increasingly difficult to create a simple GUI.

If you move up to something like photoshop you start to reach the limit of what a graphical user interface can deliver. It's hard for a beginner to just sit down and start. There are masks, layers, palettes, and all sorts of other things to master before you can really use the program the way it's meant to. There's still discoverability - you can actually learn photoshop without a manual, just by clicking around. But it comes at a cost: A lot of options are hidden behind two, three or sometimes four mouseclicks. So you have a program that's hard for a beginner, but not streamlined enough for an expert.

Emacs is at the other end of the scale. It has basically ditched the crutches that are the graphical user interface, which makes it a great program for experienced users that know exactly what they want to do and how to do it. But it has no discoverability. If you don't know how to perform an action emacs won't give you any clues(1), and it won't tell you what it can or can't do. An often heard remark in regards to emacs is "Wow I didn't even know you could do that".

(1) Yes I know there are MAN pages, manuals, etc. but they don't count. I often get better results from a simple Google search.


This is argument shows up in most threads on Emacs - "sure, it's powerful, but that is actually a flaw since it takes such a long time to master". The problem with this position is that you don't need to master Emacs to make productive use of it. No-one has mastered all of Emacs. That's not the point.

The basic text-editing functionality in Emacs is completely discoverable via the menus. If it takes you 30 seconds to learn how to use Notepad, it will take you 60 seconds to learn how to do all of the same things in Emacs. At that point, your productivity on Notepad has plateaued, but you've just scratched the surface with Emacs.

After that point, Emacs rewards careful study. It may be faster to find a quick fix to a specific question with Google, but investing 30 minutes with the built-in tutorial will bump you up from Notepad-like productivity that will pay off the time invested in a few days.

Most proficient Emacs users don't get that way from devoting weeks of study before they start actually using it. It's an incremental process. You (quickly) get to basic familiarity. After a while, you notice some tedious thing you'd like to automate. So you find the next trick or tool to add to your repertoire, and now you're a little bit more efficient in your coding. Repeat the process over a few years, and slowly you 'discover' more of the power that's available to you.

It's true you often get the "I didn't even know you could do that" response in this process. But after you've run into that a few times, you internalize a more powerful idea: "I know I can do this, and now I will find out how".


The power of emacs is also it's biggest flaw - it's a tremendously powerful piece of software but it's hard to master.

I think that's wrong. It more having to do with emacs having old arcane UI convention that doesn't make sense to a modern user.

Where is my copy and paste? It's not C-c C-p? Save is C-x C-s? WTF?


Well, F2-F5 is how I save a file. ;) I just push my fingers up and mash any of those keys.

Actually there's an interesting advantage — Mac and Linux differ on using control and command keys. I'm constantly switching between the two OSes using VMs, and fairly awful things happen when my fingers get confused. Whereas there's no confusion between emacs and either those environments.

For cutting/pasting, Emacs uses a clipboard which remembers a bunch of things, not just the last thing you copied/cut. So at least you gain something to compensate you for initial frustrations. (Though I saw someone use a Mac program which improves the Mac clipboard in this direction.)


Emacs is about muscle memory -- after a while, it just flows.


Yes. If you stop to think about what the key-binding is for the command, you are not using emacs efficiently.

Interestingly I would not even be able now to teach someone what the commands are without having an editor open, as I don't really remember them, only my fingers remember the sequence. It is like my brain has built a macro for the command and sent the actual code to the fingers, so I don't have to think about it.


How is this any different, like using any tool used by any profession by a professional frequently.

Programmers, Musicians, Carpenters, Chef's, Drivers and almost everyone in those lines use their tools frequently enough such that their usage is committed to muscle memory and not the usual think-act-think cycle.

That's also because most problems are matched to solution patterns. You might have seen this while working with the programming language you have mastered. If there is syntax error, you generally don't read the entire error message. You just ideally read the template and the 'fill-ups' in the template and the line number. You go straight without bothering much and fix it.

Same with an editor. There are some things that you do so frequently, its actually better and efficient if the editor enables muscle-memory use cases than Apple product's kinda UI design.

Its precisely this 'problems matched to solution patterns' thing that will some day enable us to do drag and drop programming.

There will ready templates for each problem each of which will match a solution pattern. We will just parameterize the templates. To an extent this is already there auto-complete, macros, template driven programming etc. But in future we may see full scale stuff like this.


> How is this any different, like using any tool used by any profession by a professional frequently.

It is not. However since it is an editor, it can be a tool used by a number of professions -- a writer or a programmer.

What it improves is text editing capabilities. How does it improve them? It help you keep your hands on the home row. Not saying that vi doesn't do that, it does too. So they can both work. One can argue perhaps that emacs' key combinations are harder to memorize but eventually they are easier encoded into muscle memory.

> To an extent this is already there auto-complete, macros, template driven programming etc. But in future we may see full scale stuff like this.

Interesting point. I think there is a larger discussion point in there. In general that hasn't happened and wizards, macros and templates still haven't replaced programmers. Business, non-programmer, programming languages, built from drag-and-drop components have been dreamed about since COBOL. And it is funny, but it still hasn't happened. The idea was that instead of hiring programmers, managers would just encode business rules in an easy language or environment and bam! mix in some AI and they are done.


Not exactly. If all the user wants is a editor. Which generally acts as a cache for temporary text a general user wants to use somewhere else. There is always notepad or wordpad. There is also a word processor called Microsoft Word. Which generally does more than sufficient job. There are sufficient enough alternatives. Emacs can't become notepad just to become usable to general users. Emacs's design case is for programmers who need to do a lot text lifting, execute repeated patterns of complex text editing.

Keeping all this in mind Emacs is designed, to facilitate use of macros and alikes. There are also key bindings to enable short cuts to do that sort of automation quickly. Also there is a huge repository of what the community considers 'common pattern of solutions' to most problems developers face while editing code. Emacs is mean't to provide large gains in productivity while coding for long hours. Notepad is designed for a few minutes of use by a user. Vim is optimized on similar line of Emacs, but in a different usability case, which is also awesome and serves some users pretty well.

Also we already have drag and drop programming to a very large extent these days. Most people working on SAP, and package based solution don't see code in years. But they actually do a lot of programming. In most mega corporations there are business units, where there are consultants, who do a lot of domain logic coding by mere button clicks on GUI. You will surprised how many large number of people are actually with that sort of a thing these days.

Not to mention armies of Java programmers. If auto complete weren't to be there how many Python and Java programmers and their supply in the industry will actually scale? Given the verbosity and configuration hell I doubt even half of that would be possible. Even the mere existence of those programmers is dependent on the existence of eclipse. Remove away eclipse today, and you will see the supply of Java programmers will fall by 90%. Even those 10% available programmers will suffer a massive decline in productivity.

We are already in the drag and drop era. We are just not realizing it. Since we are doing it in different ways.


Would you really group Python in with Java? I find it reasonably compact. True, there is an unfortunate tendency to drag java-style thinking into Python.

I write python with vim; so do most of my co-workers.

(But then I also write Java with vim (when I have to write Java))


I wouldn't group Python with Java, But I would group a bunch of programmers common to Python and Java.

Python attracts the same major group of programmers as Java because it has a very low barrier to entry. It has all the qualities that you would need build a army of programmers. But unfortunately that quality also has a downside, you tend to get a lot of people who need tools and stuff to help them overcome their personal shortcomings.

If you make the tool very easy for novices sure you will get a lot of novices, but they won't really like to take the extra step beyond those initial steps.

This is also the crowd that is in love with verbosity. Verbosity in every thing, code, configuration etc. Because it helps them to write more than they think. Whereas ideally you must be thinking more than your write. Unfortunately Python belongs to the former school of taught.

Good to know you develop Java applications with vim. I don't see that as a very productive thing for the rest of the world. They are better off using eclipse.


The whole Java configuration hell stereo-type is kind of getting old. Its really not true anymore (have a look at the play framework). Although I do agree Java is verbose and you defiantly need an IDE to edit it that doesn't mean other less verbose languages could not benefit from an IDE.

If you really want to play the Ivory Tower of condescension you need to attack the army of PHP programmers and there love of string manipulation of SQL statements.


"""Not to mention armies of Java programmers. If auto complete weren't to be there how many Python and Java programmers and their supply in the industry will actually scale?"""

I don't think I ever used autocomplete with Python. And I don't know many who do, either. You really believe many Python users use something like the Eclipse python mode?

Except for the "tokens in the same file" autocomplete that Vim and such editors offer.


After 10 years in Emacs I've switched to PyCharm (for about 100 EUR). Its autocompletion feature are quite decent (aided by specifying types in docstrings but otherwise it does whole-project type deduction) and I use them frequently.

It has many time saving features -- like real time "pyflakes" like warning, automatic import management (when I type time.strptime it warns me about time being undefined -- would I like to import the time module?).

Only downside is that it can get sluggish in large file on this 5-year old processor.


auto-complete.el does a great job for Python in emacs. To install it check out: http://bfrsblog.blogspot.com/2011/10/making-emacs-first-clas...


Emacs is like piano playing, you are typing unconscious. Image playing a piano with a GUI and mouse! Unthinkable.


The problem arises when you start making custom commands to common things. That makes it much more difficult to move to someone else's emacs instance.


Good point. I have started to really prune down my .emacs simply because I had problems moving from one machine to another.


I swear, after 30 years my connection to Emacs is telepathic. I don't even think about it.

I'm only lost in Notepad (... or Vim :) ).


Emacs hotkeys are set for 1970s hotkey conventions, not todays common hotkey conventions. Several hotkey conventions, such as C-c, C-p, M-(left arrow), etc is wide spread amongst all other software packages except emacs and Vim to an extent.


> old arcane UI convention that doesn't make sense to a modern user

If you are unhappy with the shortcuts, you can buy a Sun Type 7 keyboard and have keys dedicated to cut, copy and paste. I never tried to bind the keys to the Emacs functions, but I am quite sure it must work.


What fraction of the M-x commands and modal functionality (to say nothing of the Lisp functions) are covered by any CUA binding (or whatever C-c C-p comes from)? If a user turns on M-x cua-mode, do the discoverability problems instantly all go away?


that's exactly my point - emacs doesn't put emphasis on the UI at all as you point out. If you can be bothered to learn its, as you put it, arcane ways then it's tremendously powerful tool.

But my mom wouldn't stand a chance.


Anybody's mom need not has to be as proficient or even use Emacs as much you or I need to be proficient playing a violin or a piano.

This also means musical instruments have to be designed to be optimal for musicians who play them regularly not for general amateurs like us who play them once in a while.

Same for a code editor. They need to be optimized for programmers not general masses.


Three words that describe why not Emacs:

"Inner Platform Syndrome"


It has basically ditched the crutches that are the graphical user interface

Because it pre-dates the GUI. Emacs was written for VT-100 terminals and the like.

As far as discoverability, once you learn about apropos you're well on your way.


Frankly, apropos is only the first step. But yes, the traditional self-referential nature of lisp functions, variables and other entities helps a lot.


I sometimes wonder how Emacs would look if a lot of blue-sky resources were poured into its foundations.


Please go on - what odd ideas came out wondering about this?

I'm tinkering with emacs at the moment because I like the lisp-as-foundation idea. Thoughts I've had this morning:

  * Make emacs more useful as the driving-panel for
    a multimode monitor setup. Launch a generic client
    window, and then post data to it as you liked (web
    browser, text stream, graphical)

  * Structured document production system. I'm impressed
    to see that you can now get different size, colour,
    face fonts in a major mode.
  * Iceberg. I keep playing with a concept where you take
    the Bloomberg-style interface, and then implement this
    to drive your computer. I think Emacs would be a good
    starting point for this.
Several big-investment ideas I've had turn out to already exist:

  * Make it nice to drive webkit from emacs.
    (maybe not nice yet - rough edges?)

  * visual debugging of java


A life completely dominated by Emacs.


At least having a reasonably universal library for generating and using syntax trees would be very helpful in closing the gap with modern IDEs.


20 years old like me are using emacs these day. It's not for old people anymore. I bet there are people in the world who are two decade more than my age and never touch vim, or emacs.


Not for old people anymore? Why when I was your age.... Well, I was using emacs. Seriously, 20 year olds have always been using emacs. It's just that suddenly 15 years go by and you're not 20 any more (but your .emacs file will be cleaner).


Yeah, because you know all about programming demographics, from your remote part of the world...


In the article he links to "Emacs Prelude". From its README:

No arrow navigation in editor buffers

This is not a bug - it's a feature! I firmly believe that the one true way to use Emacs is by using it the way it was intended to be used (as far as navigation is concerned at least). That's why I've disabled all movement commands with arrows - to prevent you from being tempted to use them.

I don't use my arrow keys that much, but do any others see this as a useful feature? How do you typically navigate around code in Emacs?


Mainly, I use my arrow keys for M-x tetris. ;)

To navigate, I typically use incremental search (C-s or C-r). Because moving up line-by-line is a slow linear process which gets annoying if you're not a couple lines away from the target.

You can also use the mouse, which is a very direct way of getting where you want to go.

There's also page up/down. (If you don't want to move your hands, that's C-v and M-v.) And for moving the screen (without moving the cursor), there's a quick C-l. If you want to go to the very ends of the buffer, there's M-< and M->.

Then there's linguistic motion, because you're often thinking in terms of moving in units of text. So, M-f if forward-word; M-} is forward-paragraph.

Then there's navigating units of code. Which is like moving in units of text, but you press control too. Like C-M-f is forward-sexp, which pushes you forward a code unit. (Like a string or variable name.) C-M-a is beginning-of-defun, which gets you to the start of the function/method/whatever you're in.


In my experience, nothing helps you change a muscle-memory habit as much as instant negative feedback. It doesn't help to remember 2 seconds after you did it, because then you've already told your brain "this works", and you can only go through so many "oh right, I wasn't supposed to do that" moments before you become demotivated.

When I first started using Emacs, I removed the arrow keys from my keyboard to force me to get used to C-(fbnp) and to this day, when I fiddle with my bindings, I still use that technique, though I'm slightly more sophisticated about it now:

  (global-set-key (kbd "C-+") (lambda () (interactive) (message "Use C-x C-+ instead.")))


I disabled them in my Emacs for the same reason - to force myself to use C-f, C-b, C-p, C-n and related keys instead. One problem with arrow keys is that they're far away from home row, so you need to move your hand quite much to the right to use them, and then back to the left to continue editing.


One feature of Emacs that I wish IDEs would or could adopt is macros. It really enables a larger set of refactorings when you can repeat any text transformation. You really need non-popup find-this-string, though.


    One feature of Emacs that I wish IDEs would or could
    adopt is macros
I think you'll need to have a reflective language as your foundation to do this as well as emacs. It doesn't have to be a lisp - io language has this property as well. But otherwise the IDE developers need to consciously build and expose functionality. Despite this amount of work, users will keep running into things they hadn't thought of and which won't be accessible (unless you build a plugin - a similar concept).


I suspect he means keyboard macros, as opposed to macros defined in emacs lisp using forms like defmacro. Keyboard macros allow you to record an arbitrary sequence of actions, whereas lisp macros allow you to perform arbitrary transformations on your code. I could be wrong though.

Still, keyboard macros could be amazingly useful in an IDE setting.


I use emacs. But arguing between Vim Emacs and Textmate is a perfect waste of time. Get back to work.


He's not arguing which is best at all. He just talks about why he loves Emacs so much. It's a nice article that may make some non-emacs users look into using it.


I wasnt commenting about the author's post. Rather I was commenting on what all the commenters for this post were about to do :).


I want to use emacs. I really do, mainly because of its lisp integration. Partly because I don't like being "locked" into vim. This article does make me want to give it a shot again.

But it is so painful to try to switch. It's a heavy cognitive load to do even simple things like navigation. The best way I can explain what it is like is to reference the frustration of trying to switch from QWERTY to Dvorak.

It is incredibly frustrating to go from 60 WPM to 10 WPM. It burns so much brain energy on such a critical and fundamental task. There may be a great payout if you are successful, but it's a big hurdle to get over.

There are some things that emacs does better than vim can, that I do want to switch. I'm just starting to doubt my reserves are sufficient for that task and doing other productive work at the same time.

Edit: completing some thoughts


I won't lie, it's a painful first few days. It feels slow because you have to look up every little thing you want to do and mentally translate what you want to happen into these new strange keystrokes. Really, it's all about your frame of mind. If you go expecting to hit the ground running you're going to be frustrated. But if you come from the place where you know you're going to go slow and you're just going to do it anyway for a couple/few weeks then you'll have a much better time.

One thing I think is important is to not overwhelm yourself. You'll want to do all these cool things but you'll never remember the nifty commands if you don't even know the basic ones. Just use it for a week or two with just basic cursor movement, cut/copy/paste, saving and quitting. It'll feel like "nano" but with worse keys. Maybe learn isearch after couple days, and query-replace after a week or so. Seriously, don't even think about "buffers" for the first couple weeks. Emacs has so many features and editing commands that you're guaranteed to get overwhelmed if you try to take everything in all at once.

It also really helps to be in close proximity to someone who uses emacs so that you can ask questions as they arise.


> But it is so painful to try to switch. It's a heavy cognitive load to do even simple things like navigation.

You might be interested in viper mode [1], or another one of the VI emulation modes for emacs.

[1] http://www.emacswiki.org/emacs/ViperMode


Yes, I have tried viper mode, and it's a good effort. But it can only handle the basics, or at least when I tried it was just the basics. I have a ton of vim scripts customizing vim, adding features, etc., that just don't work with viper mode.

Part of me thinks that if I go over to emacs, I ought to go with the 'native' experience of it.

I appreciate the reply; and others may find Viper mode very useful.


vimpulse is an extension to viper and gives you (for example) visual mode (copy blocks using 'v').

http://www.emacswiki.org/emacs/Vimpulse


I guess it depends how you define slow. I've never been big on VIM but have used it a number of times. My biggest complaint with it is going in and out of insert mode. With emacs, as long as you keep learning more and more about it, all the shortcuts become muscle memory and you can whip through things pretty fast.

In my experience, the extensibility of emacs was why I kept using it. I don't really notice any "slowness" compared with VIM. It's not enough to make me go to VIM anyway. But either way, to each their own. It's probably best just to know one really well and know the basics of the other. I've never been big on the whole debate. They each have their pitfalls and benefits


The trick is to start with a few basic ones then learn more as you go along.

Know how to quit (C-x,C-c) & save (C-x,C-s).

Then basic moving commands: C-p (up), C-n (down), C-b (left), C-f (right), C-a (start of line), C-e (end of line)

I used just those for quite a long while before I learned others, and even with just those command I realized how much faster I was working, as it saved time from having to move my hand to the arrow keys.


If thats all it took to improve your productivity, you can't have been very proficient with whatever it was you were using before.


Huh? How did you deduce that?

Suppose I was punching holes in cardboard cards and feeding them to a card reader. How does the fact that emacs improved my productivity reflect how proficiently I was punching those holes?


Well changing to another editor, just for the looks of it. Looks like a very bad idea. Editors are productivity tools, not religions that if you don't use one you will end up going to hell.

Learning is good. But if you are using vim and you are productive enough then building on top of it will help you more than learning Emacs from the scratch.


I've been using Emacs with Evil for a few weeks. It's really good, possibly the best vim-mode I've seen.


Here's the other vi emulation mode: http://gitorious.org/evil/pages/Home

It even has its own port of surround.vim: https://github.com/timcharper/evil-surround


That looks interesting. I hadn't heard of it before, I think I will give it a try. Thanks for the link.


  Get back to work.
Time to hack, time to sharpen the ax. It's weekend now, so sharpen it is.


Actually, it's far from perfect.

A perfect waste of time would waste time and nothing else.


I'm going to stick out like a dork I suppose but I prefer slickedit. It gives me all the stuff claimed as great for emacs AND all the stuff claimed great for IDEs. The only thing it doesn't give me is vims smallness but since I rarely exit the editor that doesn't effect my workflow.


I was a huge fan of slickedit as well. It was my main editor on Windows. My 'birth' editor was FINE (Fine Is Not Emacs) which was based on Finseth's thesis but wasn't as computationally heavy as Emacs on the DEC10. On CP/M I used Mince (Mince is not completely EMACS) and later Microemacs. When I got to Sun I learned vi. Left Sun, forced to use Windows and that was where VSE became my goto editor of choice. Then Netapp, mostly windows, some not, used VSE and vi. Then Google and used vim almost exclusively because it was the 'same' on my macbook and my workstation. Once I got a good port of VIM for windows I could have the same environment everywhere.


I'm a huge fan of slickedit. I've switched to OS X in the last couple years and the crappiness of slickedit on OS X has me looking for a new editor.


They are privately testing the beta testing the native OSX version of Slickedit right now. They expect to have a public beta within a couple of weeks.


I am a long time Emacs users but now I shamelessly admit I am an Eclipse user.

Eclipse handles plugins really well. What I loath about Emacs is its plugin management. It is a PITA to download new plugins or update existing ones.

Also Eclipse generally understands the programming language your working on. The whole you have to use your mouse in Eclipse is total BS. In a simple keystroke I can navigate the type hierarchy of a class and or the call hierarchy of a method.... not to mention auto-completion.

For Scala, Java, Javascript, and XML I use Eclipse. For Python I use Emacs because its still the best editor for it.

If your using a JVM language give Eclipse a try. I'm glad I did.

IMHO IDE vs Emacs is becoming so Déjà vu of Emacs vs Vim.


For what it's worth, Emacs 24 has built in package management. It's arguably easier than using eclipse's package management.


Eclipse largely wins because for verbose languages it fills in the gaps in the templates pretty well.

But for large text manipulation, automation, and non linear gains in productivity, Emacs is better designed to enable those than Eclipse.


El-get is a package manager that really helps with the plugins. It allows you to install them very easily and update them with just one command, among other things.

https://github.com/dimitri/el-get


Have you tried Pydev for Eclipse?


Also I noticed only recently that emacs32-nox is really-really lightweight and starts immediately, so I am happy to install/run it on my servers.


I think you mean emacs23-nox


Of course :)


alias ee='emacs -nw -Q'


alias ec='emacsclient --no-wait'

and add to your ~.emacs -> (server-start)


I have started using emacs recently. Before I was using vim (approximately 4years), and one of the things I liked in emacs is there is no editing and command mode, you don't have to press ESC and goto the end of program in emacs and then enter to edit mode, for instance. However, I think it will take time and patience to master emacs.


When the author starts going on about IRC and email within emacs the first thing that came to mind was an old joke:

"Emacs has everything, email, chat, and even a web browser, hopefully next year they include a text editor"

or

"Emacs, for when you want to do anything but edit text"

Now I will readily admit that I use Vim for my day to day work and have not spend any significant time in emacs, but I do find the many control commands jarring and difficult to remember.

My boss is a big emacs guy, and whenever I help him with code or he helps me with code we make fun of each others editing environments :P

I hope to eventually have the time to learn emacs to its fullest and understand it. Being able to use a variety of different editors won't hurt.


I love Emacs. Have used it for years. Which makes it frustrating that the GUI sucks so hard. I program on a laptop which means that reaching for the mouse is far less expensive then it is with a keyboard+mouse setup. Sublime Text supports this beautifully, by offering pretty comprehensive keyboard-ability while not neglecting mouse-ability. Emacs just falls down hard on this front.

Not to mention that on OS X it does pretty much everything against the basic conventions of the OS.


people think emacs users use emacs for it's sheer power but i think that is the wrong perception to have (and promote).

the sheer power is in it's key bindings. it lets you literally take full control of texts with pin-point precisions just like a surgeon does with his tools. the speed and efficiency of it is just un-matched by any text editors out there. i've seen some power vi/vim users get close to speed but still can not rival against a power emacs users. long live emacs.


I like being able to easily write my own functionality. It would take weeks to do on Eclipse what I can do in a leisurely afternoon on Emacs.

Archaic a dialect of Lisp as it is, Emacs Lisp makes Java look like something out of the 50's.


In my limited experimentation with Emacs, trying to get started with Lisp/Scheme, it seems like a bit of an ergonomic nightmare. That may be affected by my Dvorak layout and Kinesis keyboard, perhaps Emacs is the one Kryptonite of this combination...


Emacs is a platform, others are only editors.


We get it! Emacs is god. Or Vim is god. Whatever. Why do we keep having to be subjected to Emacs/Vi love letters on the front page of HN? Then someone says "but Emacs can't do this!" then the other guy says "well vi cant do that!" then we talk about key bindings and it becomes the same post with the same comments and then everyone downvoteed the guy who called it out. Next story!


"""Why do we keep having to be subjected to Emacs/Vi love letters on the front page of HN? """

Because we like reading them, stupid. This is a community driven site.


I think emacs is probably one of the biggest mistakes to ever happen to computer science.

First, let's remember that emacs is not powerful in and of itself. It requires mastery to understand the potential and power that lies in it. The inclusion of emacs lisp is amazing, but seriously? Have you programmed a separate application in emacs lisp? You haven't? What? You used Scheme or Common Lisp instead? Than why the fuck are you defending emacs lisp?

And that is the biggest flaw. The flaw no one likes to talk about. How many people have picked up emacs and quit? I certainly have. Numerous times. How big do you think the population of people who have tried emacs is to the number of current users? Seriously, in terms of a conversion rate, it's absolutely terrible. And you think that's a good thing? Don't give me that bullshit about how only "smart" people will put the effort in. It isn't about fucking effort. It's about giving people the confidence to learn more about your software. And emacs almost definitely fails there.

And that's the whole fucking point of computer science. It's not writing the "greatest" programs. It's sharing. Sharing techniques, skills, libraries and ideas. And emacs is an artificial barrier. And worse than that, the most elite people in CS continue to protect it and cannot comprehend that their elitism is to the detriment to CS as a whole. It's complicated, arbitrary and designed in a terrible manner. I don't care if it makes sense to you. What matters is that you should be able to easily defend any design decision. And you can't.

We need more people to start programming. We need better editors. Why is it that CS has some of the oldest, most decrepit tools with the most adamant defenders? Why?

Seriously, we deal with fucking computers all day. The most arbitrary representation of knowledge possible. And all people do is whine about how things are "good enough" or "no, someone made this decision a long time ago, and now a lot of people make the same choice, so don't be stupid and choose that."

The number of new computer languages being invented is almost fucking SLOWING down. WTF? Computer science is about the drive to find better ways to express and share knowledge, and that means trying new things. Usually, they will suck. But jesus, we have to keep trying. And whatever we do, we have to help a). more people try programming, and stick to it b). support people following their own loony ideas.

I mean seriously, it's fucking sad how slow shit happens. Common lisp, one of the more powerful languages ever invented, got a wonderful tool called quicklisp last year. 15 FUCKING YEARS AFTER CPAN CAME OUT. Why the fuck is shit so fucked up, I mean jesus, it's fucking inexcusable. Our descendants are going to mock us to our faces til we fucking hara-kiri.


You think emacs is one of the worst things to happen to computer science? Thus putting it in the same rhetorical category as patents, multithreading, mutable data, garbage collection, open source, closed source, closed journals, governments, debugging and Microsoft? Any one of which has far better credentials for that role? And you say this because the language it is largely written in is grotty? My god, man, get some perspective. The rest of your rant is nearly as content free--there have been more attempts at sound systems programming languages in the last five years than in the previous fifty.

Look, Emacs is among the last survivors of a very powerful paradigm, along with Squeak, some Forths, AutoCAD to some degree, and a handful of others. It is one of the last metarecursive programming environments. It is not even the zenith of that paradigm--I would probably give the nod to the Symbolics machines with Zwei, but I am largely ignorant of Interlisp and know it is much beloved. These environments are self documenting (for a very specific sense of "document"), extensible, discoverable (for example, C-h k on a key sequence and then click through to the source code; or on the Symbolics you could I think Super-left click a user interface element and immediately start discovering its code, instrument it for debugging, what have you), have internals written in the same language (mostly) as the user script, and any part can be modified at run time, with the modifications taking effect immediately which is what distinguishes them from the Eclipses of the world. These environments are, almost to a man, time consuming to learn; amorphous; frequently kinda pokey; and phenomenally, improbably productive. The fact that some of them can edit text is almost an accident.

I've used a cross section of editors and IDEs and build environments and what have you from recent innovations to decrepit monsters like TECO, and almost none of them have learned anything from Emacs. Some of them have better excuses than others (ed, for example, predating visual terminals). Of the alternatives the ones I found most interesting and most productive are Acme (which is brilliant, but ultimately I think too good at editing itself and not good enough at editing anything else) and Sublime Text 2 (the first new editor I can remember in years with an apropos function), and I'm including the latter mostly on promise rather than actual competence at this time.


I know there are worse things. But that's why I ranted against emacs.

It's good, but we can do so much better. So much. I have faith in you guys, and it's just, well hell I get sad when I see you writing something amazing in C or in emacs. You should be writing the next amazing C or the next emacs. Those tools are the keystones to how cs is able to express itself in a practical manner. And yet almost all new efforts are treated poorly or mocked.

Like, that shit you are describing earlier? Those amazing modifiable and inspectable systems? Why aren't you preaching that from the roof tops? Why do I, the guy who barely knows emacs, have to whine? Cause seriously, that shit sounds fucking amazing. If anything, you should be the one whining "Jeez, after all those advances we only get emacs?"


Languages and text editors aren't the bottleneck, so writing the 'next amazing C' or the 'next emacs' is counter-productive at this stage.


    "Why do I, the guy who barely knows emacs, have to whine?"
Because once you know emacs, you stop whining about it and start using it.

You sound mad because all these people are using emacs and you just don't understand it yet or something. Spend time, learn emacs or vim and then you will understand.

It is ridiculous for you to rant on something you obviously don't understand or recognize the power it possesses.

Emacs and Vim have been around forever. There is a reason.


I generally agree with the sentiment that writing programs, which are supposed to be advanced technology, is done with tools that are often woefully bad and seem stuck in a long past decade, but be wary of generalizing about "you" so much. I use emacs because I find I'm the most productive with emacs, and because it's the best environment for Common Lisp development, but I'm aware of its warts and will happily criticise them at length -- even when talking to vim users! Not everyone who uses emacs is as breathless about it as the author of the article.

I do think your jab at emacs lisp is spot on -- it's really not the lisp you want, and Common Lisp is certainly good enough these days to have a stab at writing an emacs clone in it. I don't know enough about Scheme to comment about it though.

My favourite candidate for most decrepit CS tool is GDB -- it astounds me that this is still the best the open source / Unix world can produce in the field of debuggers, especially since debuggers are the sort of non-user-facing, lots-of-interesting-technical-problems type of area that open source usually excels at. Every time it repeatedly segfaults and kills my carefully constructed debugging state I just want to cry.


Have you heard of LLDB http://lldb.llvm.org/goals.html?


Wow! That's really good news!


I am very, very good with Emacs. There are no other editing platforms that have its power and convenience. If I didn't have it, I would be forced to invent it. (I did in fact do a small Emacs implementation for a microcomputer, back in the 80s. It was fun).

My customizations? Nada. I rarely bother. My ".emacs" file is about 20 lines long, mostly turning stuff off that I don't care for.

If you whip up a tool that is /better/ at working with million-line-plus projects in C/C++, let me know. You seem to be on fire about it.

[I use Visual Studio for C#, and for its debugger. But the heavy lifting is still done in Emacs]


That's the thing though. You're comment about the debugger? That gives it all away.

My comment isn't just about emacs. It's about all the tools we use. There is no real incentive to fix them. To make them work together. We wait for other people to make it. We all wait.

I can't whip up a tool better than emacs. I can't even imagine it. But, that doesn't mean it can't exist. And you're attitude towards my complaints? That's probably putting off your coworker, someone who could invent it.


There are better complaints than yours. I can't whip up some. I can't even imagine them. But, that doesn't mean they can't exist.

This is your bizarro logic in action.

"Something better surely exists".

Well, no shit Sherlock.

Either 1) do something, 2) propose something better than someone else can implement, or 3) shut up.

Your comments are idiotic. Who told you that there aren't real people out there trying to implement something better than Emacs?

XCode 4's use of an actual parser's AST for code completion, refactoring and syntax highlighting comes to mind. Or Visual Studio's overall integration. Or even Eclipse meta-platform extensibility. Subethaedit's concurrent editing ability. And a lot more stuff, besides...

"Where are my robot ponies and flying-cars, they just have to be" is idiotic.


You seem awfully riled up about a text editor. This rant is mostly incoherent, and probably a troll, but I'll bite.

> I think emacs is probably one of the biggest mistakes to ever happen to computer science.

Emacs has nothing more to do with computer science than hammers and nails do with architecture. It's just a tool used to write code; computer science is about thinking algorithmically and mathematically about computation and problem solving.

> First, let's remember that emacs is not powerful in and of itself. It requires mastery to understand the potential and power that lies in it. The inclusion of emacs lisp is amazing, but seriously? Have you programmed a separate application in emacs lisp? You haven't? What? You used Scheme or Common Lisp instead? Than why the fuck are you defending emacs lisp?

Does anyone really push Emacs Lisp as a general purpose language? Really? I realize that Emacs is quite a bit more than just a text editor, but I've never heard it seriously recommended as an alternative to other languages for application development. No one is writing the next big revolution in software using Emacs Lisp, nor is anyone saying that we should.

The language is specialized for customizing and extending Emacs, and nothing more. Vim has its own extension language too, which is even more domain-specific. Are you seriously arguing that the use of specialized languages for the tasks that they're designed to accomplish is indefensible, simply because general-purpose languages also exist?

> And that's the whole fucking point of computer science. It's not writing the "greatest" programs. It's sharing. Sharing techniques, skills, libraries and ideas. And emacs is an artificial barrier. And worse than that, the most elite people in CS continue to protect it and cannot comprehend that their elitism is to the detriment to CS as a whole. It's complicated, arbitrary and designed in a terrible manner. I don't care if it makes sense to you. What matters is that you should be able to easily defend any design decision. And you can't.

How in the world is Emacs, or any programming tool, a "barrier" to computer science? No one is forcing you to use Emacs. If you don't like it, don't use it. There is nothing about Emacs that prevents "sharing techniques, skills, libraries, and ideas". Whether or not it's "complicated, arbitrary, and designed in a terrible manner" is a matter of opinion. Plenty of people feel that way; plenty of others don't.

Souped-up text editors like Emacs and Vim are certainly designed for expert users and do little to assist newcomers. So should those of us that are experts just throw out our advanced tools and switch to MS Notepad? The learning curve exists, no doubt, but there is a payoff to surmounting it. Why else would these tools have so many adherents?

> We need more people to start programming. We need better editors. Why is it that CS has some of the oldest, most decrepit tools with the most adamant defenders? Why?

Emacs is old, sure. That says nothing about whether it's worthwhile. Sometimes the earliest ideas in a particular field are the most revolutionary. And if you have better ones, then what's stopping you from making them a reality?

There is no shortage of editors out there that are more approachable to newbie programmers than this "advanced" kind. I'm a huge Vim user, and I think it's a fantastic piece of software that I could hardly do without, but I would not recommend anything of the sort to a newcomer. There are plenty of tools for that demographic, but when it comes to text editors for "veteran" programmers, there are really only the two big ones, plus a handful of others that lie somewhere in between in terms of complexity and power. I find it very hard to believe that new programmers are being turned off to the field by Emacs, of all things. There are countless aspects of the process of learning to program computers that are far more difficult than choosing a text editor appropriate for your needs.

> Seriously, we deal with fucking computers all day. The most arbitrary representation of knowledge possible. And all people do is whine about how things are "good enough" or "no, someone made this decision a long time ago, and now a lot of people make the same choice, so don't be stupid and choose that."

Again, you seem awfully bent on disparaging the status quo without offering any real alternatives.

> The number of new computer languages being invented is almost fucking SLOWING down. WTF? Computer science is about the drive to find better ways to express and share knowledge, and that means trying new things. Usually, they will suck. But jesus, we have to keep trying. And whatever we do, we have to help a). more people try programming, and stick to it b). support people following their own loony ideas.

The quantity of new languages being invented is hardly a great metric by which to measure innovation. Maybe most of the great ideas in programming language design have already been had, and now it's a matter of incremental refinement, ad infinitum. I'm not saying that's necessarily the case, but it could be. And what any of that has to do with text editors is utterly beyond my comprehension.

> I mean seriously, it's fucking sad how slow shit happens. Common lisp, one of the more powerful languages ever invented, got a wonderful tool called quicklisp last year. 15 FUCKING YEARS AFTER CPAN CAME OUT. Why the fuck is shit so fucked up, I mean jesus, it's fucking inexcusable. Our descendants are going to mock us to our faces til we fucking hara-kiri.

Another complete non sequitur. And liberal usage of profanity does nothing to make your argument more compelling.


30 year old programmer here (started programming when I was 9, in LOGO, and then BASIC).

While doing my BS in Software Eng. I tried Emacs and Vi for several months (really really wanting to like them) and I never "grok it". I've been using IDE's (Borland, Microsoft, IntelliJ, Eclispe, Netbeans, etc) and the only reason I touch Vi is to edit text files in my Linux installs.

Aside of that, I never really saw any benefit, but hey, maybe I am not cool enough.


Well as a guy who likes vim quite a bit and is playing around with emacs because being a platform is interesting, you should really just pick one to use for a while. You have to actively pick up and use it though; pick a new feature every few days to learn and use. Downloading a fairly well thought out .vimrc file and using that will be a productivity boon if you choose vim. Change the leader to a comma, change : to ; to get into the command line quickly, exit insert mode with jj pressed instead of escape, use the hjkl keys to navigate, learn how easy and amazing the macros are, text-block navigation is great. There is a reason that there is a vim mode available as a plugin for most of the IDEs that you listed; text editing and navigation is really efficient with it. learn the verb-Til-character command dt> would delete until the > character on you line.

If you want to grok vim this is the guide to read: http://stackoverflow.com/questions/1218390/what-is-your-most...

I would love for someone to show me a comment like that one for emacs as I am learning emacs currently.


Yes, Emacs is useful. Yes, it can be used for great things. Am I smart enough to know how to fix it? No. Do I have any solutions to the problems I perceive? No.

But, that DOES not mean that they do not exist.

We're riding the back of Moore's law and we can't even take advantage of it.

Think about it this way: take something you like, or think is well designed, and imagine it 10 years in the future. Now 20. Then 30. And so on. When does it start being a piece of shit? Because, you see, everything besides art and the most practical devices turn to shit eventually. It's happening to emacs, and a lot of other software, and no one wants to admit to it.

You're right, algorithms are timeless. But, you are an absolute idiot if you think that the tools we use don't influence how we conceptualize things. If you use C, it's almost impossible to think in a pointer-free manner (I mean stacks, not gc). Or that the tools we use influence who tries it. Most people have a horrid view of cs, and for good reason. The tools we use represent cs, and they do so poorly. Very, very poorly.

The point isn't emacs. Or quicklisp. It's that people become too satisfied with the status quo. They are happy to master what exists, and pride themselves in that. And they should, we need that.

But, we also need anarchy. We need people to invent things. We need new things. Change is good, it's inevitable.

I want to make this clear: I am an absolute idiot on this forum compared to most of you guys. But, that doesn't mean I can't be on the right side of fate, or understand that.

You're right, no one is forcing me to use emacs. Or gdb. Or Windows. Or C++. Or internet explorer. But guess what, they all get pushed by the popular kids.


>>We need people to invent things. We need new things. Change is good, it's inevitable.

This is right, but something like Emacs isn't a joke to invent, maintain and grow. Look of it something like, Emacs is a tool designed to work hundreds and thousands line of code. And that's only a beginning. You need to make all that text context sensitive to each other. You need features to make enable heavy text lifting, automating complex text editing, and then enabling them all through macros. And not just that, you need features to run a shell inside the editor. You need to enable code-checkin features. May be to do to a quick check you need to read some news or read email. You need enable code profiling, features to enable seamless debugging. You also need to manage to-do lists. As you will see the list is only growing.

And again, you need to make all that programmer friendly, you need to enable to do all that through just keyboard because tend to be in efficient source of input for that kind of editing.

How many tools since the advent of programming have been to do all that? And still be maintainable, relevant and usable for so long as Emacs and vim?

I hope it was as easy to build a editor that would make coding all milk and honey. But with generations of programmers and their combined effort is what Emacs and Vi is all about.


Dude, a word of advice: don't knock vim or Emacs around here EVER! You're likely to start a holy war. Just stay out of it and let the religious war ensue without becoming a casualty.


Yeah, we read your other comments. You don't use Emacs and Vim either, and are proud of it. We get it.


First year college student, right?

"First, let's remember that emacs is not powerful in and of itself. It requires mastery to understand the potential and power that lies in it."

Same can be said for Math, Computer Science or anything. What did you expect, a silver bullet?

""The inclusion of emacs lisp is amazing, but seriously? Have you programmed a separate application in emacs lisp? You haven't? What? You used Scheme or Common Lisp instead? Than why the fuck are you defending emacs lisp?""

Because it's convenient to have it inside a text editor. Until you go write that other text editor that uses Scheme, that is. We'll wait.

""And that is the biggest flaw. The flaw no one likes to talk about.""

No one like to talk about it eh? Really? Strange, because I read criticisms of Emacs lisp all the time.

""How big do you think the population of people who have tried emacs is to the number of current users? Seriously, in terms of a conversion rate, it's absolutely terrible. ""

Yeah, I can see how being one of the two more widely used programming text editors in UNIX-land is terrible.

""And that's the whole fucking point of computer science. It's not writing the "greatest" programs. It's sharing. Sharing techniques, skills, libraries and ideas. ""

Actually, computer science is not about writing programs at all. That would be software engineering. And it's also not about "sharing techniques, skills, libraries and ideas", though that could come handy.

""It's complicated, arbitrary and designed in a terrible manner. I don't care if it makes sense to you. What matters is that you should be able to easily defend any design decision. And you can't.""

Actually I can. But you seem to have already made up your mind.

""We need more people to start programming.""

Well, I for one don't. I like my job security, thank you very much.

""Seriously, we deal with fucking computers all day. The most arbitrary representation of knowledge possible. And all people do is whine about how things are "good enough" or "no, someone made this decision a long time ago, and now a lot of people make the same choice, so don't be stupid and choose that.""

Yeah. First year college student, definitely. Unable to comprehend the real world tradeoffs (like: something existing is better than your pie in the sky idea of a perfect editor).

""The number of new computer languages being invented is almost fucking SLOWING down. WTF?""

Yeah, really WHERE TF you got that impression? It is actually increasing, nearly everybody and his dog are writing a compiler these days.

And it's not like language creation is something special or really good. Especially another run on the mill language, or some academic monstrosity with no following and libs.

"" Common lisp, one of the more powerful languages ever invented, got a wonderful tool called quicklisp last year. 15 FUCKING YEARS AFTER CPAN CAME OUT. Why the fuck is shit so fucked up, I mean jesus, it's fucking inexcusable. """

Yeah, it's amazing how slow computer development is compared to all those other fields. I mean it only took like 5,000 years to invent typography.

Still, we didn't made a library-system for a language relatively few give a fuck about for 50 years? Inexcusable.


upvoted for wordcount.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: