the Modernization of Emacs
in [Lisp]
|
From: Tim X on 16 Apr 2006 12:32 "Richard G. Riley" <rgrdev(a)gmail.com> writes: > 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 > Think about what it does and the suitability seems to fit by my reading. The apropos command provides a list of commands/variables matching your regular expression - which you usually define according to what you believe will match to the purpose you want to apply them to. So, it provides a list of commands/variables to fit a certain purpose. The fact it also does this when you want and provides some documentation/explination fits with it being available at an 'opportune time' and with 'interjection or further comment: with regard to the > present topic'. Sure, its not necessarily a word everyone uses day to day, but if we restricted ourselves to only using words in common usage, things would be even more confusing. How many of us used cache regularly before computers? My question is if its such a bad choice, come up with a better one that doesn't create its own confusion. This BTW is my point when I refer to how people should stop moaning about how unsatisfactory it is and do something about it. It doesn't necessarily translate to "do it yourself" - anyone is free to get others to help them do it. However, it does mean stop moaning - either do something constructive or switch to something different or accept things as they are, just don't moan about it. >> >>>> 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. > I was following on from what you said and was saying that IF SW developers tried to be innovative rather than following what was popular, we would have more dieversity within the windows world for a while - I was not saying there was diversity there as there clearly isn't. Windows is locked into a single UI paradigm which is now considered to be not just the "normal" way to do things, but also by many the "right way". >> 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. > Fair enough - probably was getting argumentative. I just find it frustrating when people on one hand can recognise the power and incredible flexibility of a system like emacs, but at the same time criticise it for not having a simpler and more intuitive interface. Firstly, I find the interface to be quite intuitive and don't see the mess or kludge of things you seem to observe. I'm a big user of key shortcuts and avoid the mouse as much as possible - the emacs keybindings were the first I ever came across which had some easy to follow pattern to them. the use of buffers instead of files makes perfect sense because they are not all files and the use of frames and windows makes as much sense as any other terminology - especially considering I cannot think of many MS apps which have the same frame concept. Now, because some company has been very successful in marketing their product and now dominates the desktop environment, we have people like Xah coming out of the woodwork telling everyone that anything which doesn't follow the MS interface style and terminology is wrong and needs to be changed. Will we then change it in 20 years time again when some other paradigm and terminology becomes popular? I'm mean, really, one read of the emacs tutorial and this sort of stuff becomes pretty clear - its not bloody rocket science. There are some things I would like to see in a future emacs. I would like to see it use a version of elisp which has better namespace seperation or a better package space, but apart from that, I find it pretty straight forward. It would be nice to have threading so that long operations don't stop you from switching to another window/frame and continuing to work and I'm really interested in how some of the really innovative work relating to things like semantic will develop. I'm not interested in the opinions of users who have spent an hour playing with it telling me whats wrong with it when they haven't used it long enough to see what is different about it and what is done right. Its interesting that I see few people moan about MS Office and all its components - this has got to be one of the worst applications for crappy interfaces I've used in a long time and its crappyness is not limited to poor keybindings and unfamiliar terminology (though I think its got plenty of that as well). With emacs, I cannot see how you could make things better and not lose power or flexibility. Sure, there has been some discussion in the past about changing elisp to something else, but there is just too much really good elisp out there to replace (the fact many of us are running elisp written over 10+ years ago with no or little updating means something must be going right). >> >>> >>>> >>>> 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. Well, in fact, not all keyboards had easy access to pageUp/down or even arrow keys - they may do now, but they didn't as little as 10 years ago. I do have arrow keys and pgup/dwn and a numeric keypad etc. However, I rarely use them. This is for the same reason I don't like using a mouse. Moving your hands away from the main keyboard just slows you down. Prior to emacs, I was a VI user and I didn't use the arrow keys and pgup/dwn keys then either. > >> 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. > thats a bit ironic - I think it was me who pointed out the easymacs package etc. I looked at Xah's post and I've checked out his website - he as next to nothing in the way of good ideas - most are ill conceived and show only very shallow thinking about the problem. Much of what he says is based on FUD relating to things he really hasn't bothered spending the time to get to understand. Essentilly, Xah is very much like a young child - he has an inquisitive mind, but gets bored very quickly and doesn't want to really put in much effort to understand things - if its not bleedingly obvious in the first few hours or attempt at use, he either writes it off or starts writing about what needs to be done to make it work "in the modern world". I'd be interested in know which of his ideas you thought were of any merit? >> 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. > I'm not a religious zelot regarding emacs and initially was forced to use it and now use it simply because there is no other tool which meets my needs. However, I've seen nothing put forward by Xah which has any real benefit or which would make any real improvement. >> 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" ... :-; > True enough - but why not? If your going to rubbish how things are at the moment I think its reasonable to suggest you back it up with effort to do something about it rather than screaming into the internet that some magic force should do it. The suggestions put forward by Xah were not discounted because he was proposing change, they were discounted because they had no benefit and were based on misconception and misunderstanding of emacs with claims that had no foundation in fact from someone who wanted to change something he was unfamiliar with to become something he was familiar with - in the same way that you can argue the problem is those who are familiar with how it currently is are resistant to change, peole like Xah are just as resistant to things which don't match with what they are familiar with. As they are coming to the new system, I don't think its unrreasonable to suggest that if they don't like it, then they should be the ones to change it. >> 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
From: Chris Menzel on 16 Apr 2006 14:11 On Sun, 16 Apr 2006 07:02:50 -0800, Floyd L. Davidson <floyd(a)apaflo.com> said: > David Kastrup <dak(a)gnu.org> wrote: >>Ari Johnson <iamtheari(a)gmail.com> writes: >>> Isn't it interesting that the vast majority of programmers and other >>> hackers work most efficiently with either Emacs or vi, and can't >>> stand to be without their favored editor? >> >>Most people could not stand stopping to breathe in Mexico City. That >>does not mean that the air is good there. > > False logic. People cannot stand to stop breathing anywhere; hence of > course it actually says nothing in particular about air in Mexico > City. That nothing in particular follows about "air quality" was exactly Kastrup's point.
From: Patrick May on 16 Apr 2006 14:57 "Richard G. Riley" <rgrdev(a)gmail.com> writes: > I have a reasonably decent command of the English language. "apropos" > is not a word in common use. Relax. "Apropos" is not a word that would be considered particularly unusual and certainly not in any way confusing among the people I converse with day to day. "Decent command of the English language" is evidently in the eye of the beholder. Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)
From: Cor Gest on 16 Apr 2006 15:19 Some entity AKA Alan Mackenzie <acm(a)muc.de> wrote this mindboggling stuff: (selectively-snipped-or-not-p) > Anyhow, congratulations on starting a thread which has gone on to 150 > articles. :-) ah, well it's a holyday-weekend, so why not have a little fun. For there can't hardly be anything more usefull to do except chasing easter-bunnies anyway. Cor -- I do NOT use any Windows(TM) products, therefore I do NOT fear mail from strangers http://www.clsnet.nl/mail.html If everything else failed to satisfy you, try reading The Frign' Manual (defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
From: M Jared Finder on 16 Apr 2006 19:17
Tim X wrote: > "Richard G. Riley" <rgrdev(a)gmail.com> writes: > >> 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. >> > > thats a bit ironic - I think it was me who pointed out the easymacs > package etc. > > I looked at Xah's post and I've checked out his website - he as next > to nothing in the way of good ideas - most are ill conceived and show > only very shallow thinking about the problem. Much of what he says is > based on FUD relating to things he really hasn't bothered spending the > time to get to understand. Essentilly, Xah is very much like a young > child - he has an inquisitive mind, but gets bored very quickly and > doesn't want to really put in much effort to understand things - if > its not bleedingly obvious in the first few hours or attempt at use, > he either writes it off or starts writing about what needs to be done > to make it work "in the modern world". > > I'd be interested in know which of his ideas you thought were of any > merit? There is merit toward doing things the same way as everyone else. There's also merit in keeping things the same. The first makes it easy to learn other apps in a *basic* way; you can rely on certain things always being there and acting generally in one way. The second prevents you from having to re-learn an app as the popular interface changes. Both of these are useful; I know I encountered initial difficulty learning Emacs because C-x/C-c/C-v/C-z did not do what I expected. Now I use cua-mode, and everything works out fine. I think C-x/C-c/C-v/C-z/C-o/C-s/C-a/mouse-3 are here to stay. Every application I've seen in the past ten years, other than Emacs, has the same meaning for each of these keybindings. Using the same meaning as other applications here would be a *good* thing. On the other hand, there are common keybindings that are disagreed upon, like for mouse-2 and C-y. Using the same meaning as other applications do here would be a *bad* thing, as there is no commonly accepted standard, so it'd be better not to change anything. I think Xah is right that Emacs should provide a mode where C-x/C-c/C-v/C-z/C-o/C-s/C-a/mouse-3 act as in every other app, and that mode should be enabled *by default*. He is also right that there should also be a menu entry (though not necessarily a keybinding) for Redo. It would be nice if "window" could be renamed to "buffer-area" and "frame" to "window", but I don't see that ever being feasible until Emacs has proper namespace support. All of Xah's other suggestions are pointless or not really thought out. But don't discount everything Xah says just because he thinks the *scratch* buffer should be eliminated or longlines-mode should be enabled by default in every buffer. There are some good ideas in there -- I think a longlines-code-mode would be really cool to have, and making *scratch* start with buffers-offer-save=t would be nice. -- MJF |