Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
On Jun 8, 7:30 pm, "Jürgen Exner" <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > [nothing relevant to Perl] Perl?? Perl is even less relevant to Java than the original post, which admittedly has some connection to pretty much all programming languages. (Perl, on the other hand, has no connection to any known programming language. ;) In particular, Perl code looks more like line noise than like code from any known programming language. ;)) -- http://mail.python.org/mailman/listinfo/python-list
Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
On Jun 9, 8:21 pm, "BCB" <[EMAIL PROTECTED]> wrote: > "Paul McGuire" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > > > On Jun 9, 6:49 am, Lew <[EMAIL PROTECTED]> wrote: > >> > In particular, Perl code looks more like line > >> > noise than like code from any known programming language. ;)) > > >> Hmm - I know of APL and SNOBOL. > > >> -- > >> Lew > > > TECO editor commands. I don't have direct experience with TECO, but > > I've heard that a common diversion was to type random characters on > > the command line, and see what the editor would do. > > > -- Paul > > J > > http://www.jsoftware.com/ Oh come on! Toy languages (such as any set of editor commands) and joke languages (ala Intercal) don't count, even if they are technically Turing-complete. ;) Nor does anything that was designed for the every-character-at-a- premium punch-card era, particularly if it is, or rhymes with, "COBOL". Those have excuses, like it's a joke or it's a constrained environment. Perl, unfortunately, has no such excuses. If there were such a thing as "embedded Perl", I'd have to hesitate here, but since there isn't... -- http://mail.python.org/mailman/listinfo/python-list
Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
On Jun 10, 8:50 pm, "BCB" <[EMAIL PROTECTED]> wrote: > I wholeheartedly agree, and did not mean to imply as much in my original > post, in which my intent was to emphasize the fact that, until you learn the > language, a J program /does/ resemble line noise! :-) Eh. This isn't right. The whole discussion was supposed to have died after the original Perl joke, certainly after the subsequent exclusion of joke and toy languages. I think I made it clear also that an editor's command set, Turing-complete though it may be, constitutes a toy language. Anyway I amend the original claim to cover joke languages, toy languages, and any write-only languages that mysteriously aren't considered to fall into either of the former two categories. After all, you can't really take a language seriously if it's either impossible to write unmaintainable code in it OR impossible to write maintainable code in it. The one is necessarily trivial, and the other unsuitable for anything serious, except as a machine-compiled intermediate format or a mechanism for assuring job security. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
On Jun 11, 2:42 am, Joachim Durchholz <[EMAIL PROTECTED]> wrote: > It is possible to write maintainable Perl. Interesting (spoken in the tone of someone hearing about a purported sighting of Bigfoot, or maybe a UFO). Still, extraordinary claims require extraordinary evidence. (And no, a fuzzy picture of something that might be a giant serpent-like thing in the loch, or equivalent, does not constitute "extraordinary evidence".) -- http://mail.python.org/mailman/listinfo/python-list
Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
On Jun 11, 5:36 pm, Tim Bradshaw <[EMAIL PROTECTED]> wrote: > I think it's just obvious that this is the case. What would *stop* > you writing maintainable Perl? For starters, the fact that there are about six zillion obscure operators represented by punctuation marks, instead of a dozen or so. More generally, the fact that it comes out looking like modem barf, and modem barf is unmaintainable. ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
On Jun 11, 8:57 pm, Patricia Shanahan <[EMAIL PROTECTED]> wrote: > I wrote a Perl script to process logic analyzer traces for some hardware > engineers. While I was out of the office, they found they needed to > process a new record type. They didn't want to delay their work until I > got back, and one of the EEs knew Perl, so he modified my script. > > The change was done correctly. It not only worked. Except for a couple > of comments calling my attention to the changes, it looked as though > the new record type had always been there. *blinks* Hallelujah! It's a miracle! Praise be the Lord! This must surely be a sign... a sign of the End Times. :P -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
On Jun 17, 11:13 am, Xah Lee <[EMAIL PROTECTED]> wrote: [snip] Whoa. Xah posted something I agree with wholeheartedly. Imagine that. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
On Jun 20, 1:59 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > On Jun 19, 9:21 pm, Ed <[EMAIL PROTECTED]> wrote: > > > Have you ever seen an, "Extractmethod," function for emacs? Whereby > > you highlight some lines of code, press a key, and the code is whisked > > into its ownmethod, with the appropriatemethodinvocation left in > > its place. If you could post a link, that'd be just champion. > > xrefactory does this. I tried it once. It's a bit pricey , though. Someone is charging money for an emacs addon? Are they nuts? A lot of people won't touch emacs with a ten foot pole, and emacs is free. How many would actually pay for something that's useless without emacs? Especially given the near-certainty that the price is almost pure profit margin... -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
On Jun 20, 12:39 pm, [EMAIL PROTECTED] (Joel J. Adamson) wrote: > The point is that the responsibility to customize is on the user. Given that in its out-of-the-box configuration it's well-nigh unusable without a printed-out "cheat sheet" of some kind, of the sort that were supposed to have died out in the 80s, getting it customized poses something of a catch-22 for anyone trying to get started using it. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 20, 8:52 am, Bjorn Borud <[EMAIL PROTECTED]> wrote: > I found Emacs to be user friendly, but in a different sense than the, > IMHO faulty definition, "beginner friendly". Emacs let me, as a user, > do more with less effort and provides a lot less friction than many > other developer tools I've used. at work I use it extensively, and we > have lots of neat extensions that really save a lot of time. Being beginner-friendly doesn't have to be at the expense of power or expert-user usability. On the other hand, being actively beginner-hostile leads to nobody adopting the tool. Then again, if you don't mind being the last generation that'll ever use it, then I guess you're okay with that. If it suits its existing users, the rest of us will just continue to use something else. I continue to suspect that there's an ulterior motive for making and keeping certain software actively beginner-hostile; a certain macho elitism also seen with light aircraft pilots and commented on at www.asktog.com (exact URL escapes me; sorry). -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
On Jun 20, 9:09 am, Kaldrenon <[EMAIL PROTECTED]> wrote: > Imagine that a man invents a vehicle that's far safer and more > maneuverable than any existing vehicle. Imagine that the increased > safety comes from the fact that it has five wheels. How incredibly > stupid would it be for that inventor to then say, "I'm going to > convince people to buy my new vehicle, which is safer thanks to this > fifth wheel. But in order to market it, I'll take the fifth wheel off, > so it's more familiar and comfortable for them." Imagine that a man invents a vehicle that's far safer and more maneuverable than any existing vehicle. Imagine that the increased safety comes from the fact that it has five wheels. Gratuitously, he also has his own peculiar ideas regarding how one should control this vehicle, and instead of giving it a normal car steering wheel, brake, and gas pedal, he gives it two stick-like left and right throttle controls, which can be pulled back to brake and even reverse the car, pushed forwards to accelerate it, and positioned differently to cause the vehicle to rotate -- even to rotate in place, obviating the need for three-point turns and simplifying parallel parking somewhat. Unfortunately, nobody used to a normal car is remotely comfortable with these controls. They have a very steep learning curve and numerous accidents result. It turns out there's even a conversion kit available for replacing them with a normal steering wheel, brake, and gas pedal, but getting the conversion kit without crashing on the way to where you get it proves problematic because of the same unusual controls you're trying to replace. All of the driving schools, of course, teach the usual wheel-and-pedals method of controlling a motor vehicle... This seems to be a closer analogy with emacs versus normal Windows text editors. Arguably even the weird controls are superior in some way -- but only if you got used to them, which will never happen because you'll abandon it for inability to be productive with it long before that can happen, and also because the same clunky controls hobble your access to the online help that would otherwise smooth the path for you. The same problem plagues attempts to reconfigure the controls to something more normal. And the computer-driving schools -- computer classes in ordinary school -- teach standard Windows UI conventions (or their Macintosh equivalents, which correspond closely to one another). If there is any formal training in emacs use, it's effectively unobtainable due to obscurity and hard-to-findness, geographical distance, expense, or even more than one of those factors. The above applies equally to vi and its derivatives, if not more so -- vi is like taking that same already-wacky car with the two separate throttles and adding, in a fit of quaint nostalgia, the need to actually crank-start its engine. ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 20, 4:35 pm, David Kastrup <[EMAIL PROTECTED]> wrote: > Twisted <[EMAIL PROTECTED]> writes: > > On the other hand, being actively beginner-hostile leads to nobody > > adopting the tool. Then again, if you don't mind being the last > > generation that'll ever use it, then I guess you're okay with > > that. If it suits its existing users, the rest of us will just > > continue to use something else. > > > I continue to suspect that there's an ulterior motive for making and > > keeping certain software actively beginner-hostile; a certain macho > > elitism also seen with light aircraft pilots and commented on at > >www.asktog.com(exact URL escapes me; sorry). > > You are babbling. No, I am not. You, however, are being gratuitously insulting. > Emacs is amazingly beginner-friendly for the power and flexibility it > provides. [snip] That's a joke, right? I tried it a time or two. Every time it was rapidly apparent that doing anything non-trivial would require consulting a cheat sheet. The printed-out kind, since navigating to the help and back without already having the help displayed and open to the command reference was also non-trivial. Four hours of wasted time later, with zero productivity to show for it, I deleted it. The same thing happened again, so it wasn't a bad day or a fluke or a one-off or the particular version, either. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
On Jun 20, 4:21 pm, BartlebyScrivener <[EMAIL PROTECTED]> wrote: > On Jun 17, 10:13 am, Xah Lee <[EMAIL PROTECTED]> wrote: > > > [this post is a excerpt from > > The Modernization of Emacs > > > > SIMPLE CHANGES > > At the command line, change "emacs" to "gvim" Out of the frying pan and into the fire... -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 20, 4:49 pm, Twisted <[EMAIL PROTECTED]> wrote: > On Jun 20, 4:35 pm, David Kastrup <[EMAIL PROTECTED]> wrote: > > Twisted <[EMAIL PROTECTED]> writes: > > > I continue to suspect that there's an ulterior motive for making and > > > keeping certain software actively beginner-hostile; a certain macho > > > elitism also seen with light aircraft pilots and commented on at > > >www.asktog.com(exactURL escapes me; sorry). > > > You are babbling. > > No, I am not. You, however, are being gratuitously insulting. I have that exact URL now -- http://www.asktog.com/columns/027InterfacesThatKill.html The most relevant section is towards the bottom of the page. Curiously, you can jump right to it with a text-find of the word "girls". -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 20, 5:03 pm, Kaldrenon <[EMAIL PROTECTED]> wrote: > I still have a good deal to learn, even of the basics, but I've toyed > with it casually for a little bit (a total of two hours at most, but > almost certainly less) and I already know enough that finding out how > to do anything else IS trivial. It's not a program whose controls > throw themselves at you, exactly, but with a touch of patience and a > genuine interest in learning, it's not too bad. I don't know what software you're describing, but it's obviously not emacs, unless there have been some HUGE changes to (at minimum) the help and pane-navigation (er, excuse me, "window"-navigation) controls... My experiences (with emacs and with a lot of other supposedly- superior, usually unix-heritage software) put me in mind of an analogy: fumbling around in a strange house in the dark without a flashlight, banging into furniture frequently, trying to find a light switch, but it turns out the switches are all spring-loaded. For some reason (saving electricity and fighting the war against global warming?) if you go to start doing anything else the light goes off again immediately -- so you have to stand there holding the switch, memorize the contents of the room, and then quickly do whatever you needed to do before your memory of the room's layout and where things are fades! Then back to the switch, or trip and fumble your way to a different room's switch...wash, rinse, repeat... Nobody would actually design a home (or a workplace) like that in a trillion years, global warming be damned. So why do people still sometimes design software like that? Oh and did I mention that these houses' layouts are also totally strange, with the living room on the top floor and the kitchen in the basement, or other things of that nature, so you can't transfer any knowledge of conventional home designs to aid in your navigation there...and they are even all different from one another, nevermind "normal" houses... BTW, is anyone else finding Google Groups especially ornery of late? I get all of the following, recurrently: * I enter one reply in a thread, and it works. Then I go to make a second reply, and I get a text box like one uses to enter a reply, except evidently read-only -- I can select text but there is no blinking cursor. * The fix seems to be to navigate off the page and back. Unfortunately, that then pops up some dialog. I think GG is trying to protect me from losing unsaved changes, except that there are obviously no unsaved changes to the (read-only!) form for me to lose! * The "back" button is wonky -- it seems to require hitting back *twice* to go back *one* page to the previous page of the thread or to the newsgroup's thread index, if already on the first (or only) page. * After *that*, "forward" behaves sometimes normally and sometimes as "forward and then click a reply link on some random post"?? * Submitting a post results in the form disappearing and being replaced by "The post was entered successfully". Of course, if it turns out to have NOT been all that successful as evidenced from refreshing the page or using an external newsserver (I have found one read-only one suitable for verifying that a posting succeeded and propagated beyond GG's server), there's no way to get back to the form to try to resubmit the text, or even to recover it to the clipboard to paste into a fresh form for a fresh attempt. So far, it's never actually lied and claimed a posting was successful that wasn't, but there's a first time for everything, and we all know the track record for QA in the software industry ... and the way one of the more common failure modes of software is silent failure, claiming success on failure, claiming failure on success, or claiming one failure when a different failure happened! (All the various forms of diagnostics failure...) I guess I have to pre-emptively copy the form contents to the clipboard before clicking submit, and preserve the clipboard contents pending verification, or risk catastrophic data loss, because GG can't be arsed to make a decent interface, or even to leave well enough alone and stop constantly changing it. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 20, 5:21 pm, David Kastrup <[EMAIL PROTECTED]> wrote: > Twisted <[EMAIL PROTECTED]> writes: > > On Jun 20, 4:49 pm, Twisted <[EMAIL PROTECTED]> wrote: > >> On Jun 20, 4:35 pm, David Kastrup <[EMAIL PROTECTED]> wrote: > >> > Twisted <[EMAIL PROTECTED]> writes: > >> > > I continue to suspect that there's an ulterior motive for making and > >> > > keeping certain software actively beginner-hostile; a certain macho > >> > > elitism also seen with light aircraft pilots and commented on at > >> > >www.asktog.com(exactURLescapes me; sorry). > > >> > You are babbling. > > >> No, I am not. You, however, are being gratuitously insulting. > > > I have that exact URL now -- > >http://www.asktog.com/columns/027InterfacesThatKill.html > > Utterly unrelated to Emacs. I think it is quite relevant. Clunky computer interfaces may not be so dramatically dangerous, but they certainly can hamper productivity. Between Windows bugs and gratuitous misfeatures (e.g. DRM) and Unix clunkiness, billions of dollars of potential productivity is lost worldwide every *month*. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 20, 5:22 pm, Matthias Buelow <[EMAIL PROTECTED]> wrote: > Twisted wrote: > > That's a joke, right? I tried it a time or two. Every time it was > > rapidly apparent that doing anything non-trivial would require > > consulting a cheat sheet. The printed-out kind, since navigating to > > the help and back without already having the help displayed and open > > to the command reference was also non-trivial. > > Ah, yes.. we live in a time where no-one seems to have the patience to > read documentation anymore. Maybe that's why there is such a scarcity of > good documentation with many "modern" software packages. Emacs does have documentation. The problem is you have to already know a load of emacs navigation oddities^Wkeyboard commands to get to and use it. Also, basic tasks should not require consulting the documentation, unless the application genre is new to the user. Basic tasks requiring the uninitiated to consult the documentation is okay in 3D modeling apps, given the "uninitiated" have used none before. Basic tasks requiring the uninitiated to consult the documentation is absolutely ludicrous in a text editor. I count "consulting the documentation" as one of those basic tasks, along with the fundamental editing, saving, loading, and searching functionality (including, of course, "searching the documentation"). > ``I abhor a system designed for the "user", if that word is a coded > pejorative meaning "stupid and unsophisticated".'' Yeah, and I abhor the elitist systems that are designed with the philosophy that anyone who hasn't mastered years of arcane memorization and training in just that one idiosyncratic system is / ipso facto/ "stupid and unsophisticated". Most of us 6 and a half billion people have better uses for our time, such as buckling in and being promptly productive, once we're out of high school or college, and fully three and a quarter of us are at least as smart as average, and so /ipso facto/ *not* "stupid and unsophisticated". -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 20, 5:35 pm, David Kastrup <[EMAIL PROTECTED]> wrote: > But Emacs does not have a "clunky" interface. That's for the everyday novice-to-intermediate user to decide. Your gnu.org email address (and attitude) clearly marks you as not a normal user, and so your opinion doesn't count. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 20, 5:37 pm, David Kastrup <[EMAIL PROTECTED]> wrote: > ...spewing...babbling... I won't dignify your insulting twaddle and random ad-hominem verbiage with any more responses after this one. Something with actual logical argumentation to rebut may be another matter of course. One more GG issue: those stupid star ratings. So potentially prejudicial. So easy to game, as evidenced by your managing to somehow vote 82 times(!) against one of my posts in a matter of minutes. So far I've found a less-impressive method to game them -- it's not hard to get throwaway accounts elsewhere, send yourself there a gmail invite, and create many GG accounts. Handy to get around their onerous posting limits. Handy for stuffing the star-vote ballot boxes with multiple votes, too, but there's no way I can see to generate 82 of them that fast by that method, and that much logging in and out in that short a time using different accounts but from just one IP address is sure to come up on Google's radar somehow, with unpredictable but probably bad results. How did you do it? I'm guessing they stop the link for voting appearing as a usable link on the page for a) your own posts and b) the ones you've voted for, but the link's URL still works, so if you use a script to keep fetching the appropriate URL ... -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
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 prod
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 21, 12:09 pm, Robert Uhl <[EMAIL PROTECTED]> wrote:
> Twisted <[EMAIL PROTECTED]> writes:
>
> >> > I have that exact URL now --
> >> >http://www.asktog.com/columns/027InterfacesThatKill.html
>
> >> Utterly unrelated to Emacs.
>
> > I think it is quite relevant. Clunky computer interfaces may not be so
> > dramatically dangerous, but they certainly can hamper productivity.
>
> You're quite right. Windows/Mac user interfaces are so clunky that they
> massively hamper productivity.
This is a joke, right?
> Emacs, OTOH, enables it. For example,
> C-s is search forward; C-r is search backward ('reverse'); C-M-s is
> search forward for a regular expression; C-M-r is search backward for a
> regular expression.
Aside from the collision with the standard in the case of C-s (should
be save focused document if it has unsaved changes), these present no
problem. The inability to find and use them without memorizing all
those keystrokes does present a problem.
> A Windows or Mac editor would have C-s for save,
> and that's it. It might have C-f for find, but it'd pop up a dialogue
> instead of offering an interactive search, causing a mental context
> switch.
Eh? In other words, it works the way it's supposed to. That dialogue
will ordinarily be modeless but floating, so you can get it out of the
way or use it to navigate the document, then edit the document without
having to close the dialogue, and avoid the dialogue disappearing
behind other things. New search can be typed in at the drop of a hat.
Some editors have regular expression searches. All have a
straightforward substring search. Generally if there's anything in the
least arcane (e.g. regular expression searches) there's a ? button to
pop up help, which goes directly to the search help. You can read this
and tab back to the search dialogue with ease, and get them side by
side without any mess or fuss. Of course the dialog offers search
forward and usually search backward. And it normally also offers
search-AND-REPLACE, to boot.
Is this somehow not "interactive" enough for you? Versus having to
memorize a bunch of keys. It also means no esc-meta-alt-ctrl-shift BS,
as the document window needs to have only a few bindings, such as C-f
and C-s, and only the one (C-f) for search; all the search bindings in
the one window in emacs get replaced by just one binding in the
document window and a bunch applicable to the find dialogue. And the
find dialogue can be operated without knowing the bindings by mouse,
and the bindings can be seen directly in the find dialogue by
underlined letters on button labels (see that underlined N in "find
Next"? It means you can hit alt-N while the dialogue has focus,
followed by alt-tab to jump to the document with the next occurrence
selected, or alt-N repeatedly to jump to later occurrences until you
see the one you want, just in case you have rodent allergies).
It has useful key bindings. It is also wise enough to make learning
them optional, so you can learn the ones that speed up your most
common tasks and spare the effort otherwise, where it would consume
more time than it would eventually save you (less common tasks). With
an emacs type interface, you only get to ignore the key bindings for
commands you will NEVER use, rather than ones you use but
infrequently. Forgetting the latter means a trip to the help every
time, also.
> Searching would interrupt one's flow of thought rather than being part of it.
Where does this come from?
--
http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 21, 11:06 am, [EMAIL PROTECTED] (Joel J. Adamson) wrote: > And it's baloney! No one in my office that uses one of these supposedly > user-friendly machines thinks that it's actually easy to use. They > slam their keyboards and throw their hands up *every* day. Because of bugs or the network going down or stuff like that, I'll bet, not because they can't find out or remember how to do some basic task. That's entirely orthogonal to the issue of interface learning curve OR interface ease-of-use. Emacs has deficiencies in both areas, if principally the former. (For an example of the latter, consider opening a file. Can't remember the exact spelling and capitalization of the file name? Sorry, bud, you're SOL. Go find it in some other app and memorize the name, then return to emacs. Now THAT is what I call disruptive context switching. Meanwhile even the lowly Notepad responds to "open" by displaying a list of text files and tools to navigate the folder hierarchy without having to do it blind, while still letting you blind-type a path if you remember it. And you can also paste the path in from the clipboard. Unix systems don't even *have* a proper system-wide clipboard and copy/paste capability. Under X there's a weak, text-only imitation, which doesn't help you much when you want to copy a selection from an image in a paint program and paste it into a CAD or web-design or specialized image-manipulation tool or whatever...you have to save it to a file and load it, which is a pain in the butt and slowly clutters your hard drive with "temporary" files you occasionally forget to delete. > The only solution that really works is for people to _learn_ how to > use computers, and to accept that it will be a challenge. How much learning it takes can be varied by the programmer, however. They can choose to make the learning curve steeply vertical at takeoff, or they can make it start out shallow and climb steeply only when the user desires expert functionality. (They can also, stupidly, choose to leave out fancier functionality entirely, of course.) As for bugs and other frustrations, better robustness in the key areas of memory management and concurrency control is needed. Most serious (especially crash-causing, data-losing, or data-corrupting) bugs involve memory mismanagement and a lot more, as well as other serious bugs, result from race conditions. These sorts of bugs are also responsible for a lot of security holes -- buffer overrun exploits are only possible against targets with memory management and input validation bugs. Java apps, due to Java's memory management model, are immune to these. The Windows world may have a fair bit to learn from the Unix world about software reliability and QA, and also about better supporting task automation. But not about user interface design for when tasks are done manually. > And as for the arcane commands needed to get to the help page, their > on the splash screen. Have you used Emacs recently? Of course not. It's too hard to get started using it, so I gave up on it years ago. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 21, 12:03 pm, Robert Uhl <[EMAIL PROTECTED]> wrote: > Twisted <[EMAIL PROTECTED]> writes: > > >> Emacs is amazingly beginner-friendly for the power and flexibility it > >> provides. [snip] > > > That's a joke, right? I tried it a time or two. Every time it was > > rapidly apparent that doing anything non-trivial would require > > consulting a cheat sheet. The printed-out kind, since navigating to > > the help and back without already having the help displayed and open > > to the command reference was also non-trivial. > > C-h i, C-x b RET is non-trivial?!? Let's change that so that you see it the way most human beings see it: > > navigating to > > the help and back without already having the help displayed and open > > to the command reference was also non-trivial. > Erh h, dhsd f hHE is non-trivial? I'm sorry. I don't speak Chinese. I trust I've made my point. Not only does it insist you learn a whole other language (though I'm guessing it's not actually Chinese -- Greek, maybe), even when you know that's a bunch of keystrokes and even what they are... HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD TELL THEM THOSE ARE THE KEYS TO REACH THE HELP?! I suppose it just pops in there by divine inspiration? Or it's supposed to be self-evident to anyone who has TRUE wisdom? Or maybe it's just expected that you be mentored by an expert, who would know that arcane incantation and could pass it on to a new student. Well I've got news for you buddy -- there's no such thing as divine inspiration, it's not self-evident, and most people can't afford (if they could find) a tutor just to learn how to use A TEXT EDITOR. Of course, Notepad is so easy to use it doesn't even need help, despite which it's readily available. In case you forgot the bog- standard (and therefore it IS self-evident) "F1" there's even a "Help" menu in plain view as soon as you open a Notepad. This is the lowly Notepad, which I'll freely admit is the rusty bicycle of text editors, and it's much easier to use (including the help) than the supposed Mercedes-Benz of editors. [remainder snipped, apparently describing some piece of software that presents you automatically with an emacs tutorial if you start emacs while it's running. I've seen emacs a few times in my day but never whatever unnamed piece of software is being referred to here...but it does occur to me that a context-sensitive auto-popup cheat sheet tool would be useful on the typical unix system!] -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 21, 10:52 am, Bjorn Borud <[EMAIL PROTECTED]> wrote: > [Twisted <[EMAIL PROTECTED]>] > | > | Being beginner-friendly doesn't have to be at the expense of power or > | expert-user usability. > > depends on your definition of "expert". :-) Well, admittedly, if your definition of "expert" is "elitist pig who considers beginner-hostileness itself to be a required feature in order for him to regard the software as usable", then you may be right. That sort of negative-sum thinking is alien to me. Software being easy for beginners to get started using does not in and of itself detract from its value to expert users. Only if they "value" such perverse things as "being one of the exclusive club that can actually manage to use this thing" does any of this make sense. That's a form of artificial scarcity, and as I think I've mentioned before, artificial scarcity is one of the more major roots of evil. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
On Jun 21, 11:11 am, Lew <[EMAIL PROTECTED]> wrote: > Joel J. Adamson wrote: > > My point is that I'm the sort of person that has a mind set up for > > Emacs. I had none of the difficulties that someone else might have, > > who's used to other kinds of software. > > > However, I'll also point out that my wife has used Emacs a couple > > times, and she's never done more than point and click with a computer, > > and she's had no frustration whatsoever. > > A new user of two hours' experience. A father of a six-year old whose child > hums along happily with emacs. A computer widow who "had no frustration > whatsoever" with it. > > To the claim that "emacs is too hard for the beginner" we have a mounting pile > of steaming evidence that refutes. It's a steaming pile of something, of that I am sure, but I don't think "evidence" is the word I'd use to describe it. The word I'm thinking of IS eight letters long, but it starts with "b" instead of "e"... I find these anecdotes liberally sprinkled into this thread frankly unbelievable. Either they are not using the same software I understand "emacs" to refer to, or someone somewhere is simply lying. Or maybe there's a bunch of prodigies around and they all picked now to pipe up? We can't design software or any other tool to cater exclusively to a handful of Mozarts, though, unless there's no reason to believe anyone outside that small and exclusive club will ever have a use for it. > To the claim that the help is too hard to use comes the evidence that three > simple keystroke patterns are all one needs to know, and anecdotal evidence of > the help system's utility. Utility is nothing without usability. In particular, no matter how much useful content the help might have, the fact that when the document window has the focus the help is always open to the section on switching windows rather puts a crimp in the actual usability of that information. The only times you can use it and the only times you can read it are non-overlapping sets. > Some will refuse to face the truth. To the open-minded, let the facts speak > for themselves. A few anecdotes prove nothing. A first year statistics 101 dropout knows that much. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
On Jun 22, 11:52 am, Bjorn Borud <[EMAIL PROTECTED]> wrote: > [Martin Gregorie <[EMAIL PROTECTED]>] > | > | Yep, and the same people think a command line is to be avoided at all > | costs. "I mean, its so /last century/ and you can't do anything useful > | with it anyway". I think a command line can be useful as a way to directly talk to something's brain. More GUI apps should have a command processor you can access to do something arcane once in a while. The other thing a command processor is good for is providing automation support. Windows is definitely weak on allowing things like editors to be embedded and used as components by other applications. OLE makes it theoretically possible to e.g. use Winword in an IDE but who'd want to? It also doesn't provide a system-wide way to select particular components to do particular jobs -- the closest thing would be splitting comctl32.dll into separate dlls for each common task or dialog and allowing third-party drop-in replacements to be found in a user-specific directory that override the defaults. That sort of modularity and choice is alien to MS thought patterns however. Combining the flexibility of componentry in Unix with the graphical power of Windows might lead to something awesome ... which makes KDE and Gnome things to keep eyes on in the future. > I have observed similar opinions in other non-computer-freaks. people > who see the computer only as a tool and are only interested in getting > the job done. they have a surprising preference for Linux. But not emacs, I'll bet. I think emacs appeals to people who like dealing with the mechanics of emacs or fiddling with and extending the darn thing. But most people just want to get the job done, and the editor or other tools they use have to get out of the way and simply let them work. If their attention keeps being dragged forcible from THE JOB to THE TOOL and how to make this cantankerous thing do *this*? then there is a problem. If I sit down at a windows text editor (or even kwrite or similar) I can just focus on the job. Faced with emacs or most other text-mode editors (but not MS-DOS Edit, interestingly) the editor keeps intruding on my focus. Oops. Elsewhere, you mentioned 3 second attention spans -- I think you'll find people are much more willing to spend 3 hours of attention on their task than 3 seconds on your favorite tool. When the tool intrudes into the user's attention (either by misbehaving, e.g. crashing, or by confounding the user as to how to do what they want to do next), then a problem is evident. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 23, 10:36 am, Martin Gregorie <[EMAIL PROTECTED]> wrote: > However, there's a case he missed, probably through never using a CAD > system. All the good ones can be driven either by mouse, or by > non-chorded key sequences or any combo the user likes. The essence of > CAD is very accurate pointing but all too many mice move slightly when > clicked. Fortunately a decent CAD system offers the possibility of > purely pointing with the mouse and doing everything else with the other > hand on the keyboard. The result is both fast and extremely accurate. Actually, what I prefer in (2D and 3D) visual design apps is the ability to snap to some kind of grid/existing vertices, and to zoom in close. Then small imprecisions in mouse movement can be rendered unimportant. > An interface design point that nobody has yet mentioned here is that > there are four different types of user that map onto a grid: > > casual dedicated > untrained 1 2 > expert 3 4 > > I first ran across grid this in "Design of Man-Computer Dialogs" by > James Martin and its been very useful in systems interface design. > > The problem with almost all current GUIs is that they are aimed at types > 1 and 3 users - this certainly applies to Windows, OS X and Gnome > desktops with the emphasis on type 1. vi and microEmacs, OTOH, are aimed > at type 3 and 4 users. The problem of course being the complete exclusion of type 1 users. Everyone starts out as type 1, and I don't think type 2 occurs in practise. You'd have to be some kind of religious nut to be "dedicated" while still "untrained", rather than only as a result of experience. Apps that provide no traction for a type 1 user will not see much adoption except in an environment of immersion, mentoring, or desperation. I wonder which of the three explains the majority of emacs users, and of vi users, and whether those prove to be the same one. :) (Actually, there'll be a single or a small number of class-2 users: the original developers, who presumably became dedicated before having much experience *using* the tool. Their experiences are atypical however, and their knowledge of the internals probably means they're type 4 by the time they actually use it to do more than debug it. Unsurprisingly, never experiencing it as a type 1 themselves they tend to be inconsiderate of future type 1 users...this is normal, and requires effort to avoid, in much the way blinkered views of stuff and seeing what you want to see can be normal, and efforts like using double-blind studies may be needed to avoid bias in evaluating, say, a new drug. That such efforts are needed should not be seen as disparaging the programmer or the drug-studier, but as merely reflecting human nature, and as a simple pragmatic requirement if one is to maximize utility.) > Its very difficult indeed to design an interface that suits both > untrained and expert users. One with a bog-standard UI but also a "console" or command prompt, scripting language, and customizable bindings? Funnily enough I can count the software I've seen with that range of capabilities (so able to satisfy type 1, 3, AND 4 users) on one hand. Here's the list, in fact: ROM BASICs and QBasic (on any really ancient microcomputer, and old pre-Windows PCs, respectively; the former came with printed manuals and you could just run prepackaged software from disks very easily; QBasic had mouse and menu support, but an immediate mode command line. You might not count ROM BASICS as as friendly, due to the lack of menus and such, but then at that time in history NOTHING had menus and such! And comprehensive introductory use manuals came with those, and with pre-Windows PCs (DOS also had a decent and easy to navigate help system). Most other BASICs and programming environments more generally lack an integrated environment with an immediate mode prompt. Eclipse actually sort of does, but the evaluate line can't be used really arbitrarily and I've found it touchy, and rarely use it. Hypercard (found commonly on old Macs; had a command prompt you could access to directly communicate to an interpreter). Fractint (fractal graphics making software for old pre-Windows PCs; had a similar prompt, accessed by typing 'g', but also had extensive help and menus readily controlled by stock keyboard commands such as the arrow keys, and later a Windows port with menus and mouse support). Quake and descendants (yes, the games. Easy to just use the menus and play the game. Advanced users could hit ~ to drop down a console and do a few things. Really advanced ones made config files to rebind weapons and make chat macros to fire off a taunting sentence with a single keystroke -- no more embarrassment getting fragged while typing it in longhand in mid-game. Super-advanced ones got at the QuakeC and made bots, flag-capture mode mods, and other enhancements and utilities. And sometimes cheats.) There's probably some more out there, but I've yet
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 23, 2:04 am, Robert Uhl <[EMAIL PROTECTED]> wrote: > Of course, emacs doesn't take years of mastery. It takes 30, 40 > minutes. I gave it twice that, and it failed to grow on me in that amount of time. > > Besides, ANY interface that involves fumbling around in the dark > > trying to find a light switch is clunky. > > That sounds like vi, not emacs. That sounds like any application where you need to read the help, but "f1" does not bring up a separate help window, switchable with the main one using alt-tab or the mouse, and navigable using arrows, pageup, pagedn, and the mouse. The result of that is invariably that when the document has the focus, the help is open to "help on switching windows" rather than whatever you need it to be on once the document has the focus. You can read the help on doing what you want to do with the document, but to apply it you need to transfer focus back to the document. If doing that isn't second-nature, you have to navigate the help away from where you need it to get the focus back to the document. Now the focus is on the document, but the help you need isn't displayed next to it anymore. Frustrating? You can't begin to imagine, I suspect. Apparently, some people are born somehow able to avoid this problem without having to memorize one or the other piece of help. You're clearly one of those. I am equally clearly NOT one of those. Of course, if emacs let you keep THREE windows open and visible at the same time, instead of being limited to one or a horizontally split two ... and a cramped 80x10 or so each, at that ... > > 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. > > a) emacs doesn't 'eschew normal methods of navigation'; it's been doing >its own thing since before there _were_ Mac OS or Windows I'll admit that it didn't USED TO 'eschew normal methods of navigation', but at a certain point in time there began to be 'normal methods of navigation' and emacs naturally began eschewing them promptly and has done so ever since. > b) I believe you've never used the emacs tutorial, which is quite >definitely designed for you _not_ to have to fumble around between >windows If I haven't, it must be the case that finding this tutorial (or even discovering that it exists) was nontrivial, or it wasn't built into emacs, one or the other. My memory is somewhat fuzzy after all these years so you'll forgive me if I don't make a definite statement about which. On the flip side, if I have, the tutorial can't have been all it's cracked up to be. Especially given I can program Java proficiently, including some fairly sophisticated network-using tools, and clearly am not an idiot or untalented in technically demanding areas involving substantial amounts of arcana. Of course, I might have put more effort into learning effective Java; effort like that in learning some language is necessary to being a programmer. Thanks to modern editors and IDEs, putting a comparable amount into learning the mere mechanics of operating a text editor is not necessary, and I chose to spend the time and effort elsewhere, where it was necessary, such as on learning a programming language. The technical term for managing limited resources, such as time and effort, first where needed and never where avoidable, is "efficiency", in case you were unaware. > > 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. > > That doesn't even make sense. Either your memory is faulty Impossible > you've never actually used emacs Untrue > or you're just making things up. Also untrue, and you've just accused me of incompetence once and of lying twice, which in a formerly civil discussion constitutes behavior that I consider to be in poor taste. > If I'm browsing the manual > online, I can switch from said manual to my document buffer without > making the manual scroll to the documentation for switch-to-buffer. Apparently because you find the switch second nature, despite its not being the obvious (which is ctrl-tab, to switch between documents in an MDI app). Cheat sheet? Memorized with painstaking months of hard effort? Thanks for proving my point, either way. > In fact, I am not aware of any package which auto-changes the *info* or > *Help* buffers to reflect the last keyboard command. I didn't say it auto-changes. It manual-changes. The exact sequence of events that causes this with a novice user being: * Need to do X, and the usual command doesn't work (e.g. go to save document and get search prompt) * Now nothing much works (typ
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 23, 8:35 pm, Robert Uhl <[EMAIL PROTECTED]> wrote: > Twisted <[EMAIL PROTECTED]> writes: > > > For an example of the latter, consider opening a file. Can't remember > > the exact spelling and capitalization of the file name? Sorry, bud, > > you're SOL. Go find it in some other app and memorize the name, then > > return to emacs. > > Once again I am forced to wonder if you have _ever_ actually used > emacs. find-file has tab completion: hit tab without anything typed, and > it displays _everything_ in the directory; type a few characters to > narrow it down; hit tab to complete the filename and be done with it. > > Or of course you could use directory mode, which enables you to navigate > around a directory tree, performing actions on files (including editing > them). > > Then of course there's ido.el, which is even better: type a few > characters from anywhere in the name, and it displays files matching > those characters. Really? None of this happens if you just do the straightforward file- open command, which should obviously at least provide a navigable directory tree, but definitely does not. One sounds like it involves managing a separate open window on each directory you're interested in (versus having a file...open dialog that falls open to the last place you'd left it and doesn't clutter up any space when you're not opening a file); the other sounds like it involves actually installing a plugin of some kind, which is obviously well beyond what a beginner should need to do just to get a freaking directory listing. :) Tab completion is a poor cousin to a real directory tree navigator, as I'm sure most would agree. Even if it will show all matches to a partial name instead of none, it's the textual equivalent of navigating a directory tree made into menus instead of provided by a proper folder view window. Windows users unfortunately have the experience regularly: the notorious Start menu. You have to expand submenus to find stuff, and you can't leave it idling to do something somewhere else and come back to it because it's a menu. Moreover, clicking an item may display a large number of items the next level down, which runs into screen display space issues. Even a large video mode can't hide the fact that menus weren't really designed to list hundreds of sibling items or for scrolling or finding stuff in a large set of files, unlike folder windows. I can only imagine the pain of trying to navigate an equivalent way in an 80x25 box of text information. That would be like navigating the Windows start menu from outside your house by peeking through a keyhole and reaching through a window with a repurposed straightened out coathanger. Clumsy AND the neighbors'll see you and call the cops well before you find the item you're looking for. :) (Navigating the Windows start menu in safe mode, at 640x480, is about as close as most Windows users are ever likely to come to the nightmare of opening a file in emacs when you don't already know its exact path.) -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 23, 11:56 am, Bjorn Borud <[EMAIL PROTECTED]> wrote: > [Twisted <[EMAIL PROTECTED]>] > | > | That sort of negative-sum thinking is alien to me. Software being easy > | for beginners to get started using does not in and of itself detract > | from its value to expert users. > > the fact that you imply that this is my argument tells me that either > you have not paid attention, or you have a raging inferiority complex. > given the sum of your postings so far I'd say that you neither are, > nor consider yourself, a cerebral sort of person, so this narrows it > down somewhat (although not to the exclusion of you not having paid > attention). That ... makes no sense. Sorry. Previously, I said: > Being beginner-friendly doesn't have to be at the expense of power or > expert-user usability and you said that depended on the definition of "expert". Apparently you believe there is a type of "expert" for whom beginner-friendly software is intrinsically less usable than beginner-hostile software. Given that beginner-friendliness does not preclude any kind of expert level functionality being available (consider something configurable enough that an advanced user can start it up and open an advanced-uses window and immediately do advanced stuff, and a real expert can make it start up with that window already open and focused by default), it follows that these experts' perceptions of decreased usability are a psychological result of simply knowing beginners can easily become proficient in using basic functions of the software in question, rather than a material result of some compromise necessarily made in the software's design, as there is no such compromise that can't in practise be avoided. An expert who feels software is less suitable for his use *purely* because the unwashed masses can actually use it to accomplish something is quite obviously some type of elitist jerk. I rest my case. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 24, 8:10 am, Martin Gregorie <[EMAIL PROTECTED]> wrote: > > Actually, what I prefer in (2D and 3D) visual design apps is the > > ability to snap to some kind of grid/existing vertices, and to zoom in > > close. Then small imprecisions in mouse movement can be rendered > > unimportant. > > That might work for visual design apps, but it doesn't for CAD, where > you may want to point to an arbitrary position with a (scaled) accuracy > of microns. I didn't mention that you should be able to zoom and make the grid fine to whatever limit is reasonable given the application? The issue being, how accurate is "accurate enough"? Pinpoint precision isn't possible, unless it's an integer or a functionally derived value like pi or some arithmetic result of that. Grids are good for getting rational numbers exactly, and nothing will hit the irrational ones exactly, save if you can enter a formula for it to use to compute the point's location to any desired precision. A mouse click (sans grid) will always introduce some error; the zoom level lets you limit the magnitude of the error. So does a grid, and to zero if the desired point is a grid vertex, and to half the grid size more generally. > The fact remains that mechanical mice do jump when you click them, > though optical mice are better in this respect. Ultimately, the button has to be non-mechanical for this sort of thing to really work. Or else not physically part of the mouse. Being able to "click" from the keyboard makes sense given such requirements. So does being able to snap to a grid. > > The problem of course being the complete exclusion of type 1 users. > > Totally untrue. I'm not talking about in general. I'm talking about the specific sorts of unixy applications that are under discussion here. Those emphatically cater solely to type-3s and type-4s, aside from newer graphical apps for KDE and Gnome, which are emerging as a third group of type-1-accessible tool alongside Mac applications and Windows applications. > Thats not true and never can be: a computer is > the most complex device the average person will own or use and is likely > to retain that title for the foreseeable future. What about the fabrication devices? Oh, but I suppose the "foreseeable future" has already ended by the time those trickle down to widespread consumer use. > I grant you that type 2 users are rare, but I think flight simulators > may fit this case when used for training. Anything you have to use to meet some important external goal, I suppose. But most usually there are options. A programmer needs a text editor but it need not be emacs. Jobs requiring the use of specific software (for training, or just on the job) maybe, of which your example is a subset. > Not really. What's needed is a single interface that can be used by > anybody from beginner to expert and that, in the case of an error, shows > precisely where it got, what caused the action to fail to complete and > that allows the user to continue from that point without having to > undo/redo the bits that were successful. Its not easy, but it can be done. Why do those who have the skills, talent, knowledge, and thus capability to do this insist on making cruft like emacs then? I've never seen a classic-unix tool that didn't barf unhelpful and uninformative error messages at the drop of a hat (just like Windows!) and present a piss-poor UI, or even no UI at all (unless "usage: blah blah blah" qualifies as a UI, to which my response is one word. "Non- interactive.") When the error messages are informative, they're still cryptic, and only someone with knowledge of the software's internals has a hope in hell of fixing the problem as a rule. Of course, the number one rule of interface design is to speak the user's language and the language of the problem domain, and remain mute (except to developers invoking debug modes) about the implementation details and the language of the solution domain. Especially given that a different version of the same software, nevermind a different app with the same usage, is probably going to use a different implementation anyway. One exception can be to expose a specific scripting language for advanced users to use to automate tasks. Emacs does this, and it's one thing I don't have a problem with. As long as knowledge of its arcana is not needed to either do straightforward stuff, or fix the errors that occur attempting to do straightforward stuff, anyway. If the beginner can safely ignore the thing's existence (e.g. the VB-based scripting language in some office and paint programs) it's fine. > > ROM BASICs and QBasic (on any really ancient microcomputer, and old > > pre-Windows PCs, respectively; the former came with printed manuals > > and you could just run prepackaged software from disks very easily; > > Hang on: you don't read manuals. You object to using tutorials and to > buying books, so its a bit precious to claim this example. The manuals came with the computer
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 24, 6:52 pm, Robert Uhl <[EMAIL PROTECTED]> wrote:
> > Really? None of [navigating a folder window analogue] happens if
> > you just do the straightforward file-open command, which should
> > obviously at least provide a navigable directory tree, but
> > definitely does not.
>
> The first does. Really, it does. Fire up emacs (which you've never
> done before) and type C-x C-f.
Whoa, Nellie. I seem to recall we were discussing the file-open
command.
That was something else, like C-x C-o or something. More apples-and-
oranges?
> You will be presented with a prompt
> something like 'Find file: ~/'; hit tab once; you'll see the message
> '[Complete, but not unique]'; hit tab again and you will be presented a
> list of all files in that directory.
Sounds clunky anyway. I don't need a bunch of keypresses to do the
equivalent in an Explorer-based file-open dialog in a native Windows
app. Just a double-click.
Emacs, with your C-x C-f:
C-x C-f tab tab ("Startofnameofdirectory somethingElse
otherstuff")
Startofname tab tab ("Subdirectory anotherSubdirectory")
Subd tab tab
Windows:
Alt, f, o ("Startofnameofdirectory somethingElse
otherstuff")
Click-click
or Startofname-down-enter ("Subdirectory anotherSubdirectory")
Click-click
or Subd-down-enter
Worst case (all keyboard): one fewer keypress. Best case (judicious
use of the mouse and smart hand placement, one by left alt and one on
the mouse): five TOTAL gestures.
In particular, C-x C-f tab tab is replaced by alt f o (four down to
three keypresses) or click file, click open (two instead of three
inputs, but you have to locate the File menu from halfway across the
screen with the pointer, so count it as three as well).
Being able to pick an item from a list just by touching the damn thing
instead of typing in a sufficiently long prefix is definitely an
advantage, and if a lot of things share the same 16-character prefix
in a particular directory, the emacs way starts to look SLOW.
Of course, there's an even faster Windows way, if you don't mind not
seeing lists of possible items:
Alt, f, o
Startofname-down-/-Subd-down-/
Straight to the subdirectory without waiting for it to display the
parent directory or the root. Same number of inputs. And of course
there's the super-fast
Alt, f, o, C-v, enter
if you happen to have the exact path in the clipboard already. I'd
like to see emacs do that, at least if the text to paste originated
outside emacs. (If I'm doing this in Winword's file open dialog it
could have originated in Notepad, Firefox, or just about anywhere
else, not just Winword.)
> If you like 'em, though, just select File:Visit New File. It gives you
> a platform-default (gtk+, for me) file selector.
Now we're talking about a graphical port instead of stock emacs
again. :P
> Nope, because of the way emacs works you can stop what you're doing, do
> something else and come back to the minibuffer.
After spending a while brushing up on my Tibetan, I may or may not
agree, but until I've got some real meaning out of your use of jargon
like "minibuffer", I'll have to pass on this one. Nonetheless, stuff
you can do but can't know you can do without learning Tibetan is
unlikely to be of much help to the average user. :)
> Fortunately, folks brighter than you & I have imagined a nice way for
> us. It pops up a new Emacs window (pane, if you prefer the terminology)
> showing a list of all filenames. You could continue typing, or just
> click on a filename in the window, or hit return while the cursor is on
> a filename in that window.
Back to discussing a graphical port again. Besides the apples and
oranges issue, this amounts to implementing a dodgy imitation of a
file open dialog anyway. Why bother with such an imitation when you
can use a natively-GUI editor written for your platform and get access
to the real thing?
--
http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 24, 7:19 pm, Robert Uhl <[EMAIL PROTECTED]> wrote: > Twisted <[EMAIL PROTECTED]> writes: > > > Of course, if emacs let you keep THREE windows open and visible at the > > same time, instead of being limited to one or a horizontally split two > > ... and a cramped 80x10 or so each, at that ... > > I have two frames open right now: one 80x70, the other around 180x70 > (characters, not pixels). One isn't split at all; the other is split > into four windows, horizontally and vertically. Then you're obviously not using the One True Emacs I am criticizing, which is a console app. If we're not talking about the same piece of software (and the one the fanatics evangelize about) then this is pointless. > emacs has continued doing its own thing, mostly because that thing is > better. The CUA standards (there exists an emacs package if you really > want them) are broken and lame--I and most other don't wish to cripple > our text editor of choice. "CUA standards"? I'm sorry, I don't speak Botswanan. If you mean Windows standards like for cut, copy, and paste, "broken and lame" is obviously in the eye in the beholder, and something 97% of computer users are used to is the defacto standard, so it's the other 3% that are "broken and lame". ;) > When you start emacs in a text console, you see this: > > Welcome to GNU Emacs, one component of the GNU/Linux operating system. > > Type C-l to begin editing. > > Get help C-h (Hold down CTRL and press h) > Emacs manual C-h r > Emacs tutorial C-h t Undo changes C-x u Really? That is not what I recall seeing. Are you talking about emacs- the-text-mode-editor, or emacs-the-hybrid-somethingorother-when-you- happen-to-run-it-from-the-command-prompt-on-unix? Because I've been discussing the former. > Buy manualsC-h C-m How crass. First I've seen anything open source/"free" software that makes sales pitches at you. Mostly I've only seen that with closed-source Windows "free"ware loaded with adware, and with shareware that nags you to register or otherwise spend money with its author. And with actual paid products, particularly those from Intuit which act as Intuit's front-line salesmen by trying to constantly upsell you and sell stuff to your friends and relatives. Er, thanks but no thanks. (I don't personally spend a dime on any Intuit products. I unfortunately know people who do. One version of some accounting software of theirs even spammed all of a user's email contacts, by God. Where are those Russian spammer-targeting hitmen when you need them?) > Activate menubar F10 or ESC ` or M-` Definitely not the stock text-mode emacs I've had my runins with in the past, but some kind of hybrid or offshoot, then. > Clicking within the document's window isn't obvious?!? Clicking within the document's window is obvious but doesn't work, unless you're using something other than vanilla emacs at least. It did of course work in MS-DOS Edit, later versions. > No, we're discussing emacs, a text editor which runs in both a GUI and a > text console. Which can display images. It's cool like that. No, we're discussing ... oh, nevermind. It looks like there are several utterly different pieces of software that have one thing in common - the name "emacs". Anyone can dodge or seem to rebut a criticism of one of them by describing how another of them isn't like that. :P > > At least Windows 3.1 had most apps have the same keys for the vast > > majority of commands, and those were the right keys. Emacs has all the > > applications have the vast majority of their commands use the same > > WRONG keys. > > Neither is right nor wrong; you're just used to one. The emacs keys are > certainly more flexible and powerful, though. Some might consider them > right for that reason. The Windows keys are familiar to 97% of the population. Some might consider them right for that reason. This is also a change from your earlier position that they were, and I quote, "broken and lame", assuming you mean the same stock Windoze keybindings you meant with the cryptic term "CUA standards". > > Search is usually ctrl+f, type something, hit enter in my experience. > > Unless you want regexp search. And if you want to find again it can be > interesting. I rarely want regexp search, and if I want it I can use Notetab, a notepad replacement with tabbed MDI and yes, regexp search. A few tabs and a space keypress to turn it on after ctrl+f. As for "find again" hitting enter additional times is the usual method, in Notetab, Notepad, and elsewhere. > > And I can use any text ed
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 25, 8:40 am, Martin Gregorie <[EMAIL PROTECTED]> wrote: > Twisted wrote: > > The manuals came with the computers, at no additional charge. It was a > > different time. This isn't going to be true of any separately- > > purchased book or user-made printout concerning emacs. Also, the > > manuals provided a basic introduction for the beginning user. A > > traditional-unix-tool providing anything resembling that would > > genuinely shock me. > > Oh, so manuals are OK and you'll read them if they are dead trees that > came in the same box as the software, but not if they're HOWTOs, online > documentation or O'Reilly books? I think I need to clarify. What I expect is that I can have the application and the documentation open side by side, a) without needing to use the application's own navigation methods to navigate to/ from or within the documentation given that that can create a catch-22, and b) without paying extra. If a printed manual comes with the thing, without paying extra, then it clearly qualifies as such documentation. If I have to print it myself it doesn't, because ink doesn't grow on trees. Paper does, but they still manage to charge money for that too. If I have to purchase the manual separately it likewise doesn't. So the options are: printed manual that ships with the software at no extra charge, or online documentation I can read "the normal way". Emacs in control of the console has neither. (Emacs relegated to a single terminal window on a graphical workstation may not have such a big problem.) Regardless, having to reach for the help every two minutes doesn't enamor me of an application unless there's a darn good reason for it, such as it's actually rocket science. 3D modeling I expect to be tricky at times. Text editing should be just-sit-down-crack-knuckles- and-do-it obviously. > > Oh, because the implementation (of "reveal codes" and of everything > > else) was awful, not because of any intrinsic flaw in the idea itself. > > If a word processor, which by definition is provides a WYSIWYG user > interface, can't produce perfectly formatted text by editing a > representation of the finished result then its a deeply flawed program > and not fit for purpose. First, I didn't claim the ideal WP was necessarily perfectly WYSIWYG. On the other hand, even so it might be that hand-hacking the underlying representation might in some cases be a faster way to achieve a particular goal than doing it "the WYSIWYG way". You'd still have a WYSIWYG preview available either way of course. > > Would you want to edit a Web page without being able to hand-hack the > > HTML? > > Of course not, but HTML isn't anything to do with WYSIWYG and any system > (Coldfusion, Front Page, HTML from Word) that pretends it is WYSIWG is > both useless and perpetrating a fraud. Your quiet change from discussing word processing to discussing WYSIWYG is interesting. Is that how you generally go about fighting your verbal battles, by quietly shifting the specific thing under debate to whatever would have made your opponent blatantly wrong IF they had been talking about that thing instead of what they really were? > > What happened to the guys that did all this stuff after it became > > obsolete? > > It isn't obsolete despite going back a looong way. The hardware and > software was originally developed as Future Series (intended S/360 > replacement), was canned in 1970 but resurfaced in the late 80s as > System/38. A second generation appeared as AS/400, was renamed to (I > think) Z-series and are now known as iSeries servers. Its good, reliable > kit and easy to work with if you don't mind programming in RPG. Programming in role-playing game? And I meant my roguelike-filesystem- interface suggestion at least partly in jest... Anyway, obsolete or merely obscure, it obviously failed to hit the big time since us ordinary joes are still mostly using various forms of Windoze and wishing for something more reliable and secure that didn't also have gratuitous user interface weirdnesses. > I know of no better "one size fits all" interface design than that > provided by the OS/400 operating system. Its still called that. Its a > pity the interface style hasn't been emulated by others. If it's so great, why hasn't it, and why hasn't OS/400 managed to escape from persistent obscurity? > It was standard with Win 3.1 and 3.11 and it was bloody useless. Most > people I know tried it once or twice before giving up and writing .BAT > files or putting up with RSI. The problem was that it recorded > keystrokes and mouse clicks. Even minor changes to the screen layout > made it fail and the macros couldn&
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 25, 5:20 pm, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]>, > > Twisted <[EMAIL PROTECTED]> wrote: > > On Jun 23, 10:36 am, Martin Gregorie <[EMAIL PROTECTED]> > > wrote: > > [ snip ] > > > * The operating system where you can do powerful stuff with a command > > line and a script or two, but can also get by without either. (Windows > > fails the former. Linux fails the latter.) > > About the latter -- it's hard for me to be sure, since for many > things something with a GUI is not my first choice of tool, but > my impression is that on "user-friendly" Linux distributions, > pretty much everything, including sysadmin stuff, can be done by > pointing and clicking, starting with the menus displayed on the > default desktop. With the latest stuff like Ubuntu, you're pretty much right ... until something goes wrong. Windows has safe mode and System Restore and, if push comes to shove, a recovery disk or partition. Linux has ... the command line, or worse a GRUB or fsck prompt at startup. No access to accessible, easy to browse help right when you need it most. Blow away the partition with everything on it and reinstall? y/n _ Sometimes it's not that bad. Sometimes it's just some X thing needing tweaking, or a particular thing elsewhere that's broken, but it requires at minimum hand-hacking a .rc file and running some stuff in a terminal window (aka command line, but with maybe more easily available and navigable help, since at minimum you can open two side by side and leave one open to the output of man or less). -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 25, 5:32 pm, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > To me it's similar to "memorizing" a phone number by dialing > it enough times that it makes its way into memory without > conscious effort. I suspect that not everyone's brain works > this way, and some people have to look it up every time. > For those people, I can understand why something without a > GUI could be a painful experience. "YMMV", maybe. You'll be happy to know then that my opinion is that the phone system is archaic too. Exposing the numerical network addresses like that is so 1970s; where's the phone version of DNS, given that the technology to develop it is clearly there now, and (from my experiences with the phone menus at some 800 numbers) even the technology for you to just pick up the handset, say someone's name, and have it look them up and ring them, possibly after being prompted to accept long distance charges, reverse them, or cancel if it's LD. :) We'll actually probably see a generation of friendlier phones RSN -- either regular phones, or because VoIP providers leapfrog them and advance rapidly leaving the old telcos eating dust when these don't advance their technology and interfaces. Setting up and using voice mail or speed-dial keys still tends to be *painful*. There's still an excuse for that with cell phones since you can't put a more sophisticated interface onto something the size of a credit card, but a phone that takes up a substantial chunk of desk space really should have more than a tiny LCD screen and twelve tone keys. The only reason nobody complains much is because they're so bog standard everyone is used to them and knows how to operate them. If we had modern internet and other services and someone tried to introduce the touch-tone telephone system now, the market would reject it in a heartbeat and pursue VoIP, and Techdirt would run a "Failures" category article blaming the terrible UI and excessive fee structure. The same sort of inertia that let the phone system survive mostly unchanged over the last 20 years without improving its UI much keeps some old unix tools beloved by those who mastered them, and of course propels Windows, which has done some dumb things with its UI (and much worse under the hood). -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 26, 2:01 am, Adriano Varoli Piazza <[EMAIL PROTECTED]> wrote: > Twisted wrote: > > With the latest stuff like Ubuntu, you're pretty much right ... until > > something goes wrong. Windows has . > [...] > > Linux has ... the > > command line, or worse a GRUB or fsck prompt at startup. No access to > > accessible, easy to browse help right when you need it most. > > I suppose you never used Ubuntu's disc for anything but installing or > reformatting either, but that doesn't mean it's the only thing that > can be done with it. You can boot with it, have a working net > connection (or create it) and solve many problems in the comfort of > the full GUI, and with all the help available from the web. Ah, if you have a live CD this might indeed be possible. If you can get it to mount your usual hdd partitions to go sniffing around the configuration files that might be gummed up, and if doing this isn't insanely complicated anyway. A Windows restore CD or recovery partition doesn't do anything of the sort, although a genuine install CD has a repair function, which can among other things fix problems with the MBR and reinstall key Windoze components on the hdd. If you can boot to safe mode you can fix most things with System Restore, which simply lets you roll back the configuration to before that ill-advised install, uninstall, driver update, or whatever it was that hosed things. I've had to resort to it exactly twice; once when firewall software b0rked the system on install and put it in infinite-reboot mode (safe mode halted the loop) and once when nVidia released some driver update that hosed the 3D accelerator and screwed up the available graphics modes. System Restore works by quietly backing up key files (DLLs, config files, and suchlike) and registry trees when an installer is run and under some other circumstances, including a manual instruction to create a save point, which you can use before you try anything dodgy so you can roll back to right before the attempt if it goes wrong. Ordinary document files and the like aren't backed up or anything by this, however. If they get hosed, they get hosed, although System Restore won't damage them any more than it will back them up. I've managed to fix driver and networking problems a few times, and sometimes on someone else's computer, with and without system restore. Most of the times if I've seen any flavor of unix misbehaving, it's been find a bigger geek or resort to beads and rattles; it's been far from obvious what the problem was from the error messages, let alone what the fix was, and often the problem precluded access to any useful tools or documentation simultaneously. A live CD might make that less of an issue, though it would still be a pain if you had to keep using it as a workaround for days while waiting for a mailing list or usenet response explaining what the f*#! "bad zixflob in fuzzwangle.rc, aborting" meant and how to fix it, especially as a system-wide search didn't turn up any files named "fuzzwangle.rc" -- or whatever the problem was. :) [Insulting insinuation snipped] Oh, sod off. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 25, 2:32 pm, Giorgos Keramidas <[EMAIL PROTECTED]> wrote: > > So much for the "free" in "free software". If you can't actually use > > it without paying money, whether for the software or for some book, it > > isn't really free, is it? > > Please do not confuse the term 'free' in 'free software' with 'gratis'. > > 'Gratis', i.e. 'lacking a monetary price tag' is something *very* > different from the meaning of 'free' in 'free software'. Having to pay for the documentation, presumably because it's copyrighted, doesn't strike me as much more "free as in speech" than it is "free as in beer". Also being dependent on a particular publisher for access to required documentation violates "free as in no vendor lock-in", to boot. So anyone saying some "free" software is unusable without such-and-such an O'Reilly book can go peddle the software and the book somewhere where spammers are welcome. Being locked in to O'Reilly being just as bad as being locked in to Microsoft or Adobe. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 25, 2:28 pm, Giorgos Keramidas <[EMAIL PROTECTED]> wrote: > > This is the lowly Notepad, which I'll freely admit is the rusty > > bicycle of text editors, and it's much easier to use (including the > > help) than the supposed Mercedes-Benz of editors. > > Isn't this always the case? The 'interface' of a tiny bicycle is > something which even very young kids can master pretty fast. On the > other hand, I'm relatively sure there's at least one valid reason we > don't let pre-school aged children drive around Mercedes-Benz cars, > isn't there? And the myth of the bicycle being easy to learn persists. Did you know that kids learn better than adults do? Why do kids pick up at least one language without any conscious effort, while adults trying to learn one more often struggle in night school? I know people who find all kinds of vehicles easy to learn but never mastered a bicycle (despite trying). People, plural, as in more than one of them. Anyway, I know which comes with a fatter manual -- the Benz... -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 26, 10:52 am, Bjorn Borud <[EMAIL PROTECTED]> wrote: > [Robert Uhl <[EMAIL PROTECTED]>] > | > | Agreed. Stallman got sidetracked by Scheme, which IMHO was a > | dead-end. > > too many people buying SICP and believing what they heard about it > being an important book. I too spent some time exploring Scheme, or > should I say, wasted some time, years ago, and nothing came of it > other than a profound irritation. these people seemed to be > completely disconnected from reality. > > Scheme, and thus Guile, might have been a viable path if these people > had only been practical instead of stubbornly insisting on being odd. Some people might say the same thing about emacs. A lot of unix tools even. "Stubbornly insisting on being odd" appears to be a particularly prevalent character flaw among the geeknoscenti. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 26, 10:37 am, Bjorn Borud <[EMAIL PROTECTED]> wrote: > ...and of course, in addition you have access to history so you can > easily find previous parameters and edit them. this makes it very > efficient when you need to fiddle about in deep directory trees in a > way no GUI can yet offer. > > ...and then there's bookmarking, which is very good for keeping a set > of files (and locations) handy for quick access. Good thing it has these. Bookmarking is quite natural and is THE way in GUIs to cope with deep directory structures. Bookmarking in a GUI is simple: you just open file-browser windows and park them in oft- visited places, to flip to whenever needed. Multitasking window systems are neat that way. Current versions of Windoze Explorer have a history and back and forward navigation buttons reminiscent of a Web browser, too. None of them turn into as big a PITA when lots of files have a lengthy, identical prefix either, which is a fairly common situation. That only causes difficulty at all when some column or window is sized too narrowly to show parts of the name past the prefix, forcing scrolling. Resizing it is then easy, thanks to the GUI, so unless the prefix is wide enough to cross the entire screen even if you set the font size down to 3... contrast that with tab completion, where to disambiguate you'll have to type the entire prefix and then part of the rest, THEN hit tab. If the prefix is long, you might be saving 3 keystrokes reducing 47 to 44, a gain in productivity of about 7%, a figure I'm sure you'll agree is somewhat underwhelming. Of course with a GUI it's spot-the-right-file-and-click, and just as fast whether the prefix is 4 characters long or 40. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 26, 6:06 am, Gian Uberto Lauri <[EMAIL PROTECTED]>
wrote:
> >> > HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO
> >> ENTER > THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT
> >> WOULD TELL > THEM THOSE ARE THE KEYS TO REACH THE HELP?!
>
> >> What's your problem ?
>
> >> Ofcourse a mere program-consumer would not look what was being
> >> installed on his/her system in the first place ... So after some
> >> trivial perusing what was installed and where : WOW Look, MA !
> >> it's all there!
>
> >> lpr /usr/local/share/emacs/21.3/etc/refcard.ps or your
> >> install-dir^ ^ or your
> >> version.^
>
> n> So now we're expected to go on a filesystem fishing expedition
> n> instead of just hit F1? One small step (backwards) for a man; one
> n> giant leap (backwards) for mankind. :P
[snipping some thinly-veiled insults and irrelevancies throughout]
> There's a program called find, not this intuitive but worth learning
>
> It could solve the problem from the root with something like
>
> find / -name refcard.ps -exec lpr {} \; 2> /dev/null
Let me get this straight.
In this corner, we have just about every Windows application ever
developed. When a user needs help, a click on the "help" menu or tap
of the F1 key is all it takes to obtain some. Sometimes the help is
not of the greatest quality, but that is another issue we won't
concern ourselves with here.
In the other corner, we have just about every Unix application ever
developed. When a user needs help, they may do such things as manually
explore the directories where the application was installed
(equivalent to rooting around in C:\Program Files\Appname for .hlp
files, because F1 didn't work and there was no "help" menu, if such a
thing ever happened on Windoze). Or alternatively it can just
magically come to them as a divinely inspired insight, or in a dream
or a burning bush or stone tablets from heaven or something, that
something useful might happen if the unlikely combination of symbols
"find / -name refcard.ps -exec lpr {} \; 2> /dev/null" were typed at
the console, which otherwise would obviously never occur to them. Even
if they knew the find tool and its syntax, it would still have to
somehow occur to them that "refcard.ps" might be a useful search
target. On Windows, if push came to shove, clicking Start->Search and
putting in ".hlp" and "C:\Program Files\Appname" would quickly find
any help files. If they were given the usual file extension. If not,
good luck, but most usually the help files would be named to end
with .hlp. Moreover, once found, a quick double click and they're in a
hypertext browser viewing the help. Unless I miss my guess, refcard.ps
would require mucking about installing and configuring Ghostscript and
GSView, which for Joe Winblows User is daunting enough. Trying to read
anything serious and navigate in GSView is no picnic either. A
hypertext browser it ain't. Adobe Acrobat Reader *might* be able to do
more with a .ps file, but it's proprietary. On a Unix box, if you
don't know exactly how to get some app viewing a .ps file and how to
navigate in it I'm guessing you're SOL. The original suggestion with
"lpr" implies printing it rather than viewing it online, which a)
costs money and b) requires configuring a printer and a Postscript
interpreter, given that unless the printer cost more than the
computer's CPU it surely won't natively grok Postscript. We're back to
configuring Ghostscript, only this time on the Unix box where I have
no doubt it's even more painful than it is on a Windoze box, as well
as configuring a printer on a Unix box, itself a recurring nightmare
of mine for years now since one night in the nineties when I got
caught in the crossfire between someone's Epson inkjet and their
Mandrake 7.somethingorother Linux.
Reexamining that "find" line it looks like it tries to automatically
"lpr" the file(s) found. That is cause for concern, since I can easily
see something like this going into Sorceror's Apprentice mode and
costing you a fortune in ink and paper if there's either a misspelling
or other mistake (easy enough to make in a complex arcane command line
like that one) or more "refcard.ps" matches than you expected there'd
be in the target directory and its descendants.
--
http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 26, 6:17 am, Gian Uberto Lauri <[EMAIL PROTECTED]> wrote: > Children pick up other language without any conscious effort because > either they learn it by using with parents, relatives and friends or > they are involved in a game-like style of learning. Actually, it's proven that there's a critical period for language learning "coming naturally" that ends around age seven. Children actually have enhanced learning abilities due to brain physiology and plasticity. > T> I know people who find all kinds of vehicles easy to learn but > T> never mastered a bicycle (despite trying). People, plural, as in > T> more than one of them. > > Again, fear, or maybe, some malfunction in the balancing organs. But > fear mainly. You do not see what keeps a bike upright and running, you > have to trust that you can. Oh, come off it. One of those people is a physics professor, who knows the mechanics of gyroscopic stability and things of that nature backwards and forwards. And his sense of balance is fine -- he has no trouble with that except when he's quite drunk. He told me the problem was the bike tipping over before it could get up enough speed to become stable. My own guess being there's a "knack" you may or may not eventually get, for getting past that initial hurdle and getting it up to speed when it becomes stable. Of course, this "knack" isn't something found in any instruction manual. I'm wondering if getting your head around unix arcana is also dependent on an iffy "knack" where you "get it" and somehow know where to look for documentation and problem fixes, despite everything having its own idiosyncratic way, and "get" some sort of workflow trick going, or you don't. Personally, the thing I always found most irritating was the necessary frequent trips to the help. Even when the help was easy to use (itself rare) that's a load of additional task switching and crap. Of course, lots of the time the help was not easy to use. Man pages and anything else viewed on a console, for example -- generally you could not view it side by side with your work, but instead interrupt the work, view it, try to memorize the one next step, go back to your work, perform that next step, back to the help to memorize another step ... that has all the workflow of a backed-up sewer, yet until and unless the commands become second nature it's what you're typically forced to do without a proper GUI. Navigating also being a pain -- generally it's easy to get it to scroll down, or exit; hard but usually possible to scroll up in case you overshoot; and there's some arcane search capability, but it isn't straightforward to use so you can't use it because you'd need to be open to the help for the help viewer or other tool instead of the help you're trying to search, and then your search would come up empty. The searching-help instructions not being in the same help file as the target of your search proves to be the final straw, and you throw up your hands in disgust after going a few rounds with "thetool", "man thetool", and "man man" and make an inch of progress in an hour, most of it spent on typing, scrolling, or memorizing rather than on working with "thetool". Maybe the thing I really, REALLY deplore is simply having 99% of my attention forced to deal with the mechanics of the job and the mechanics of the help viewer and only 1% with the actual content of the job, instead of the other way around. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 27, 4:18 am, Gian Uberto Lauri <[EMAIL PROTECTED]> wrote: [A very long, rambling, semi-coherent post] > Strange. I am *NOT* a native english speaker and I think my Q.I. tends > toward average from below... That much is obvious. > ...but refcard sound very useful to me, maybe is short for "reference card" ? Yes, but you'd have to be some kind of clairvoyant to realize "I know! I'll do a search for "refcard.ps" on the off chance someone happens to have made a reference card, called it "refcard", and chose the Postscript format to record it in!" out of the blue. > I admit. find is less intuitive. But the stuff Windows comes with does > just that and nothing more. It will never suggest you that the long > boring task expecting you can be solved in a completely automatic > way with a little creative job. And with one little typo, it's hello Sorceror's Apprentice mode... > Emacs help was hypertextual when Dr. Watson plagued Windowd 3.11 > users... Dr. Watson just plagued this WinXP user. Please don't mention Dr. Watson again for a while, for the love of Christ. > Splash, large miss. This is usenet, not Battleship. > You usually fire it to the local printer. Yes, if you have one and care to blow through reams of paper and gallons of ink every month by printing everything you encounter instead of reading it on the expensive LCD monitor you got for such purposes. > T> enough. Trying to read anything serious and navigate in GSView is > T> no picnic either. > > A refcard, my dear, is something that goes on an A4/Letter sheet and > NEEDS NOT to be hypertextual. I was being more general. > With a PS file you can do just one thing, execute it. It's a program, > did you know ? For which you need an interpreter. Such as Ghostscript. Which is a pain to install and a bigger one to configure, even on Windoze. > Uh, I forget. For Windows users getting a PDF out of a PS or HTML or > ASCII is not this easy unless they get some extra software (someone > ported CUPS to Windows ?). Again, not an Emacs fault. I wouldn't know CUPS if it dropped on my head. I think the same can be said of most of the 3 or 4 non-expert unix users in the world. > Stop guessing or all will know that all you know about Unix is that > is a 4 letter word... Yeah. Unix is a four-letter word alright. > All the computer screen is devoted to your work, the sheet provides > some extra "real estate" for the help information, a sort of double > heading display. All you need to do is turn your eyes from the > monitor, maybe your eyes and read the informations. It coudl happen > that you need to flip the sheet. But you can keep both your work and > the help text "ready at your fingertips", and this is useful indeed: > you read the command keybinding, turn your eyes, type it and see the > result and/or continue your work. One small step backwards for a man, one giant leap... > About money. Indeed ink/toner and paper costs. Electricity grows on > the spark tree so aboundant in our forests... This intrigues my younger brother. He wants to know how many moons are in the sky and what color the sun is that your planet orbits. He's at that phase where he's fascinated by astronauts, tales of alien worlds, and things like that, you see... > But PostScript printing on my '80 Epson printwriter or my HP720c with > a Unix system with CUP is as easy as opening a browser, telling the > system I have a HP720c plugged to the parallel port and voilà. I'll bet. Something tells me the catch lies somewhere in "a Unix system with CUP". Unless it's in "browser" instead. Something tells me we're not talking about something that resembles Firefox and makes navigation easy and intuitive here. > In the same time I got an HP720c and it come with no other drivers > than Mac and Windows ones. I feared I was SOL when I readed of some > guy that wrote a small program that was able to convert certain gs > output to byte sequences good to pilot the HP720c. > > It was *easy* to put this program in the pipeline in the "printer > driver" script. > > And was *easy* insert a2ps to shoot plain text directly to the printer. *Easy*. Maybe if you know all about the guts of how the printing subsystem of the OS works. I doubt it's anything like that easy for joe random who just wants to hit "print" and print the document already and not have to spend ages learning about the internals of the operating system first. In Windows, you plug it in and pick it from a dialog (or use a disc that comes with the printer to do setup) and print something. Voila! Out pops a document into the tray; no mess, no fuss. Getting out your wrench and going at the plumbing shouldn't be necessary; any more than I'd want to move into a new home and find I needed to break out the tools and mess with the plumbing before the toilet would flush or the kitchen tap spout water. > Ah, you'll start thinking that those who find find syntax a
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jun 27, 8:26 am, [EMAIL PROTECTED] (Timofei Shatrov) wrote: > >For which you need an interpreter. Such as Ghostscript. Which is a > >pain to install and a bigger one to configure, even on Windoze. > > Lie. Ghostscript works out of the box on Windows. You're joking. First of all I am not a liar, and secondly, Ghostscript and Ghostview are tricky to set up correctly. I know -- I've done it a time or three. There's an arcane GUI configurator that isn't exceptionally well designed, and once it's working it still wonks out on maybe 1 in 10 .ps and .eps files you come across ... which is still better than being able to view none of them, mind you. Nonetheless there's a world of difference between the GS tools and say Adobe Acrobat Reader in terms of setup and use; the latter you just run an installer and then find a pdf to double-click; no other steps necessary and it works every time. Of course, Adobe stuff is proprietary, and acrord supports some types of evil DRM... -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jul 7, 4:26 pm, Edward Dodge <[EMAIL PROTECTED]> wrote: > So -- what magical computer app illuminates the entire room and shows > you how to use everything at the flip of a switch? This brilliant > discovery would put Sam's, O'Reilly, the for-Dummies series, and > virtually every other computer book publisher out of business in weeks. > Naturally, this would include the publishers of books on "easy-to-use" > Microsoft products. I don't know, but it sure as hell isn't emacs. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jul 7, 6:12 pm, Lew <[EMAIL PROTECTED]> wrote: > Twisted wrote: > Edward Dodge wrote: > >> So -- what magical computer app illuminates the entire room and shows > >> you how to use everything at the flip of a switch? This brilliant > >> discovery would put Sam's, O'Reilly, the for-Dummies series, and > >> virtually every other computer book publisher out of business in weeks. > >> Naturally, this would include the publishers of books on "easy-to-use" > >> Microsoft products. > > > I don't know, but it sure as hell isn't emacs. > > The reason you don't know, and Edward Dodge's point, is that there is no such > app, whether emacs or not. Translation: since perfection is unattainable, we shouldn't even try, and just foist upon our poor users whatever awkward and hard-to-learn interface pops into our heads first? -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jul 8, 4:28 am, Adriano Varoli Piazza <[EMAIL PROTECTED]> wrote: > b) If you do want to keep an antediluvian copy of emacs -probably > versioned in the negative numbers, for all you've said- please do. Do > be so kind as to send a copy, since it might be quite valuable as an > antique. Judging by the existence of the newsgroup comp.emacs, emacs is indeed considered by some to be a quite valuable antique. Otherwise why on earth would it have an apparently fairly active newsgroup a full seven years into the 21st century? -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jul 8, 12:18 pm, Bjorn Borud <[EMAIL PROTECTED]> wrote: > uh, I think the point here is that some think it might be an idea to > force *their* idea of the ideal interface upon others, refusing to > understand that people might have their own preferences. I, for one, have a strong preference for interfaces that let me see what the hell I'm doing and make it easy to find commands, navigate the interface, navigate the help, and so forth, while making me resort to reaching for that help as infrequently as reasonably achievable. But that's just me. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
On Jul 12, 7:10 pm, Miles Bader <[EMAIL PROTECTED]> wrote: > Twisted <[EMAIL PROTECTED]> writes: > > I won't dignify your insulting twaddle and random ad-hominem verbiage > > with any more responses after this one. Something with actual logical > > argumentation to rebut may be another matter of course. > > Er, why don't you just answer his question (what version)? He's asking > for actual information, which will help us understand what you are > (trying) to to say. > > If you continue to just make vague and unsupported (and rather hostile) > assertions, without examples, version numbers, or other concrete > information, do you expect anybody will continue listening to you? Some people can't let sleeping dogs lie I guess. I can't remember the specific version after all these years. It may have been 18 or 19 point something. As for "concrete information" this thread is littered with fairly specific anecdotes. I know, I know; anecdotes aren't really proof of anything. Got any better suggestions? HCI stuff is a bit slippery to try to hang a rigorous theory and quantitative facts upon. For most people, a crappy interface isn't something they can precisely define, but they know it when they see it (or at least try to use it). -- http://mail.python.org/mailman/listinfo/python-list
Re: Xah's Edu Corner: Under the spell of Leibniz's dream
On Aug 19, 7:56 pm, Xah Lee <[EMAIL PROTECTED]> wrote: > So, when you "dress up formally" to attend your friend's wedding... Oh dear God, please *don't* remind me. > "Under the spell of Leibniz's dream" (2000) By Edsger W > Dijkstrahttp://www.cs.utexas.edu/~EWD/ewd12xx/EWD1298.PDF A link to a copy in a non-toxic format would be nice. -- http://mail.python.org/mailman/listinfo/python-list
Re: A/C Systems!
On Aug 19, 4:12 pm, Daniel Pitts <[EMAIL PROTECTED]> wrote: > Don't you know that targeted advertising has far better return? Only when each impression is fairly expensive to cause. Unfortunately, spam (whether usenet, guestbook, blog comment, email, or whatever) is very cheap per impression, so the best strategy is indeed to just jizz enormous amounts of it indiscriminately into any socket that will accept the insertion of your network packets. It's the same problem as causes the battle of the sexes; expensive eggs vs. cheap sperm. :P -- http://mail.python.org/mailman/listinfo/python-list
Re: Latest models of Gibson guitars
On Aug 19, 2:41 pm, [EMAIL PROTECTED] wrote: > This is a newsgroup of programming language Python, stop with this! Python?! Python is as off-topic here as guitars, unlike, say, Java... -- http://mail.python.org/mailman/listinfo/python-list
Re: Latest models of Gibson guitars
On Aug 20, 8:05 am, Lew <[EMAIL PROTECTED]> wrote: > Twisted wrote: > > On Aug 19, 2:41 pm, [EMAIL PROTECTED] wrote: > >> This is a newsgroup of programming language Python, stop with this! > > > Python?! Python is as off-topic here as guitars, unlike, say, Java... > > When referring to "this" newsgroup or "here", one must remember that this is a > cross-posted thread You assume it was obvious to me that it was in the first place. But I didn't see it in any other group that I read, and the news interface that I use just, by default, shows me the subject, from, and date and the name of the one newsgroup that I'm reading. If the message then says something absurd, like "this is a newsgroup about Python" when I'm reading it in cljp, well, what do you expect? :P Again you seem to assume I have more context than I actually do when I read postings. At least when it's cross-posted if I for some reason decided to look closely at all of the headers that it was cross-posted would become quickly apparent. Previously, though, you even expected me to know at a glance when a message was multi-posted separately to various groups, though nothing in the headers would indicate this. Only doing a Google search for every message's content would reliably detect multi-posting, and I'm not about to start doing that just to satisfy *you*. :P -- http://mail.python.org/mailman/listinfo/python-list
Re: Latest models of Gibson guitars
On Aug 21, 8:52 am, kaldrenon <[EMAIL PROTECTED]> wrote: > On Aug 20, 8:54 pm, Twisted <[EMAIL PROTECTED]> wrote: > > > If the message then > > says something absurd, like "this is a newsgroup about Python" when > > I'm reading it in cljp, well, what do you expect? :P > > I think most would expect you to go, "WTF?" but then, like a rational > person, click the helpful little "More options" link that GG provides [snip rest of insult-implying randomness] Er, right, whatever. :P > > though nothing in the headers would indicate this. > > Newsgroups: comp.lang.java.programmer, > microsoft.public.dotnet.framework.aspnet, comp.lang.python, > rec.photo.digital, alt.home.repair That indicates a *crosspost*. As I was saying in the post you've willfully misinterpreted in order to attack me, there is however nothing of the sort to indicate a *multipost*. -- http://mail.python.org/mailman/listinfo/python-list
Re: Xah's Edu Corner: Under the spell of Leibniz's dream
On Aug 23, 3:38 am, Matthias Buelow <[EMAIL PROTECTED]> wrote: > In comp.lang.lisp Bikal KC <[EMAIL PROTECTED]> wrote: > > > I used usenet years ago then stopped for couple of years. I remember > > seeing him/her on c.l.perl I believe doing the same thing he/she is > > doing atm. I'd say the ultimate usenet superstar. Wow! > > I think it's some (probably mild) form of autism. > No offense intended, Xah. Yeah, yeah, that's what they all say, especially when they do that most-common of usenet things -- insult your mental health and tone it as if it were a very compassionate and understanding suggestion to seek medical treatment rather than the flame that it is. :P -- http://mail.python.org/mailman/listinfo/python-list
