the Modernization of Emacs
in [Lisp]
|
From: Miles Bader on 16 Apr 2006 19:30 M Jared Finder <jared(a)hpalace.com> writes: > 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*. No. Doing so would give complete newbies an easier first fifteen minutes, but it would would interfere with the task of learning the _rest_ of Emacs keybindings -- and the latter is a much harder (and more important) task than the former. Is it really that hard for people to learn _three_ new keybindings?!? [It's not like a complete newbie is unable to function -- most that I've observed simply use the menus at first, and slowly pick up whatever keybindings they find useful.] -Miles -- We have met the enemy, and he is us. -- Pogo
From: Tim X on 16 Apr 2006 22:38 M Jared Finder <jared(a)hpalace.com> writes: > > 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. > This is probably where we will disagree - I think the merit of doing things the same way as everywhere else has limited and often over stated benefits. This can be hard to justify if it also means we lose any real innovation. There are three main reasons why I don't agree with changing the default or modifying emacs base key bindings - 1. The complaint everyone has surrounds the basic cut/copy/paste and cursor movement keys. However, changing the current defaults will create inconsistency with the underlying approach used in emacs (yes, it actually does have a method to the maps). This will make learning and becoming familiar with the other powerful key bindings more difficult and it will becom eless likely new users will realise this power exists. Note that for a long time, arrow keys, pgup/pgdwn have worked anyway. 2. There is a lot of documentation and examples of how to bind keys and change key bindings from the defaults, so lets leave them and give the new user the opportunity to try something which many consider superior to the common approach, but leave them with the ability to change things if they don't like it. 3. There are already plenty of packages which can change key bindings to whatever other common environment/editor the new user wants. None of these should become the defualt as most of them do lose some functionality or have inconsistency and most people don't bother changing the defaults, so they won't know about the really good key bindings which exist (they are in fact extremely good for anyone who is a touch typest). About the only thing which I'd be critical about regarding the key bindings is that most keyborads have the control and meta keys in poor positions. However, emacs cannot predict what keyborad somebody has and on many systems, its fairly trivial to re-map control and meta to other positions. > 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. > Not when you view the whole range of keybindings and what impact this would have on them. Sure, a lot of new users would find cutting, copying pasting etc easier, but I suspect they would then find the rest of the key bindings much harder to follow and emacs has a lot more key bindings than most other programs. If someone can come up with a consistent approach which can work as well as the current one (or hopefully better), then put it forward. I don't have a problem with changing default behavior, but only when that change is going to give us real benefits and not lose us things. There is a lot more at stake here than changing a few key bindings - you also have to define a new methodology/approach to the key binding model so that developers know what keys they can and cannot use in their emacs apps. > 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. > but why should these things be made the default? As already stated, I can see more being lost in the long run doing this than any real gains. The fact the new user can make these changes quite easily via cua-mode or easymacs or any of the other packages that do similar things makes changing the defaults even harder to justify IMO. You could argue this information isn't easily available - but I'd say that if a user wasn't capable of a basic google search and cannot work out how to do it, then they are probably wasting their time with emacs anyway. > 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. > I don't discount everything Xah says just because he says it (though I would say I'd be right to do so 80% of the time). I discount Xah as just meaningless white noise because he actually contributes nothing substantial and is not interested in debating his claims. He comes along and posts some personal rants with considerable amounts of abuse and swearing and always demands everyone else fix what he perceives as being wrong with the world, yet does nothing himself except send off some post with his latest rant to a newsgroup. -- tcross (at) rapttech dot com dot au
From: Robert Uhl on 17 Apr 2006 01:14 Christophe Rhodes <csr21(a)cam.ac.uk> writes: > [ 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. I don't deny that--but that's not, I believe, the majority of use. And _viewing_ images and _hearing_ sounds can be handled pretty satisfactorily with a text viewer--it's the editing which doesn't mesh. > people also use their computers to prepare tax returns Which are composed of numbers, which are characters, which are text. Emacs offers as good an interface to editing a tax return as the web app I recently used. > typeset scientific papers with equations, tables or figures in them I think that a text+ editor can handle that pretty well. Those are all still, at heart, dealing with characters. > share their calendars with other members of their office; telephone > each other, trade stocks... the list goes on. And I think that all that still works with a text editor: calendars are just characters; telephone numbers are just numbers; stocks are named with text, their info is text. A good hypertext-aware editor can handle all that, viz. emacs-w3m. > Where does your assertion about the vast majority of tasks come from, > and how is it relevant even if it is true? Sheer assertion:-) But I can say from professional experience that the vast majority of business computer use is viewing text with some pretty pictures added. > 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. I don't think that I claimed that it could model _everything_, nor that anyone who advocates the kitchen-sink emacs style claims such--merely that it models the common case. Certainly, if one wishes to edit an audio file then one needs a specialised editor. But if one is sending email, writing proposals or viewing product documentation, then a text editor can handle one's needs. >> 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)? The developer. Writing elisp is pretty easy--I've even written a little major mode to deal with my blog postings--writing CLIM code is...rather less so. Much of this is because emacs already handles all of the annoying, niggling little stuff for one, and one can just dive in and start working on one's problem. If Climacs would provide the same environment, then it would be much easier to dive into... > 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. I'll admit that's part of it--but seriously, I've not found too many good introductions to learning how to write good emacs lisp. But to learn how to write a few elisp extensions to do a common task is relatively easy, while figuring out how to do much with CLIM is...not. I tried to like CLIM, I really did. And if Climacs would try to be as extensible as emacs, then maybe I could slowly dip my toes in, as I can with emacs! -- Robert Uhl <http://public.xdi.org/=ruhl> I once did a dd if=bootdisk.img of=/dev/hda. Luckily, /dev/hda had Windows 95 and a swap partition on it. /dev/hdb was where Linux lived. Nothing important was lost. --PD
From: Robert Uhl on 17 Apr 2006 01:17 "Richard G. Riley" <rgrdev(a)gmail.com> writes: > > 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? What's your suggestion? That _is_ the most appropriate English word to use--or at least, I can think of none better (relevant? pertaining?). I hardly think that the emacs developers can be blamed for illiteracy amongst users... > 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 might agree with you if you were going on about C-f and C-b--but C-v and M-v are _useful_. What would you prefer? -- Robert Uhl <http://public.xdi.org/=ruhl> To make laws that man cannot, and will not obey, serves to bring all law into contempt. --E.C. Stanton
From: Robert Uhl on 17 Apr 2006 01:36
M Jared Finder <jared(a)hpalace.com> writes: > > 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. window->pane, frame->window -- Robert Uhl <http://public.xdi.org/=ruhl> Nobody ever got fired for choosing Microsoft. Nobody ever looked stupid for choosing Linux. --Jebediah21 |