On Fri, 29 May 2009 08:57:18 +0200, Gabor Urban wrote: > In one the last postings about this topic Steven D'Aprano has written: > "As a general rule, menus are discoverable, while keyboard commands > aren't. There's nothing inherent to text editing functions which makes > then inherently undiscoverable, and KDE apps like kate and kwrite do a > reasonable job of making them so." > > I agree with this assumption if, and only if we are speaking about > outsider users.
It's not an assumption, it's a conclusion. My assumption is that everybody, no matter how experienced they are, will *at some time* be looking for some editor functionality without knowing whether or not it exists. I've never needed to (say) strip out all comments from a document, but if I ever do, if the editor makes functions discoverable, I've got a better chance of finding the command I need, rather than wasting my time programming something that's been done before. We all know of experienced system admins who have built-up an amazingly detailed amount of knowledge about the systems they've used. They can tell you about the most obscure features and functions of a system. But put them in a system which is *not quite the same* (say, Ubuntu instead of Redhat, or FreeBSD instead of Linux), and they often flounder. All the functions they're used to are in a different place, so to speak. And there's no easy way to learn that command ABC on one system is precisely the same as command XYZ on another. Only two sorts of people don't benefit from ease of discoverablity: those who know everything, and those who never do anything new. > This is a Python mailing list, which supposed to be a forum of people > using the Python programming language. So Python source is a plain text, > so Python interpreter should be a command-driven application. With no > other UI than the plain old Command Line Intreface. That Python is command-driven doesn't have *any* implications for the editor you use to write Python code. Photo-editing software is mouse- driven. That doesn't mean that you should be forced to write photo- editing programs by point-and-click. > MOre than that, all we are supposed to be techmen, who does acknowledge > and appreciate the conceot of wrtitten User Manual or Reference. All we > have learned Python from tutorials and not from the menues. We're probably better at reading manuals than average people, but that doesn't mean we *like* it. That's one of the reasons we use Python: nearly everything is discoverable from inside the Python runtime environment. We have a wealth of tools for inspecting objects. If you want to know what methods an object has, you don't have to look it up in the manual, you can inspect it with dir(). Besides, once you've been in the tech industry for long enough, you'll learn that the Python documentation is *remarkably* good compared to the average technical documentation. > As a summary, any open source editor should be perfect, which is > extensible, optionally language-sensitive, portable, basically > independent of any OS features. THat cuts the list drammatically. (1) Closed source editors have the same functional requirements as open source editors. (2) If you're waiting for perfection, you'll be waiting forever. (3) Why independent of the OS? When is the last time you've used a system without an OS? Forth programmers in the 1970s used an editor that was OS independent -- it managed files using its own unique file structure, managed memory itself, etc. Why do you want to go back there? -- Steven -- http://mail.python.org/mailman/listinfo/python-list