"Text editors should take a lesson from video games."
ozmm.org
ozmm.org
This “toy” should be the core mechanic of the game minus any goals or decisions. There is no win or lose state, just a fun thing to play with.
I liked ken's comment about Mirror's Edge not unlocking abilities, but you can't use them til you encounter the appropriate geometry in the environment (or I think, maybe you could use them before, but you didn't need to, as there were simpler more obvious ways to complete the task using abilities that you already knew about).
For example: movement in an editor. The cursor keys will allow you to do anything; but the word-movement keys can often do what you need more efficiently. Then, in vim (using it as an example because I know it), you can search to the right using "f<somechar>", and there's also F, t, T, ; and ,.
Interestingly, I've only really started to use the latter ones after years, because I'm having a touch of RSI, and I have a need for fewer keystrokes.
One could convert vim (for example) from a toy into a game by adding goals. These goals would have progressively greater difficulty such that they need the more sophisticated controls to accomplish them.
Having a need for something gives you a motivation for learning it; but it also makes it cognitively easier to learn. When you have a gap or lack in your mind crying out for a solution, acquiring the solution that fits that gap makes you feel "ah, that's better!". This makes it more memorable; and creates a strong link from the problem to the solution, making the solution accessible to you the next time you need it - making it useful to you, in practice.
A novice friendly interface should not impede an experienced user, and there should not be experience based modes. You don't see much of these days. MS Word is an example of a crappy interface. Some non-esoteric functions are hidden away in non-discoverable corners and it does magical things as a default. Eclipse is another program with a crappy interface, because of different modes and views. I have finally accommodated my self because it eases the intense pain of Java programming, but on the whole I would rather use UltraEdit.
Of course none of this applies to emacs users. They are are a secret society unto, themselves, kind of like the Masons.
Dude. Using Emacs really isn't that hard, and mystifying it doesn't do anybody any favors. (I can understand if it's not your cup of tea, though.) It just does a bad job of "creating the illusion of simplicity" (as Grady Booch once put it).
M-x describe-bindings - List of all keybindings for the current mode
M-x describe-mode - Information about the current major mode
M-x apropos - Search for info on subject
Emacs is the self describing editor!
Emacs is self-documenting, yes, but its help system (much like the rest of it!) seems to be designed for experienced users who can't quite remember the syntax for font-lock-keywords* , rather than new users who trying to figure out how to switch buffers or what "font-lock" even is. It's awesome once you get it, but using a help system to answer questions about basics shouldn't assume experience.
* http://www.emacswiki.org/emacs/FontLockKeywords
The tutorial does help, though.
The only "intuitive" interface is the nipple. After that, it's all learned.
No, not really. Babies need to learn to latch properly or it hurts the mother.
Google.
It's often pleasantly surprised that some task I thought was esoteric is actually solved in the standard emacs libs, but the fact that I had to go to Google to find it doesn't say great things about the editor's discoverability. IMO, Emacs is about as discoverable as a dynamic programming language with a decent interactive interpreter such as ipython or irb.
I'm not saying it's the wrong tradeoff -- but if you want to learn Emacs you probably should read a book or two and ideally spend some time with a master. You really can't just bring it up and figure out that M-q will conveniently re-wrap the current paragraph or that M-^ joins the current line to the previous line and removes intermediate whitespace.
C-h (Type ? for further options)
Type ? and you get a list.
From the tut:
To use the Help features, type the C-h character, and then a character saying what kind of help you want. If you are REALLY lost, type C-h ? and Emacs will tell you what kinds of help it can give. If you have typed C-h and decide you do not want any help, just type C-g to cancel it.
There are hundreds emacs commands. The fact that description for any command can be found through help doesn't mean that you've discovered them all after spending 30 minutes reading the Emacs Tutorial.
That is how pivo found it. By going "oh, I wonder what else is there" and hitting C-h ?
If you're not the type of person that does stuff like that, emacs probably isn't the editor for you. Hell, software development probably isn't for you.
Yeah, emacs is large - and has lots of features. Once you've been through the tut, and spent a few days with the editor, they're quite discoverable. It does make the assumption that you want to discover though.
That was my next guess! Drat!
Seriously though, what does "apropos" mean? In Common Lisp I always have to stop and remember it whenever I need to search packages for a symbol. A dictionary defines it as "by way of interjection or further comment", which isn't really meaningful. Maybe the name is a historical artifact?
In this case you're asking about things related to the search terms. It mirrors the Unix command that performs searches on man pages.
IT professionals I've worked with do this kind of stuff all the time to keep employees from breaking stuff until it's shown that the employees can handle the added functionality.
I also disagree that HN's downvoting feature is an example of progressive learning. It's more about controlling trolls and setting expectations in the community. You have to earn your keep before you can negatively affect change. It's a feature of the meritocracy, not of the usability.
Not to detract from the discussion, but this isn't an actual feature on YC. AFAIK, nobody can down-vote (although editors can [dead]).
you can downvote comments once your karma goes over a certain score. but nobody can downvote submissions. no doubt that's what andreyf was talking about.
also, the karma numbers keep changing, which is why nobody seems to know for sure where the thresholds are. back when i got the right to downvote comments, you only needed about 20 points.
Many other classic games (and most of my favorites) follow the same pattern. I do not think Tetris or Pac-Man would be better if you "unlocked" features on higher levels.
I do wish my text editor was better, but I want to make programming more like other successful cooperative creative activities. Maybe a Brooks surgical team, or an orchestra, would be more appropriate inspiration.
Part of me is sad that our craft seems to be losing its "take 10 years to really learn your tools". Just because "Rock Band" is a hit doesn't mean the Seattle Symphony is struggling to find musicians.
Progressive disclosure works well in computer games, which are relatively linear. Shortcuts in text editors are just that - shortcuts. Perhaps it might be more appropriate to ambiently detect when someone is going the long way about a task, and recommend a shorter route.
Ex sequence: End, Shift + Home, Del
Recommends: Ctrl + Shift + Del (Scintilla line delete shortcut)
Of course, its interface could be better structured for gradual learning - while the documentation is certainly there (info pages, C-h t), there's a lot to learn upfront. Advanced features for difficult stuff shouldn't get in the way of basic tasks.
The problem with learning emacs is that there are two phases. There's the stuff that you have to know or you can't do much of anything. Some of that is inevitably complicated, because it's slightly different from anything that a Mac or Windows user has seen before -- keyboard navigation, multiple modifier keys that can be used consecutively, keymaps and keybindings, major and minor modes, kill-and-yank instead of cut-and-paste, buffers, Emacs "windows" versus OS "windows", panes, prefix arguments).
The idea of having a gradual reveal of these features is a good one. But isn't that called the "emacs tutorial" and hasn't it been built into the editor for twenty years? ("C-h t"). Other people have argued that some of these features should be altered or compromised or disabled for new users -- it has been tried many times. I'm of the camp that hates this: You shouldn't screw up the carefully-designed semantics of emacs by installing Mac-style copy-and-paste. If you want to just visit the emacs world but aren't yet prepared to live there you should just go use TextMate or something in the meantime. It's not as if there are no alternatives.
The other, much larger portion of the learning curve is all the nonessential but incredibly powerful stuff that emacs can do: macros, customization, Dired-mode, shell-mode, hippie-expand, dabbrev, yasnippet, magit, Lisp interactive mode, gnus, org-mode, ido, Icicles, Zippy the Pinhead, Towers of Hanoi, blah blah blah. But it would take freaking forever to design a video-game-style walkthrough of all of that stuff, and the result would take forever to play through, and it would bore a lot of people because everyone's favorite 10% of the emacs universe is different.
I do think the emacs world would benefit from a lot more screencasts, but I'm not sure that going beyond that to game design is worth the trouble.
We haven't reached a dead end for editor (or interface!) innovation yet - look at ACME (http://doc.cat-v.org/plan_9/4th_edition/papers/acme/), for example. I don't like it (it's too mouse-centric for my taste), but it has quite a few interesting ideas, as does plan9. Probably, Emacs will absorb most interesting features from other editors instead ("worse is better" and all that), but good may come of questioning its assumptions.
I'm just trying to start some interesting discussion. Slow news because of the holidays, and all.
There's a big difference between fundamental power and actual usefulness. A volcano is fundamentally powerful, but good luck trying to convince it to build your house for you.
In practice, a useful fundamental power will sooner-or-later manifest itself as a big, complex, occasionally sloppy ecosystem of useful tools. We don't interact directly with geothermal energy. Instead, some people build generators that turn it into electricity, and then other people build factories to build fans that run on the electricity, and then shopkeepers build stores that can sell the fans. So, when I need to be cool, all I need to do is buy a fan, plug it in and turn it on. I don't need to start from scratch and build it all for myself.
What am I saying? I'm saying that you're welcome to start over with an emulated Lisp machine and a set of minimalist editing commands. And then you're welcome to build useful things like (e.g.) js2-mode on top of that minimalist editor. But then you will slap yourself on the head because you will discover that you've gone to all this trouble, but all you've done is rewritten emacs! Meanwhile, if I want to edit Javascript, all I do is download Yegge's js2-mode and turn it on.
But would rebuilding emacs in an innovative way be a good thing? Yes. It's not a bad idea at all. But it's hard to make it pay off. TextMate has made a very solid attempt, but I'm suspicious of the long-term merits of the closed-source, one-platform model, and an editor has to be built to last. (I note that the new fashion seems to be for TextMate users to try emacs!) And who is going to pay you to write another open-source editor? It is not a small project.
I also think it's interesting how the author of the toplevel post has a textmate minor mode (http://ozmm.org/posts/textmate_minor_mode.html) to add TextMate features to Emacs that I'm pretty sure it already has (e.g. go to symbol, find file within vc repo). I know I've re-implemented minor features of outline mode more than once.
What I envision is not a single gigantic emacs game in which you start at level 1 ("a four year old") and proceed to level 793 ("Yegge"), but a directory full of games that you can choose to play in any order, depending on your interests.
Clearly the next step is for someone to produce an emacs mode for writing wizard-ish tutorials about other emacs modes. ;)
I find I usually need to use a new feature a few times before it sinks in, this can be hard when it's not something I need very often. A game like thingy where I could try out the feature a few times (maybe completing a timed task or something) would maybe help that a lot, and could be fun too (for the weird definition of fun that applies to people who like learning new Emacs commands)!
I'd probably be up for participating in a project to create a set of these games, anyone else?
I'll check back on replies to this comment after Christmas, then maybe put up a project page.
http://www.emacswiki.org/emacs-ja/CommandLogMode
For scripted demos, I have a vision of a tool that's like the macro recorder, but that also logs the delay time between keystrokes. You can edit the recorded results if you like, adjusting the commands and the times, then play it back and it will slowly replay all the keystrokes, while echoing the name of each command into an auxiliary buffer like CommandLogMode does.
You could play back audio in sync with the replayed keys if the emacs play-audio function actually works. (Crosses fingers.)
Actually recording audio for a demo is almost certainly beyond emacs' capability. You'd have to use some audio-recording or screencasting software and edit it all together.
The game part might be done by creating a script that sets up a Game buffer, prompts the user (in a second buffer window) to perform an task in the Game buffer, and then just keeps checking the Game buffer to see if it has reached the "win" state, at which point you congratulate the user and go on to the next task. You have to also have prominent buttons for starting the task over, or for playing the standard solution for the task so that the student can watch. You might also want to keep score in keystrokes -- move the rectangle with fewer keystrokes and hear the special victory sound!
I've set up a Github thingy at https://github.com/almost/emacspractice/
Let me know your Git hub username and I'll add you as a collaborator.
We could maybe use the wiki to put some ideas together, that or just use some org-mode files in the repository itself.
A "how to use the help" game/tutorial/screencast would probably be the most useful, overall.
The Emacs tutorial starts this way, too. "Here's how you move a letter. Here's how you move a word. Here's how you move a page." It would be great (but probably too much to ask) for the same instructional style to continue through more advanced usage.
OTOH, I've been using the rectangle commands (e.g. rectangle-open, rectangle-delete) since nearly the beginning. I like them and often find them handy. So for me the right time to unlock rectangles is "on the third week".
And so it goes. Everybody's use case is different. Everybody explores a different subset first. Everyone's idea of the most important emacs feature is different. This is quite unlike a game. One major reason that games use the gradual-unlocking strategy is to keep you interested in following their linear plot. But, after the first few days, emacs doesn't have a linear plot, and we probably don't really want it to.
Grouping functionality by task in a way that would be simple to navigate would probably be a good start, though elisp doesn't really have a same namespacing system anyway. (Does XEmacs? I know it has a packaging system, but I use GNU Emacs.) Something like adding an alist or hash-table of symbols for task descriptions -> relevant functions, such as 'file, 'rectangle, 'email, 'basic wouldn't be too hard to retrofit onto the existing system. A bunch of redundancy wouldn't hurt, and a navigation system as in iswitchb or anything would probably work.
I'm busy with projects ATM, but I'd be interested in doing this...and aside from tagging existing stuff, it would be fairly quick. It could potentially be a newbie-friendlier version of apropos, because part of the problem with apropos is that you have to know general terminology in the first place.
If this already exists and I don't know about it...that might just prove my point.
Note that the emacs module system accomplishes some of the task of organizing commands into subsets. I make liberal use of describe-mode (C-h m) when I want to figure out what my options are in a given mode. Other modes actually populate the menu tree, almost like a real Mac application! (I spent almost a week paging through the docs, trying to memorize the magit commands, before I noticed that the module had helpfully installed a "Magit" menu in the menu bar. I never look up there!)
After pressing the relevant key (C-h something, also perhaps F1 or what have you, but definitely something listed on the startup screen), a prompt comes up, with a list of known keywords (basic, movement, file, buffer, latex, python, etc.). Typing filters the list for things that contain the substring (as in ido, iswitchb, anything, etc.); while this takes a bit of getting used to, there's immediate visual feedback, so it's reasonably self-explanatory.
When you hit enter, the first suggested keyword is selected, it brings up a list of everything tagged with that category. (The dialog would look like the result from apropos.)
Hopefully, most of the keyword mapping could be automatically generated, but it will inevitably need some hand-tuning.
I know to use describe-mode, apropos, apropos-variable, info, etc. when I am looking for / have forgotten about something, but that, in itself, means I'm over the hump in learning to use Emacs. New users aren't going to know what "M-x describe-mode" refers to (or even what "M-x" is).
Also, Merry Christmas.
Also, I do kind of like your idea, and I wholeheartedly agree with this:
New users aren't going to know what "M-x describe-mode" refers to (or even what "M-x" is).
Half the battle in learning Emacs is to get really, really used to all the help commands. You need to play with all of them, and you need to use them a lot, and somehow the documentation didn't really get this through to me at first. (Yegge, to his credit, makes this point 8 in his list of hints: http://steve.yegge.googlepages.com/effective-emacs)
Rectangle commands on the other hand I've not managed to internalize yet, I know they exist and I see they must be very useful. But whenever I come accross something that possibly could use them I end up using something else.
And I think that, while a walkthrough is a good idea, a video-game-style walkthrough is more trouble to create than it's worth. I could be wrong, and anyone is welcome to build such a thing. But I'd recommend more screencasts first -- I sense that there's more bang for the buck there.
(Still, the idea of a little 'ding' when you level up and unlock new commands excites the former Diablo-addict in me.)
When you're binding your own keys you need to know what that key already does so you can decide if it's something you use now or might use in the future. If it is then you probably don't want to use that key.
It would be a pretty bad situation to get to a "you've unlocked new feature X"! But then find that the key for new feature X is the same one you're fingers know to do something else. Not that you couldn't just rebind it to something else but that would just lead to a huge amount of differences from the norm with no good reason (on top of the the already huge amount of differences from the norm for a good reason that most peoples Emacs already carry around).
You can make the most complex software work for the simplest every day person if you open it up gradually. Why do I have all of the crap that currently exists in Microsoft Word if I don't even need it? Arguably, this is why there is so much hype around products such as Basecamp that are a world simpler than the current products that exist. We're trying to build 1 product to accomodate 100% of its users.