From: Richard G. Riley on 16 Apr 2006 09:18 On 2006-04-16, Tim X <timx(a)nospam.dev.null> wrote: > But who says the second converluted approach was selected? My point is > that if emacs does it badly, how is it that nobody has done it better? > If someone has done it better, then why aren't all these people who > are complaining about how emacs does it not using this better > solution. > > Your comment regarding apropos doesn't hold water. The term is very > appropriate to its purpose. The fact our vocabulary these days seems > to be less than it was 100 years ago is not sufficient justification > for reductionism in how we use words. Also note that apropos has been > used in other applications, including Unix for a long time. Both of your arguments above indicate a reluctance to change anything : which is why emacs is so cumbersome to so many. Dont get me wrong : I love it - but to say its "honed" is complete horse - its a giant. > > Can you propose another single word term which more accurately > reflects what the command does? Heres the miriam definition : could you explain how it fits the purpose clearly? Main Entry: 1ap·ro·pos Pronunciation: "a-pr&-'pO, 'a-pr&-" Function: adverb Etymology: French à propos, literally, to the purpose 1 : at an opportune time : SEASONABLY 2 : by way of interjection or further comment: with regard to the present topic > >>> Its very easy to sit back and criticise things, but if you really have >>> something valid to prove, go out and do it and stop bloody moaning. >> >> If this was the attitude of most SW designers then no advances would >> have been done and the world would be full of incompatible and highly >> individualistic interpretations of what ought to be a common look and feel. >> > > Why? Surely things would be more innovative and possibly even better > if SW designers actually strived to improve things rather than just > following the 'popular' approach. Sure, we possibly would have a > windows world with a lot more variation between apps, but at least >we whyt do you mean "more variation between apps"? Windows does, IMO, provide a far more concistent integration between apps than, say, Linux. I use both, Linux more. > are mor likely to see even better approaches emerge and eventually, a > standard based on preferred fuctionality rather than marketing and > market share would prevail. > >>> >>> and of course, if you don't like it and don't want to create an >>> alternative, well then just don't use it. There is no law that says >>> because you want to do lisp you have to use emacs. If you like another >>> tool use it. >> >> Thats fair enough. emacs is addictive though :-; > > Funny that. I wonder why such a poorly designed/implemented > application can become so addictive. You're being purposely argumentative. Its addictive because it has a lot of strengths and takes a lot of time to get used to : it makes it an aim or a goal to master it. No other deitor with the possible exception of vi has such a cult following. > >> >>> >>> Emacs may not be perfect and I've never heard anyone say it was. the >>> learning curve can be difficult and yes, you may have to re-think some >>> of the paradigms you have taken for granted. However, surely its >>> obvious that with power comes complexity and a requirement to learn >>> how to harness that power. I don't understand where the mindset comes >>> from that says a powerful tool like emacs should be as easy to use as >>> wordpad. >> >> I would agree with you here. But unnecessary complexity is silly. Read >> the manual : it still talks about C-v and stuff for moving around in a >> buffer - outdated and outmoded IMO and very likely to frighten off >> newbies who might otherwise, in the long run, have benefited from >> emacs and maybe have even contributed back into the community. >> > > I was a newbie 10 years ago when I switched to emacs. However, I > didn't think twice about C-v being an issue or get even a little You surprise me. 99.99999999999% of users would have keyboards with arrow keys and page up/ down. They work in emacs. Document it in the tutorial. > frustrated/scared about the differences. In fact, emacs was the very > first app I ever used where the keyboard shortcuts seemed to follow a > pattern rather than appearing somewhat random. > > At the time, I was given some very valuable advice by an old time > emacs user. Essentially, he said to me that while you could customize > almost anything within emacs, he advised me to use ti in a default > configuration for 6 months and then only make the customization I > really wanted. After 6 months, I realised the way it was setup with > its defaults were pretty good and very little customization was > required. Even now, after 10 years, most of my 'customization' has > been to make emacs fit with my work environment rather than make emacs > fit with my interface expectations. I would agree with that. > >>> >>> The same goes for Xah and his unix hating attitude. He puts in hours >>> of time writing about how awful it is and how it should be wiped from >>> the planet - yet it seems to be what he uses all the time. If he >>> thinks other operating systems are so superior, why doesn't he just >>> ignore what he doesn't like and just get on with what he does think is >>> good - thats certainly how I deal with MS windows. >> >> Using something regularly does not necessarily preclude a desire to see >> it improve and increase its potential market share. > > Although I don't actually care about emacs' market share beyond there > being enough people involved to keep its evolution happening and I > agree that regular users should be thinking about ways to make it > better, I don't believe Xah falls into this catagory. The questions he > has asked on gnu.emacs.help show he has a very poor grasp of how it > works, how to configure it and what already exists. The bottom line is > that Xah doesn't like Unix and anything which can be associated with > it, including emacs. He therefore spends a lot of wasted time trying > to justify why its so poor, but has not a single original idea > regarding how to make things better. His thinking is shallow and He actually came up with a few suggestions. You appear unwilling or unable to recognise them. Another postre pointed out a version of emacs which has, funnily enough, implemented a fair few of them to make emacs accessible to those who are not willing to invest the time and effort to learn the base products strange ways. > ill-informed and merely the regurgitation of other peoples > ill-informed ideas. Essentially, I thinnk he is out of his depth and > lacks either the historical or technical background to appreciate why > certain design decisions were selected. > It is also eas to fall into the defensive mode : as you appear to have done. The fact that you are clearly an emacs adovate and familiar with the way it does things does not necessarily make them right NOW : times and interfaces do change. I am playing devils adovcate : I like emacs as it is. > Its very easy to rubbish things, but much much harder to offer better > alternatives. I would have some respect for Xah if he proposed well And also very eays to say "tough, if you dont like it then go and make it better yourself" ... :-; > reasoned and researched alternatives, but he doesn't. All he does is > regurgitate a fairly uninformed opinion with no evidence of research > or deeper thought concerning the issues. > > Just to balance things up, there are things about emacs I think could > be better. However, the difference is that I've not been able to work > out alternatives which are better and don't have more negative side > effects. therefore, I keep them to myself and continue to think about > them from time to time. when I have something which I feel is a really > good alternative that is overall postive, I'll put it forward. > However, so far, either I'm not immaginative enough or simply not > smart enough to make things better overall. > > Tim > > -- > tcross (at) rapttech dot com dot au -- Aspirat primo Fortuna labori.
From: Richard G. Riley on 16 Apr 2006 09:21 On 2006-04-16, Floyd L. Davidson <floyd(a)apaflo.com> wrote: > "Richard G. Riley" <rgrdev(a)gmail.com> wrote: >> >>I would agree with you here. But unnecessary complexity is silly. Read >>the manual : it still talks about C-v and stuff for moving around in a >>buffer - outdated and outmoded IMO and very likely to frighten off >>newbies who might otherwise, in the long run, have benefited from >>emacs and maybe have even contributed back into the community. > > Can you explain what you mean? I'm missing something, because > while I may not agree with your other statements, it wasn't hard > to at least see your point. Tell me what is wrong the "talks > about C-v and stuff for moving around in a buffer"? Do you > disagree with keyboard sequences? With that particular key > binding? Or with teaching new users how to use it? I can't see > a lick of sense to such a statement... You cant see what I mean with regard to a two key sequence to move a cursor when there are special keys more commonly recognised by the newbie on their keyboard? >>Using something regularly does not necessarily preclude a desire to see >>it improve and increase its potential market share. > > True, but a non sequitur anyway. Neither does it preclude not > desiring to see any change or increase potential market share. Ridiculous argument. That is not the point. The point is whether its right or wrong to make improvement suggestions.
From: Alan Mackenzie on 16 Apr 2006 04:47 Xah Lee <xah(a)xahlee.org> wrote on 14 Apr 2006 08:39:15 -0700: > Some Notes about Terminology > The terminology "buffer" or "keybinding", are technical terms having to > do with software programing. The term "keybinding" refers to the > association of a keystroke with a command in a technical, software > application programing context. That is to say, one "binds" a keystroke > to a command in an application framework. I think it's an exaggeration to say that "buffer" and "keybinding" are technical terms. "Bind" is a normal English word, meaning something like "tie together". To "tie something (a command) to a key" is an easily and immediately understood metaphor. > The term "buffer" refers to a temporary abstract area for storing data, > in the context of programing or computer science. Again, "buffer" is normal English word. A buffer on a railway waggon is the spring that gives a bit of slack between the waggon and its neighbour, and stops them jostling eachother around too much. A "buffer zone" in a war is a strip of land between the two hostile territories, where UN peacekeeping soldiers keep the two enemies apart, to stop them killing eachother too much. An Emacs "buffer" is an area of store which keeps the user from messing up his hard disk too much. > These terms are irrelevant to the users of a software application. They are clear and obvious metaphors to native English speakers. > As a user of a text editor, he works with files. The terms "opened > file" or "untitled file" are more appropriate than "buffer". > Since emacs is also used for many things beside files, for example, > file management, ftp/sftp, shell, email, irc etc., the proper term can > be "work area", "work space", or simply "window". Trouble is, all these terms are either vague or have other meanings. "Work area/space" are used all over the place, and to adopt them into Emacs would cause confusion. For example, the C library call "malloc" allocates a "work space". "Window" is already used in Emacs for "a portion of the screen" and more recently has been adopted by GUI environments for what Emacs calls a "frame". Even "file window" would be unclear. > And, the term "keyboard shortcut" refers to typing of a key-combination > to activate a command. It is also more appropriate than "binding" or > "keybinding". It's not. "Keyboard shortcut" is longer than "keybinding", and has a rather twisted connection with ordinary English. A "short cut" in English means "a way of getting somewhere with less work than usual", usually an illegitimate way. The "somewhere" is usually a menu item, and the implication of "short cut" is that working a program with the mouse is the normal, proper way of doing it, and using the keyboard is improper. Anyhow, I've said all this in another post. > Adapting these terms will not only increase emacs popularity, but are > in fact more correct if we really want to tech geek about it. I doubt either is true. Changing these terms wouldn't make much difference to the popularity of Emacs either way. They certainly aren't more "correct". Anyhow, congratulations on starting a thread which has gone on to 150 articles. :-) > Xah -- Alan Mackenzie (Munich, Germany) Email: aacm(a)muuc.dee; to decode, wherever there is a repeated letter (like "aa"), remove half of them (leaving, say, "a").
From: Floyd L. Davidson on 16 Apr 2006 09:55 "Richard G. Riley" <rgrdev(a)gmail.com> wrote: >On 2006-04-16, Floyd L. Davidson <floyd(a)apaflo.com> wrote: >> "Richard G. Riley" <rgrdev(a)gmail.com> wrote: >>> >>>I would agree with you here. But unnecessary complexity is silly. Read >>>the manual : it still talks about C-v and stuff for moving around in a >>>buffer - outdated and outmoded IMO and very likely to frighten off >>>newbies who might otherwise, in the long run, have benefited from >>>emacs and maybe have even contributed back into the community. >> >> Can you explain what you mean? I'm missing something, because >> while I may not agree with your other statements, it wasn't hard >> to at least see your point. Tell me what is wrong the "talks >> about C-v and stuff for moving around in a buffer"? Do you >> disagree with keyboard sequences? With that particular key >> binding? Or with teaching new users how to use it? I can't see >> a lick of sense to such a statement... > >You cant see what I mean with regard to a two key sequence to move a Not until you state it. >cursor when there are special keys more commonly recognised by the >newbie on their keyboard? 1) The special keys are *not* "more commonly recognized by the newbie". 2) The special keys are located in different places on different keyboards. 3) The special keys may not even exist on some keyboards. 4) The special keys are *never* located where they are easy for a touch typist to use. 5) The two key sequence is *easy* for a touch typist, is always in the same place on every keyboard, and of course *are* always on every keyboard. Your reasoning lacks a foundation. >>>Using something regularly does not necessarily preclude a desire to see >>>it improve and increase its potential market share. >> >> True, but a non sequitur anyway. Neither does it preclude not >> desiring to see any change or increase potential market share. > >Ridiculous argument. That is not the point. The point is whether its >right or wrong to make improvement suggestions. Learn something about logic. -- Floyd L. Davidson <http://www.apaflo.com/floyd_davidson> Ukpeagvik (Barrow, Alaska) floyd(a)apaflo.com
From: Jay Belanger on 16 Apr 2006 09:59
"Richard G. Riley" <rgrdev(a)gmail.com> writes: .... > Heres the miriam definition : could you explain how it fits the > purpose clearly? > > Main Entry: 1ap·ro·pos > Pronunciation: "a-pr&-'pO, 'a-pr&-" > Function: adverb > Etymology: French à propos, literally, to the purpose > 1 : at an opportune time : SEASONABLY > 2 : by way of interjection or further comment: with regard to the > present topic That's the definition given by Merriam-Webster Online for the adverb "apropos"; I rarely hear it used as an adverb; from the many uses for it given by Merriam-Webster, you have chosen the least appropriate. As an adjective, Merriam-Webster Online provides the definition: : being both relevant and opportune synonym see RELEVANT and "apropos" also used as a preposition. Jay |