the Modernization of Emacs
in [Lisp]
|
From: Robert Strandh on 15 Apr 2006 18:36 Robert Uhl <eadmund42(a)NOSPAMgmail.com> writes: > Robert Strandh <strandh(a)labri.fr> writes: > > > > In my opinion, Emacs provides a framework for applications simply > > because no other such framework existed at the time. Now we have > > CLIM/McCLIM, which does a great job supplying such a framework. > > Given that we're all reading & writing text constantly, it makes sense > for all text viewing & editing to take place within a consistent and > uniform environment--and thus that it take place within one environment. Sure, this is fine. However, many of the applications that are implemented in the Emacs environment do not even need to edit the text, and do not need the concept of an Emacs buffer to display their contents. In my opinion, the main part of a text editor is about efficiently managing incremental changes to a buffer, incrementally parsing the contents after such modifications, and displaying incremental changes efficiently. > Emacs provides this environment: C-v always scrolls down; C-g always > gets me out of whatever predicament I've gotten myself into. Yes. In fact I abstracted out this particular aspect of Climacs into the ESA (Emacs-Style Application) library, which is now also used for completely different applications such as the Gsharp score editor and the dired application. The ESA library also contains things like numeric argument handling, keyboard macros, minibuffer management, and more. I find it very useful not to tie this together with text editing, though. > In some > ways it really is like an OS which hosts many applications--the only > thing is that they can each access one another's internals very easily. > I suppose that this is a good amount of the attraction of a Lisp OS, > come to think of it. Yes, and that is also the reason I am using CLIM for that. > Anyway, CLIM supplies an arcane, painful to learn framework whereas that > of emacs is straightforward and easy to get started with. I hardly > think that one can substitute for the other. Really? CLIM is an extremely rich and flexible framework for writing collaborating applications. I guess ESA is proof of this; it shows that you can replace the default CLIM command loop without giving up presentation types, and the other goodies of CLIM. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. ---------------------------------------------------------------------
From: Christophe Rhodes on 15 Apr 2006 19:59 [ note f'ups: limited relevance to emacs by now ] Robert Uhl <eadmund42(a)NOSPAMgmail.com> writes: > I disagree. The vast majority of the tasks performed with a computer > involve reading and writing text (yes, some people create graphics, but > they are a relatively small fraction of the computer-using population). Many, many people deal with sound and images these days, at least recreationally. Most people who use digital cameras, people with portable MP3 players, those downloading or making podcasts, not to mention amateur use of their computers as sound recorders, mixing desks, synthesizers, score editors... people also use their computers to prepare tax returns, multimedia presentations (not that that's necessarily a good thing ;-); typeset scientific papers with equations, tables or figures in them; share their calendars with other members of their office; telephone each other, trade stocks... the list goes on. Where does your assertion about the vast majority of tasks come from, and how is it relevant even if it is true? The existence of even a small minority of "tasks" which are not well modelled by the text-in-a-buffer paradigm does not invalidate that paradigm in its entirety, but it does invalidate that paradigm's claim to be able to model everything. > Given that we're all reading & writing text constantly, it makes sense > for all text viewing & editing to take place within a consistent and > uniform environment--and thus that it take place within one environment. This, on the other hand, is quite a reasonable claim; consistency, for similar actions, probably assists in learning applications of non-trivial complexity. > Emacs provides this environment: C-v always scrolls down; C-g always > gets me out of whatever predicament I've gotten myself into. It does that by convention. There is nothing preventing a piece of code globally rebinding C-v or C-g to scroll-up or repeat; I am not arguing that there should necessarily be, only that your perfectly stable environment isn't that way by divine fiat nor even by intelligent design of the emacs environment itself, but by the social context in which it has evolved. > Anyway, CLIM supplies an arcane, painful to learn framework whereas that > of emacs is straightforward and easy to get started with. I hardly > think that one can substitute for the other. For the user of emacs (CLIM) or for the developer of software to run on emacs (CLIM)? Not that it matters much to me, though some (see upthread passim :-) might dispute that emacs is straightforward and easy to start with; I dispute your characterisation of CLIM, though I am happy to concede that the availability of CLIM didactic material is far more limited than for emacs, and suspect that this might have bearing on your perception. Christophe
From: Floyd L. Davidson on 15 Apr 2006 20:17 "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... >> 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. True, but a non sequitur anyway. Neither does it preclude not desiring to see any change or increase potential market share. And none of that has *anything* to do with trolling by Xah, who posts nothing but therapeutic noise anyway. Your statement isn't any more logical than his are... -- Floyd L. Davidson <http://www.apaflo.com/floyd_davidson> Ukpeagvik (Barrow, Alaska) floyd(a)apaflo.com
From: Ari Johnson on 15 Apr 2006 20:45 "Richard G. Riley" <rgrdev(a)gmail.com> writes: > Much as I love emacs and dont agree with "windowizing" it for newbies, > this is a pretty poor defence. If there is a common sense way of doing > something and a long winded convoluted way and the second option is > chosen then it really is a poor show to say "if you dont like it then > fix it yourself.". One of my favorite examples of emacs "elitist" > naming to confuse the foreigner or the newbie is "apropos" ... I mean, > did noone think to name this something different? http://www.m-w.com/cgi-bin/dictionary http://www.cse.msu.edu/cgi-bin/man2html?apropos?1?/usr/man Common usage and proper English are not "elitist" and are not unique to Emacs. Do you have a particular word to suggest as being more appropriate (or, so to speak, more apropos) to the task of this command?
From: Tim X on 16 Apr 2006 02:56
"Richard G. Riley" <rgrdev(a)gmail.com> writes: > On 2006-04-13, Tim X <timx(a)nospam.dev.null> wrote: >> "Tim Bradshaw" <tfb+google(a)tfeb.org> writes: >> >>> Sacha wrote: >>>> He's got a point though, >>> >>> I don't think he really does. >>> >>> Before I start: yes, emacs is crufty in a lot of ways (horrible lisp >>> dialect etc), yes it's left-field in lots of ways (odd key bindings for >>> people coming from a Windowsoid background), yes it's big and >>> complicated. Yes, yes yes. >>> >>>> as a newcomer to lisp, and windows user, >>>> i found it pretty hard to have to learn emacs while learning lisp... >>>> None of these two are trivial. >>> >>> Who said learning to program in a new language should be trivial? And >>> do you *really* think that Emacs is the thing that's making it too hard >>> to learn? Programming is a fairly intellectually hard activity, and if >>> you're going to succeed at it then you probably won't be put off by >>> something like Emacs - some time you're going to have to deal with >>> J2EE, or Unix or something, and if you think that Emacs is hard & >>> cruftily designed, then you have another think coming. >>> >>> I play the guitar: not, generally, very well, but well enough. Playing >>> a musical instrument is kind of like programming: it's hard, and the >>> tools you use are generally not perfectly designed. And two things are >>> immediately apparent. Firstly people who try the guitar and complain >>> because the strings are too tight, the hand position makes their wrists >>> sore, it's just basically impossible to tune the thing right (really, >>> it is) and any of the myriad of other things which are objectively >>> wrong with guitars don't get very far. Secondly, of people who persist >>> and through talent and hard work become great guitarists *very few* >>> redesign the instrument. Not because it's a perfect design - it's >>> clearly not - but because it's a good enough design and there are more >>> important things to do, like playing music. >>> >>> Emacs is like a guitar: imperfect, hard to learn, but you can do great >>> things with it. And, I'm glad to say, the vast majority of people who >>> understand emacs well enough to change it realise that there isn't much >>> point - not that such changes would not be a good thing, but because in >>> the finite amount of time they have, changing emacs would be a less >>> good thing than just getting on and using the flawed tool. (I'm also >>> glad that some people do work on Emacs, just as I'm glad that there are >>> people working on new guitar designs.) >>> >>>> I can't imagine any better way than emacs to frighten the newbie lisper. >>> >>> Anyone who wants to seriously look after Unix/Linux machines needs to >>> be at least competent with vi, and if you think Emacs is frightening >>> then, well. And lots of people do this, by the way. You should be >>> glad that you don't have to learn ed any more. >>> >> >> Pretty well said. >> >> The thing which keeps striking me about the moaning regarding emacs is >> why the hell, if all these people find it so bad, none of them have >> come up with a replacement. Its not like it cost them anything and >> therefore they have some right to complain or that there isn't an >> alternative editor. > > Much as I love emacs and dont agree with "windowizing" it for newbies, > this is a pretty poor defence. If there is a common sense way of doing > something and a long winded convoluted way and the second option is > chosen then it really is a poor show to say "if you dont like it then > fix it yourself.". One of my favorite examples of emacs "elitist" > naming to confuse the foreigner or the newbie is "apropos" ... I mean, > did noone think to name this something different? > 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. Can you propose another single word term which more accurately reflects what the command does? >> 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 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. > >> >> 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 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. >> >> 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 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. 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 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 |