"Text editors should take a lesson from video games."(ozmm.org)
ozmm.org
"Text editors should take a lesson from video games."
http://ozmm.org/posts/learning_your_editor.html
9 comments
Toy vs Game, an interesting distinction in this context.
A couple of decades ago, a couple of us wrote a word processor. We thought a lot about the issues of novices and usability and came to the conclusion that users are novices for only a short time and spend most of their time as intermediates. True power users are few. So basic operations should be intuitive even if not strictly consistent. Everything else should be easily discoverable. Really esoteric things could be left to the manual, but still discoverable.
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.
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.
> 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).
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).
I love emacs, but it is anything but inuitive. None of its features are discoverable and to learn how to use it you have to read a bunch of info pages.
Um.. most of Emacs' features are discoverable:
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!
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!
The problem is, to read those, you already have to know what "M-x" means. Catch-22.
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.
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.
emacs tells you what "M-x" means on the introduction screen each time you start it.
The only "intuitive" interface is the nipple. After that, it's all learned.
The only "intuitive" interface is the nipple. After that, it's all learned.
I have used Emacs on almost every day of my life for about 10 years. I love Emacs and use those functions (as well as describe-key) fairly frequently. What's my favorite way to figure out how to do some random arcane thing in emacs?
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.
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.
Emacswiki (http://emacswiki.org) is also quite helpful, FWIW, and it always helps to have someone around who will patiently answer questions.
And how did you discover those commands?
I spent about 30 minutes reading the the Emacs Tutorial when I first starting using the editor.
I can't find `describe-bindings` or `C-h b` to be mentioned in the tutorial.
C-h and a bit of a pause gives you:
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.
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.
The fact that `C-h b` is not mentioned in the tutorial doesn't imply that one can't find it or doesn't know how to use 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.
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.
The point is that the direct link to 'C-h b' is mentioned in the tutorial. That section of the tutorial also has sections on a few of the options in C-h.
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 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.
M-x apropos - Search for info on subject
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?
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?
As an adjective it means relevant. As a preposition (apropos of) it means concerning or related to.
In this case you're asking about things related to the search terms. It mirrors the Unix command that performs searches on man pages.
In this case you're asking about things related to the search terms. It mirrors the Unix command that performs searches on man pages.
[deleted]
Any complex system that is useful when only provided the most basic functionality could "take a lesson from video games". It's essentially building the learning curve of the system into the functionality. It's really not unlike HN's system of disabling downvoting until certain karma is reached.
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.
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.
Progressive learning for apps in general is definitely an improvement. That being said, I don't agree that roping off functionaltiy is the best way for advanced text editors to lower the learning curve. Contextual hints are a better way to introduce shortcuts for those sort of apps.
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.
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.
I agree with you that the downvoting is a meritocracy, but that's my point. A user has to earn the right to use that particular function. The difference in learning how a piece of functionality is used and why or in when it should be used is two sides of the same coin.
A user has to earn the right to use that particular function
Not to detract from the discussion, but this isn't an actual feature on YC. AFAIK, nobody can down-vote (although editors can [dead]).
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 have to reach a certain karma score to be able to downvote individual comments. I can't remember what the score is, but its fairly low.
50 or so in my case. But the person who thinks the feature doesn't exist has a karma of 2053. Maybe it's not conditioned just on karma?
no, it's that you're talking about two different things.
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.
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.
Thanks for the clarification!
Mirror's Edge (the only game in recent memory that looked interesting to me) seems to brag that it doesn't have you "unlock" features as you go along -- your character can always do everything, but you seem to gain skills simply because you come across geometry that allows it. They liken this to Prince of Persia, which I have not played but apparently was similar.
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.
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.
Microsoft did this with the Paperclip in Microsoft Word.
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)
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)
Emacs already does something like this, albeit to a much lesser extent: Some useful commands, such as set-goal-column (C-x C-n) or narrow-to-region (C-x n n) are disabled by default and will ask if you actually intended to use them - otherwise, bumping C-x C-n would be really confusing, for example. (It makes the cursor jump to a specific column whenever you move up/down a line.)
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.
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.
I just don't think there's a market for yet another Simplified Emacs. Isn't that what jove and joe and nano are for? Isn't that what every other editor on the market is for?
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.
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.
Unless it's radically different. There's a lot of cruft in Emacs (I mean, it has enough mass to pull things into orbit...), but little of that has anything to do with what makes Emacs fundamentally powerful: it's an emulated Lisp machine. I know I have a fierce minimalist streak, but I wonder what could be done with a new Emacs with a clean break - all of the mini-Emacsen I've seen (e.g. mg) have preserved the default keybindings (C-x C-f, C-n, etc.) but dropped the core extensibility. Perhaps the reverse would be more fruitful?
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.
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.
what makes Emacs fundamentally powerful: it's an emulated Lisp machine.
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.
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.
"But it's hard to make it pay off." Absolutely. Emacs is already out. Similarly, while Elisp has its flaws (the lack of a good namespace system comes to mind), it's probably good enough. Efforts to rewrite Emacs in Common Lisp or Scheme seem to stall out, even (and the thought of porting all that legacy code is rather off-putting).
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.
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.
Hm, on second thought, I will amend my previous skepticism slightly. I wonder whether some emacs minigames might be useful. It might be that the best way to learn about, say, the rectangle commands is to play a little rectangle minigame.
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. ;)
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. ;)
That's a brilliant idea! Anyone fancy actually doing this?
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.
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.
One might leverage some of the code from "Command Log Mode", aka mwe-log-commands, if it works the way the wiki seems to think it does:
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!
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!
Yeah, that sounds about right, and command log mode locks like a good
base to build from. The real trick will probably be in coming up with
tasks that are both interesting and useful.
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.
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.
That's actually what I was expecting the first time I hit C-h t: Not just a verbal description of each feature, but a demonstration of it, perhaps in a sandboxed environment where only the features described so far were enabled, along with some command to exit or reset everything. I still haven't learned emacs, so I'd find that valuable.
You could start with http://video.google.com/videosearch?q=emacs
Me too, until I saw the "Copyright (c) 1985" at the start.
More task-specific tutorial games? ("You are in a maze of twisty little passages, all alike...")
A "how to use the help" game/tutorial/screencast would probably be the most useful, overall.
A "how to use the help" game/tutorial/screencast would probably be the most useful, overall.
Part of the idea behind this post is that the keys (such as C-x C-n) aren't even bound - that way describe-bindings and friends are kept relatively spartan until the features (power-ups?) are unlocked. As it is, the help functions are pretty intimidating with the amount of information available to you.
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.
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.
The problem is: when do you unlock C-x C-n? I am sad to admit that I still never remember that set-goal-column exists. So the right time to unlock it for me seems to be "about ten years into the emacs experience".
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.
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.
Also, what is basic will vary from user to user.
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.
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.
So, this isn't info-emacs-manual, but rather a system that lets you actually invoke a command by first choosing a category of commands, then choosing from a list of possible commands? Interesting.
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!)
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!)
I'm thinking of something along these lines:
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.
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.
Merry Christmas to you!
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)
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)
The idea of goal column seemed so bizarre to me at first ("why the
hell would anyone want to do that?") that I had no problem remembering
what it did. Then I just kept on coming across situations where it's
really useful (mainly when defining macros, but elsewhere as well).
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.
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.
But don't you agree there are probably basic, useful editing commands you missed along the way?
Sure. I just don't think that disabling all the other commands is necessarily going to help me find them.
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.
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.
Yeah, I think you're right about the screencasts.
(Still, the idea of a little 'ding' when you level up and unlock new commands excites the former Diablo-addict in me.)
(Still, the idea of a little 'ding' when you level up and unlock new commands excites the former Diablo-addict in me.)
That wouldn't by such a great idea in my opinion, it's not such an
advanced thing in Emacs to be rebinding keys, it's almost essential
for normal use in fact.
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).
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).
I think the next killer apps will consist of software that is gradually opened up as the user becomes more familiar with it. You can take this approach with anything, but I love the fact that the writer referenced to video games. Heck, there is a LOT from video games we can learn like a point system. If you want a great example, look at www.thesixtyone.com (I am not behind that, but I am familiar with who created it, former guys who worked at Electronic Arts).
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.
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.
Unfortunately, the goals of a video game are not similar to the goals of learning to use and using an editor. The only thing you gain from not having all tools immediately available at your disposal/discoverable is frustration because you're still in the editor and not done editing. Game playing is a task unto itself, editing is a means to an end.
When you get to the last boss of a video game you dont stop and think: "What was that command that was used to whip out my stape gun so I can staple his tentacles to the wall since I havent used that gun since level 1?" Then go though 10 manuals, google, and a buch of other crap and find out the command was:
^x+' obvious right? Just like copy-paste in vim.
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.