On Jun 21, 12:11 pm, Robert Uhl <[EMAIL PROTECTED]> wrote: > Twisted <[EMAIL PROTECTED]> writes: > > >> But Emacs does not have a "clunky" interface. > > > That's for the everyday novice-to-intermediate user to decide. > > Why should the ignorant decide? Do you leave the decision of what great > art is to 3 year olds and their doting parents?
Did I say it was for the "beginner" to decide? No, I said "novice-to- intermediate". How clunky versus usable an interface to a tool is is for those who invest some, but not extraordinary amounts of, time into its use to decide. If it requires years of mastery, it is clunky -- period. This may be unavoidable if it's something involved in nuclear power plants, delicate neurosurgery, or whatever. If it's a text editor, on the other hand, it's clearly going to have superior competition in the area of usability. Besides, ANY interface that involves fumbling around in the dark trying to find a light switch is clunky. You should be able to see what the hell you're doing and navigate easily. Applications that not only eschew normal methods of navigation of the interface, but force you to fumble your way between the help and the task you're trying to do, are definitely clunky. An analogy to a genuine emacs experience: you enter a workshop with some raw materials and tools. Unfortunately there's no big ceiling lights so you can just flip the switch by the door and then always be able to see where everything is. Instead there's little lights here and there by various specific tools and storage areas, and in one area a map of the place with switches to control the lights. So first you have to fumble around until you happen upon the map/light controls. Then you need to (in the dark!) hit the switch for the map/light control area itself. (Now you've found the help and gotten it to be the active pane, er "window".) Now you need to find the tool you want on the map -- OK, that was easy. Now you turn on its light. Oh, hell -- the light on the map/light controls has now gone out though! That also included the instructions on using the specific tool. You can go to and use the one tool, if you memorized those instructions, but then it's back to the darkness... (You find the help on doing a particular thing, then can't get back to the document to do it because of clunky navigation. So you go back to the help on switching windows, and now you can flip back to the document. Only you realize you can have the document and help open at the same time, but the only time the document has focus is when the help is open to "help on switching windows", which makes this rather useless! You end up having to memorize the help, because *you can't have arbitrary parts of the help and your document open side by side and be working on the document*. All because you can't simply tab or click to the document. At minimum, you have to *memorize* some arcane key controls for switching panes ... er, "windows", that are totally unintuitive and unlike what is normally used. Oops. The interface design is a nightmare. The most basic requirement, that it be easy to have the help open side by side with your document and switch back and forth and navigate inside the help easily, is broken. If you have to consult the help just to navigate the help or to switch focus between document and help, then you're trapped, and that is what happens with emacs. I don't know why people keep harping about what version. It was probably something in the low 20s, after an earlier try with one in the upper teens. The interface never improved over that time -- the biggest problem consistently being that whenever focus was successfully transferred to the document window, the help window was invariably open to the instructions for switching windows, so you could never be doing something with the document and have the help for that something available at a glance. Defeating the whole purpose of having a help system. A separate printed manual would have been better, if I could have spared the paper and toner, as I could hold that off to one side of the monitor and flip through it and open it to anywhere I wanted to, then go back to my document without even having to think about it. Even though it would be at the price of no full- text search capability -- not that I could ever get that to work in emacs anyway. There was no apparent way to do a simple substring search and click "next match" or "previous match" to navigate among the hits...more arcane keypresses would be required, and as soon as it showed you the first match inside the help, the keypress documentation of course vanished. As far as I can tell, it just is not and never was possible to get started with emacs without a separate, outside-of-emacs cheat sheet, or to be very productive at all without actually memorizing the damn thing. Modern user interfaces require a minimum of memorization, most of which is basic, standard stuff that is the same from one app to the next, so you already know it all -- your clicks and double clicks, your alt-tabs and alt-enter-for-properties etc.; application-specific keyboard shortcuts can be learned as convenient. Infrequently used commands you can stand to hunt for in menus. When you find you use one frequently, you can try to learn the keyboard shortcut -- and you can find it without even consulting the help, simply by finding the command's menu item. Every time you want to use the command but can't remember the shortcut you just find it in the menu and activate it from there, and see the shortcut while you're at it, helping to eventually memorize it. And the commonest sorts of File and Edit menu items have near-universal shortcuts, the big variation tending to be whether Redo is shift-ctrl-Z, ctrl-Y, nonexistent, or menu-only. But you can start using it right away with low productivity, and increase your productivity with proficiency and learning (optional) shortcuts, chiefly those to the commands you happen to use a lot. Not so emacs, or most other unix-heritage tools. Those you can't use in any nontrivial way without ascending a sheer cliff of memorization *first*, before doing a single useful thing. One person elsewhere in this thread even went so far as to suggest that to avoid having a similar hurdle with every application you just use emacs for everything. If you like being claustrophobically trapped in 80x24x8BPP instead of 1280x1024x32BPP, that may be your cup of tea. Also if you like having zero productivity in every single task instead of just one until you've scaled the El Capitan of user interfaces. On the other hand, you can avoid having a similar hurdle with ANY application by simply using standard GUI apps developed with Mac and Windows users in mind. I hear they even have them for Unix now -- technically including everything written for MacOSX as well as modern WMs on Linux and probably *BSD. (Use emacs for everything? That's like suggesting I move all my tools *into* that dark place with the screwy lighting system, rather than *out*. Me, I'd rather just avoid that place, or if necessary bring in a big bank of floodlights and install them, and the sensitive artiste who originally architected it be damned. Which is what Xah started this whole mess by suggesting, in effect.) -- http://mail.python.org/mailman/listinfo/python-list