Emacs for the rest of us: ErgoEmacs | Hacker News Reader

Emacs for the rest of us: ErgoEmacs

code.google.com

62 pointsmacco47 comments

It should be pointed out that Emacs maintainers aren't in some kind of stubborn elitist get-off-my-lawn mindset.

Making Emacs more welcoming to newbies has been discussed time and again on the Emacs mailing lists. But the general consensus (one that I happen to agree with) seems to be that "learning Emacs the hard way" is, generally, the right way.

As just one example, I think that emulating the inferior Undo/Redo paradigm (using the Ctrl+Y/Z binding familiar to Windows and MacOS users) hides the full power of the Kill Ring and may mean that some Emacs users will never get to know about it.

I know it's a topic of heated debate and I don't mean to start this debate all over here on HN. I just thought it would be good to point out that newbie-friendliness is continually being considered and reconsidered by Emacs' maintainers, but (for the most part) usually rejected, and I think for good reasons.

See this thread for one example, there are many more if you care to look for them:

http://lists.gnu.org/archive/html/help-gnu-emacs/2005-03/msg...

I agree with the maintainers. I view these pre-configured init files as a good middle ground. They help you be productive while you learn.

Right. It seems effort in this direction would be better spent making it easier to learn emacs as it is than trying to make it something else. The world is filled with CUA mode editors, many of them don't even suck. Users who truly want that are very well served, and emacs isn't going to bring much to the table. People who actually want emacs' features like it the way it is.

I truly want the programmability of emacs without the weird interface. I tried to use the former to implement the latter, but it's a ton of work and it seems to break all the time.

Spend some time seriously getting used to the "weird interface" (I mean: really work at it. Throw out the arrow keys, remap control, and stop using other editors cold turkey) and I suspect you'll change your mind.

What about the emacs interface is weird to you? Is it just the unfamiliar keybindings, or is there some overarching paradigm of emacs' that just rubs you the wrong way?

I kind of hate the kill ring, because I don't know how to suppress putting things into it. I would really like to be able to delete swatches of stuff I don't care about in such a manner that they aren't pushed onto a "paste" stack on top of other things I do care about.

I've also never really understood the benefit of not having "redo". What am I gaining in exchange for the annoyance of having to hit an arrow key before being allowed to "undo the undos" and duplicating a big chunk of my undo history?

You can set delete-active-region to t; hitting DEL will then delete the region without adding it to the kill ring (i.e. delete it as opposed to kill it.) Alternatively, you can bind delete-region to a keystroke of your choice.

Regarding your second issue, I'm happy with the undo system as it is, but if you're not you could try and see if this works better for you: http://www.emacswiki.org/emacs/UndoTree

Also, instead of cursor motion to "break" the undo operation, you can use C-g. I.e. C-g C-_ will redo (undo the last undo) rather than going back further in the undo history.

UndoTree is a true godsend! It basically shows a graphic over the undo tree and lets you navigate it. Really handy. :)

One of the clearest benefits of Emacs's undo system is that you never lose history the way you do with an undo/redo system. I also personally find it more convenient.

However, as somebody else mentioned, you should also check out the undo-tree plugin. Some of my friends really like it.

If you routinely find yourself dredging up stuff from deep in the kill ring you might want the browse-kill-ring extension, but you also might want to think about using registers, which are emacs's idea of a solution to your problem: If you often find yourself wanting to explicitly distinguish between delete-forever and delete-for-recovery, you should probably try distinguishing between delete-for-recovery and add-to-the-kill-ring-in-case-of-emergency instead; it's safer.

I think registers sound like the sort of approach I want, thanks.

I think there are a huge percentage more people who dont know the first thing about the emacs kill ring because they tried out emacs and it didnt support the same keyboard shortcuts as every single other application on their computer.

I am an emacs user, I love it, but I avoided it for over a year because it made absolutely no attempt to play nicely with new users, emacs doesnt need to be so hard to new users, it does it on purpose

To be fair to Emacs, Emacs had the key bindings it has for cut and paste, etc., long before there were such conventions for cut and paste.

I agree, except it doesn't do it on purpose. It's too old to change.

Emacs' ugly, clunky, non-standard 1970s way of doing everything is so closely bound to all the good things about Emacs that you can't have one without the other. People always try (for good reason), but then Emacs doesn't work as well, and the efforts evaporate.

The problem is that if you use other program a lot you begin to confuse shortcuts. That was a big problem for me.

The way undo works in emacs is better than standard CUA behavior for two reasons: 1. It doesn't lose history. 2. You can undo within a selection.

However, there's room for improvement. In particular, there's packages that turn undo history into a tree. http://www.emacswiki.org/emacs/UndoTree

Meh.

Modern does not equate to better. Most of the complaints listed boil down to "Because it's not Windows". Intuitive is just what you've seen before...

I suppose it's ridiculous to expect and hope people to care about their tools enough to customize it for what they use and want. :-/

I spend probably 30 minutes each month on average dinking with my .emacs to tune it with how I'm using emacs, remove hassles, etc. These days it's extremely intuitive and useful for my work. I maintain similar keybindings between multiple operating systems, customized for my preferred keyboard and hands; a variety of functions have been put together to ensure that what I do gets done very efficiently.

Because emacs was extensible trivially, was programmable, I can spend the time and the learning curve to invest in my primary tool. That's what, in my opinion, emacs is about.

Intuitive is just what you've seen before.

That is a marvelous aphorism.

http://news.ycombinator.com/item?id=3389615

I didn't come up with it, but I like to use it in an 'intuitive' debate.

Some projects related insofar as they are attempts to simplify the initial configuration of Emacs. I've used all but the last at some point and have found them useful (though like any good scaffolding, they become irrelevant over the course of continued Emacs usage):

* https://github.com/gabrielelanaro/emacs-for-python

* https://github.com/technomancy/emacs-starter-kit

* http://eschulte.github.com/emacs-starter-kit

* https://github.com/pdee/pdee

I am especially interested to see this get off the ground, though, as even the simplified "starter kits" above still require a certain non-trivial level of contextual Emacs-knowledge -- a simple binary with overly-sane keybindings and functional out-of-the-box would be a real contribution. I would have loved to use something like that myself about a year ago.

This timeline seems to be unaware of package.el, ELPA, etc, by proposing bundling MORE packages by default in Emacs (IMO Emacs' default installation is already huge).

Also, I don't see the keybinding changes gaining any traction, because they would conflict with too many existing packages. As one of many examples, C-c (proposed for Copy) is already used for lisp compilation.

In that same vain, I would love an emacs in a browser based on the Javascript language. So, a base API to create new buffers/windows. Ideally a theme manager and a plugin/extension system.

The goal would be to have this app open 24h/24 on a server and be able to totally use it from the browser and customize it with Javascript.

I would also be able to have a irc client (Think erc) directly in this 'editor' coded entirely in Javascript using this API. Basically, anything you could do with emacs would be possible, but directly from the browser hosted somewhere and running 24h/24.

That's interesting, but one of the challenges is the wide variety of modifier keys emacs uses, and the difficulty of binding them all in the browser.

The other major challenge is just duplicating javascript the sheer quantity of functionality emacs provides. An easier first step may be to run emacs on the server and write a javascript-based client for it.

Or, you know, run emacs on the server and write a "ssh based client" for it. :)

What would be the value of running in a browser specifically? The files you are editting almost by definition live outside the browser's sandbox. And if they're going to be managed server-side, it seems like there's a perfectly working 40 year old paradigm for managing files on a remote host.

You're right, it's an interesting challenge but not necessarily one that is begging to be solved.

This might not be everything you want, but check out Ymacs: http://www.ymacs.org/

Not sure about having an editor in a browser, but if you want a (mostly) decent IRC client in the browser you could try:

https://irccloud.com/

I have 3 invites if anyone wants to email me (my email is on my profile).

This hasn't been updated in nearly 2 years.

The linked 'DeveloperIntro' page hasn't been updated since 2010, but the code was updated as recently as last month. EDIT: http://code.google.com/p/ergoemacs/source/list

Many of the comments focus on increasing the friendliness of emacs for new users, and how open-minded the maintainers are to this effort, though they realize in their wisdom that this is not necessarily a valuable goal in and of itself.

The newbie issue is a typical red herring and excuse for the maintainers not to face the fact that emacs has huge design problems for all users, not just newbies. For example, the presence of dozens of redundant crappy packages associated to every function, included by default in the distribution (e.g. a dozen word-wrapping packages) means that one is likely to use a substandard tool and have problems. The fact that all add-ons are treated with equal weight means that the command you are looking for is hidden among thousands of commands, most of which are way outside the scope of what I need. The proliferation of buffers, leading to the proliferation of buffer packages used to search through lists of buffers? You have to be kidding me. The customization system in Emacs is not only a throwback to 1980s UI "design" but completely out of control -- all options, no matter how minute, are treated on equal footing even if most of them should be hidden or in subtrees. Not only this, but the customization options themselves are badly named, using quirky terminology which nobody uses except emacs.

In short, emacs is thoroughly polluted and needs an environmental assessment and large-scale cleaning project. This has nothing to do with newbies, it has to do with oldies whose dusty, dried-up packages need to be swept into the dustbin of history.

As a Dvorak user, I find it very odd that he has a version of the keybinding (http://xahlee.org/emacs/ergonomic_emacs_keybinding.html) with all the letters swapped around so that shortcuts are in the same physical place that they would be on a QWERTY keyboard(!).

I can see relearning C for copy, as it's logical and would reduce the burden of switching between normal Mac/PC applications, but having J mean copy because that key would have been C in QWERTY is just too weird. I think about lots of Emacs bindings mnemonically: C-b, C-f and friends, obviously, or C-c because that's just the "bindings having to do with this mode" key, and you see it a lot when you read documentation -- in my head, it's a letter, not a physical position. I touch-type Dvorak pretty fast, but two-finger type it very slowly, because in my brain the letters are wired to finger movements starting on the home row.

A possible reason for this is that he has an "inverted T" for cursor movement (but on the left hand, like vi, not WASD like I believe PC gamers would be used to). If your set of cursor keys is based on the physical layout of QWERTY, like vi, it doesn't translate all that well to Dvorak (vi manages to be not horrible since J and K stay next to each other, but in this proposal J and K are not on the same axis), but if they are mnemnonic, like Emacs, there's no problem.

If the idea is to fit better with what the vast majority of "normal" people expect computers to work... well, normal people use the arrow keys. Telling them an invented abstraction is better because they don't have to move their hands from home row isn't going to sell them, I think.

you may put this line in your .emacs or .emacs.d/init.el:

(setenv "ERGOEMACS_KEYBOARD_LAYOUT" "dv")

The real power of Emacs is the whole set of commands to match the mind interests (more commands you have, more power you get). For example, sexps are the best thing for programming: cut/copy/paste complete expressions is a must and you can feel how your mind want to handle those kind of expressions. And Emacs gives you that power.

Anyway the default Emacs keyboard bindings are just ridiculous, also ErgoEmacs is not good enough. I've my own keyboard bindings: http://goo.gl/jwwdG and I'm sure they can be much better. But it's just matter of taste.

The worst enemy of Emacs is its own UI and its own programming language for customization: elisp without multithreading support.

Note that ergoemacs is not the same thing as CUA mode. Ergoemacs is more about ergonomic efficiency than about mimicking windows. CUA mode is a separate mode already built into emacs.

I used ergoemacs keybindings for a year or so. They are pretty slick, and definitely more ergonomically efficient than emacs default keybindings. However, many modes are designed around emacs default keybindings, and I eventually decided it was too much work tweaking every mode I used to conform to the ergoemacs setup.

If you stick to emacs core modes which are already customized, it's probably a good choice.

Interesting project. Emacs is such a powerful tool. It makes sense to attempt to modernize it. It will be hard to get momentum because Emacs users are typically die-hard purists, so moving away from the "Emacs way" may ruffle some feathers.

Recently I've started to do this on a small scale in my own .emacs file. Shortcuts I use every few minutes were hidden but too many multi-step keyboard shortcuts. Especially when I really don't need to duplicate the arrow and page-up/down keys with single-step shortcuts.

It's too bad it sounds like there won't be a Linux version.

I think the biggest change for regular users is a good package manager. ELPA is coming per default in emacs24, and there is a project in github (el-get) that is even better. I have a pretty big emacs config, and configuring some external modules (and updating them!) used to be a nightmare. Now it has gotten much easier.

It does make sense to modernize it, but it emphatically does not make sense to use cua-style bindings. This isn't because all Emacs users are "die-hard purists", it's simply because the Emacs way is much better and trading long-term efficiency for short-term gain (ease of learning) is definitely not a good choice.

Additionally, you should use the C-whatever bindings for moving around instead of the arrow keys. Once I learned them, moving around code became much simpler. Not only do you not have to move your hand to the arrow keys, but you also start using some of the more advanced moving commands that let you move by expression or paragraph (the latter is great for code because it takes you to the next blank line, which is usually what delimits parts of the code that are logically together).

"enhanced from GNU Emacs"... Implying that you could easily enhance Emacs is a certain way for pushing passionate users away from this.

You don't "enhance" Emacs, you hack it, extend it, write cool modes...

Eh, a beginner needs Emacs to be more extended like I need twelve more legs. Emacs is harder to learn than most of the programming languages you'll be using in it. The first thing I tried to do beyond basic open-edit-save when I started learning Emacs was change the colors to something that hurt my eyes less. After extensive Googling and playing around with the things I found, I failed. That's simple in every other text editing program I'd used up to that point, but when given the choice to improve the program's usability or "extend it" and "write cool modes," you're right, Emacs users seem to invariably prefer the latter. I can't blame people for scratching their own itch, but I don't think we should hate on people for trying to help new users either.

ErgoEmacs is really helpful to me, the only problem is that most modes shipped with Emacs (like org-mode) are still using the old c-x c-something c-blah blah keybinding, that sometimes annoys me after I have adapted ErgoEmacs keybindings. It seems no good solutions for this issue available yet.

I don't love Emacs' UI either, but imposing a new UI on it won't work, unless you rethink its entire model, in which case you'll no longer have Emacs.

A better way to help new users with Emacs' daunting learning curve might be to make a game. A fun game would get that stuff into muscle-memory pretty quickly.

But this is from Xah Lee. He's smarter than everyone on the planet and knows what's best, by fiat. If you don't believe me, just ask him.

I do not question that he would agree with you. He's not smarter than me, though. :) Or Jeff Pace: http://jpace.wordpress.com/2011/12/30/ergonomic-emacs-keybin...

People want instant gratification... Seriously. Use TextMate if you want a quick to learn, but limited, editor.

How about Emacs for Android?

Apropos of nothing, "WINE" stands for "WINE is not Emacs".

"whose" not "who's"

Reply on news.ycombinator.com