I always thought one of the nice concepts that WS did was the presentation of the command menu.
WordStar worked with prefixes, much like Emacs. I think it used ^K and ^Q. But, no matter.
The important thing was that if you hit one of the prefix keys, a menu of all the commands would come up. And it was a non trivial menu. More a panel, full screen width, 8-10 lines long.
However, if you were fast enough, the menu didn’t appear. Or if you hit the second key of the command, it would abort the menu presentation, restore the screen and keep going.
This was important because the displays were slow. It worked on serial terminals, and rendering that menu took quite some time. Of course while it was displaying, and aborting, and restoring the display, it was buffering the keystrokes.
Not a small task on a 2Mhz 8080.
Simply, a lot of work went into this key component of the experience, to keep the interface out of your way, yet novice friendly and responsive on the very slow hardware we had back in the day.
Omg! We have this exact functionality nowadays in emacs with which-key (which incidentally is going to be included as part of core emacs in the next version), so I guess wordstar is where the idea originally comes from! That's so interesting :D
I don't know what the maintainers chose, but honestly, which-key would be an awesome default to have turned on.
It's soooo helpful for discovery and recall of commands (which is a huge problem with such a complicated application as Emacs!) that the fact that which-key was included by default in Spacemacs half a decade ago is a big reason I am as proficient in Emacs as I am today, and I'm sure there are others who feel the same.
It would be very, very useful for new users. Experienced users can turn it off if they don't like it -- much like the menu bars that are on by default in Emacs.
Yeah I suppose. I find M-x describe-bindings works fine when I need help.
Maybe something like "on by default if there's no .emacs" (so likely a new user) but if there is a .emacs then only on if enabled. But that probably has at least as many downsides as up.
I guess I'll just disable it along with the menus and scrollbars as I already do.
where which-key really excels is when you're already halfway through a complicated series of keyboard shortcuts and can't remember the next sequence.
you pause, and the menu pops up to remind you
using describe bindings you have to ctrl-g out of your half entered command, run describe bindings, search for what you wanted to do (without context -- which-key has the context of your half built command and only shows relevant commands, but describe-bindings just shows everything), make note of it, dismiss the documentation buffer, and then repeat the whole command again to try again
much easier to have which-key pop up and remind you of how to continue while you're still in the middle of it, and go away on its own when you continue
if you're really proficient you won't even have to turn it off because it only appears when you pause, so you'll go so fast you never see it
which-key is not a replacement for describe-bindings, it's a contextual tool to surface that information automatically when it's needed and to dismiss it or not display it when it's not
Thanks for the added detail. Guess I'll give it a try. But I really tend to dislike behaviors that kick in when I pause, because I pause for a lot of reasons other than not remembering what comes next. It's why I also tend to disable all forms of auto-complete.
WordStar worked with prefixes, much like Emacs. I think it used ^K and ^Q. But, no matter.
The important thing was that if you hit one of the prefix keys, a menu of all the commands would come up. And it was a non trivial menu. More a panel, full screen width, 8-10 lines long.
However, if you were fast enough, the menu didn’t appear. Or if you hit the second key of the command, it would abort the menu presentation, restore the screen and keep going.
This was important because the displays were slow. It worked on serial terminals, and rendering that menu took quite some time. Of course while it was displaying, and aborting, and restoring the display, it was buffering the keystrokes.
Not a small task on a 2Mhz 8080.
Simply, a lot of work went into this key component of the experience, to keep the interface out of your way, yet novice friendly and responsive on the very slow hardware we had back in the day.