the Modernization of Emacs
in [Lisp]
|
From: M Jared Finder on 17 Apr 2006 02:53 I've probably overzealously snipped your reply. If you feel I left something important out, please put it back and mention what I overlooked. Tim X wrote: > 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. I disagree. In Gnu Emacs, by default every single-character control sequence from C-a to C-z as well as odd ones like C-@ is used for some purpose. However, there are only 20 commands that I find myself using often enough that I think they deserve having one letter bindings. All the others are taking up keyboard real estate that is not needed. It would not be difficult to cut some of the cruft in the key bindings to find room for Control-X-prefix and mode-specific-command-prefix, which would be stupid to eliminate. I'd suggest starting with uncommonly used bindings like C-] (abort-recursive-edit) and C-z (iconify-or-deiconify-frame). > 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. That's not true. You could still keep the patterns native to the keybindings while moving around the keys the binding is on. If forward-character was moved to only be on <right>, there's nothing preventing M-<right> from being forward-word and C-M-<right> from being forward-sexp. In fact, that's how recent CVS Gnu Emacs works. And if, as an expert, you want to move forward-char to C-k, you can easily move forward-word to M-k and forward-sexp to C-M-k. > 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). NO! NO! NO! You shouldn't expect the beginners to be modifying their init file from the first day. Expecting a beginner to learn Emacs Lisp (the syntax) AND learn Emacs Lisp (the library) AND learn the Emacs keybindings AND learn Emacs terminology is expecting way too much. Leave editing init-files to the intermediate to expert users. A new user should start by learning the keybinding patterns (C-navigation/M-navigation/C-M-navigation, C-find/C-M-find, etc.) and a bit of terminology. Later on they can start customizing the keybindings to suit them. Expecting any more is like taxing the poor more than the rich because "the rich people earned their money". <snip> >> 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. There would be no benefit to experts. Experts already have gotten used to Emacs' bindings or have developed workarounds. But there'd be minimal pain to experts as well -- any expert who would not be able to add the 12 lines of Emacs Lisp to move the navigation commands back to f/b/n/p is not really an expert. Emacs could even have classic-keybindings-mode that uses the old keybindings, so it'd be only one line to add. There would be a huge benefit to beginners. A beginner expects the cua-bindings and gets confused and frustrated when they don't work. So if it's minimal pain for experts <snip> >> 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. I think Xah is good at raising problems from a end-user point of view. His solutions are often the wrong fix, but the problems he raises are almost always valid. Don't ignore his claims just because he swears a lot and is not interested in debating them. One of the problems he raised was with the *scratch* buffer. Xah said "Things emacs need to change for modern world: ... * Get rid of the *scratch* buffer." While this is not the a helpful description of the problem with the *scratch* buffer (it doesn't give any rationale), there are still problems with it. In particular I've encountered the following problems: * It starts in lisp-interaction-mode, which I have never ever used at program startup. * Even though the buffer starts out with "This buffer is for notes you don't want to save", I rarely want to lose any notes I take. Both of these could be easily addressed. Make *scratch* start in fundamental-mode and with buffer-offer-save=t. That'd take what, 2 lines of code? In fact, I'm gonna do this for just me right now. -- MJF
From: Christophe Rhodes on 17 Apr 2006 03:49 Robert Uhl <eadmund42(a)NOSPAMgmail.com> writes: > 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. Well, OK, but that's not what you said either; you said "the majority of tasks", not "the majority of time spent". I disagree with your rationalization of everything as a sequence of characters; I think that that kind of reductionism is unhelpful and limiting. > And _viewing_ images and _hearing_ sounds can be handled pretty > satisfactorily with a text viewer--it's the editing which doesn't > mesh. "pretty satisfactorily" or "very well"? Why aim for just satisfactory? Emacs is very, very good at what it does well; why shoehorn it into an adequate application somewhere where it doesn't quite fit? >> 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. Yes, all of these things /can/ be done with a text editor. But some of them can be done /better/ once you are liberated from "everything is a stream of characters", or even a hypertext-aware stream of characters. >>> 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. I still think that you're thinking at the wrong level. You could consider CLIM as somewhat analogous to the X11 protocol -- mechanism, not policy, though it does provide more mechanisms to do more things. A small CLIM application will inherit some kind of default policy -- e.g. an interactor pane, mouse click sensitivity -- but no coherent whole, that is true, just as small X11 applications have no coherent policy. To begin to codify one useful policy, between CLIM and Climacs there is something called -- coincidence of coincidences -- "Emacs-Style Application". This does not (yet) provide an integrated environment with everything coherent, but it does provide certain things which are likely to be common across emacs-style applications: buffer handling, file writing, a top-level loop with support for numeric arguments, keyboard macros, and C-g as an abort gesture. You might think that this is an artificial distinction, but it turns out that there are (at least) three applications using ESA out there: not just climacs, but also a file manager and a score editor (try doing /that/ with just text; it's still possible -- see lilypond -- but it's unbearably painful). >> 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. One of emacs' great features is its self-documenting and incremental nature. I'll try that again. Two of emacs' great features are its self-documenting nature and incremental customizeability; for the programmer, this adds up to the kind of discoverability that turns users into developers. Making an analogous system is likely to be important for all emacs-style applications, to harness the power of the users to help themselves become more efficient. > 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! So maybe instead you want to look at ESA and its clients, to see if that helps. While it's unlikely that Climacs itself will ever prohibit the kind of extensibility you are talking about ("I know, I'll write a spreadsheet for emacs") I doubt that it will encourage it either -- though if you haven't seen it already you might want to look at the slidemacs mode for what is possible under the current framework. However, if you can identify bits of climacs that might better be generalized and considered emacs-style, then that would certainly be of value. Cheers, Christophe
From: David Kastrup on 17 Apr 2006 04:10 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. > > 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. No. The mouse bindings of Emacs are _ingenious_. They obliterate the need for C-x/C-c/C-v. They make it possible to actually get work _done_ with the mouse without having to move back to the keyboard. The purpose of Emacs is _editing_, not browsing (and where browsing is involved, it does already make mouse-2 and lately mouse-1 work). And so its mouse bindings should stay optimized for editing. And it does an excellent job at that, better than anything else I know (including XEmacs). > 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. The default should not sacrifice usability. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Tim X on 17 Apr 2006 05:44 M Jared Finder <jared(a)hpalace.com> writes: > I've probably overzealously snipped your reply. If you feel I left > something important out, please put it back and mention what I > overlooked. > > Tim X wrote: >> 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. > > I disagree. In Gnu Emacs, by default every single-character control > sequence from C-a to C-z as well as odd ones like C-@ is used for some > purpose. However, there are only 20 commands that I find myself using > often enough that I think they deserve having one letter bindings. > All the others are taking up keyboard real estate that is not needed. And here is probably where we get to the core of the problem. Emacs is used by a lot of people in a lot of different ways and for a lot of different 'common' tasks - what I do every day is probably different from what you do every day. How do we work out which keys to use and which commands to bind to them for the 20 most commonly used? Also, are you sure all the keys from C-a to C-z are used? All of mine are now, but I cannot remember which ones I've bound myself and which ones were there by default. > It would not be difficult to cut some of the cruft in the key bindings > to find room for Control-X-prefix and mode-specific-command-prefix, > which would be stupid to eliminate. I'd suggest starting with > uncommonly used bindings like C-] (abort-recursive-edit) and C-z > (iconify-or-deiconify-frame). Well, for me C-z would not be a loss, but C-] is something I use quite often - which I think possibly supports my argument that its not that easy to just change the defaults. > >> 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. > > That's not true. You could still keep the patterns native to the > keybindings while moving around the keys the binding is on. If > forward-character was moved to only be on <right>, there's nothing > preventing M-<right> from being forward-word and C-M-<right> from > being forward-sexp. In fact, that's how recent CVS Gnu Emacs works. > Good god no! While I don't mind duplicate bindings on the arrow keys for those who want them, I would hate to see the main keyborad movement keys taken away. This is exactly the point I was trying to make about difference and innovation. Everyone I've ever known who has gotten use to the main keyborad movement keys has rather than using the arrow keys and mouse has grown to love the ease and speed of using those keys over the arrow keys. If we make only the arrow keys the default movement key bindings, few people are going to benefit from the discovery of how more efficient things can be using just the main keyborad keys. For a touch typist, they are far more efficient than lifting your hands off the keyborad. > And if, as an expert, you want to move forward-char to C-k, you can > easily move forward-word to M-k and forward-sexp to C-M-k. > >> 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). > > NO! NO! NO! > > You shouldn't expect the beginners to be modifying their init file > from the first day. Expecting a beginner to learn Emacs Lisp (the > syntax) AND learn Emacs Lisp (the library) AND learn the Emacs > keybindings AND learn Emacs terminology is expecting way too much. > Leave editing init-files to the intermediate to expert users. Stop over stating the issue! Customize means for the vast majority of things, the user doesn't even need to look in or even edit their ..emacs file. Adding a new package is generally quite straight forward - especially these days when many are packaged in various installable formats. Even when their not, its pretty bloody straight forward. > A new user should start by learning the keybinding patterns > (C-navigation/M-navigation/C-M-navigation, C-find/C-M-find, etc.) and > a bit of terminology. Later on they can start customizing the > keybindings to suit them. Expecting any more is like taxing the poor > more than the > rich because "the rich people earned their money". > I agree thats exactly what a new user should do. In fact, I've already stated in this thread that new users should refraim from changing anything until after around 6 months use. This is exactly why I don't think the defaults shold be changed - let the new user spend some time learning how emacs is currently configured and its current defaults. Then later, if they don't like them change them - this is how they will get to experience the real benefits - going down the other route of changing the defaults to suit what new users are use to will result in a 'dumbing down' of things and most users will never try the alternative and thererfore will never see the other perspective. Leaving the defaults a they are will expose them to a different approach - if they try it and don't like it, they can change it. > <snip> > >>> 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. > > There would be no benefit to experts. Experts already have gotten > used to Emacs' bindings or have developed workarounds. But there'd be > minimal pain to experts as well -- any expert who would not be able to > add the 12 lines of Emacs Lisp to move the navigation commands back to > f/b/n/p is not really an expert. Emacs could even have > classic-keybindings-mode that uses the old keybindings, so it'd be > only one line to add. > I was referring to developers who want to set defaults to something expected by other emacs users. If you don't have a methodology for doing this, then developers are left to their own devices and we will end up with even less consistency within emacs itself. Something which I've not mentioned so far is how impracticle making these superficial changes would be. One of the main benefits of emacs is the huge wealth of existing packages out there, many of which were written years ago and while still working perfectly, don't actually have a maintainer anymore. How would all of these packages get updated to ensure consistency with this new 'newbie friendly' keybinding approach? > There would be a huge benefit to beginners. A beginner expects the > cua-bindings and gets confused and frustrated when they don't work. > So if it's minimal pain for experts > This is where your mistaken - who said it wold be minimal pain. It would be a *major* pain for the existing user community, which I would argue is probably more valuable to emacs than a few new users who may or may not stick around. It would be a pain for developers as they woldn't know which way to go with defaults and it would be a pain when dealing with older packages which are no longer actively maintained. > <snip> > >>> 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. > > I think Xah is good at raising problems from a end-user point of view. > His solutions are often the wrong fix, but the problems he raises are > almost always valid. Don't ignore his claims just because he swears a > lot and is not interested in debating them. > I've seen many of his claims and I've looked at his web site. He has nothing of worth to offer at any level that I've ever seen. I guess some people are more easily impressed than others. > One of the problems he raised was with the *scratch* buffer. Xah said > "Things emacs need to change for modern world: ... * Get rid of the > *scratch* buffer." While this is not the a helpful description of the > problem with the *scratch* buffer (it doesn't give any rationale), > there are still problems with it. In particular I've encountered the > following problems: > > * It starts in lisp-interaction-mode, which I have never ever used at > program startup. > * Even though the buffer starts out with "This buffer is for notes you > don't want to save", I rarely want to lose any notes I take. > Well, I do a bit of elisp debugging and sometimes just do a very simple fast elisp function for a one off editing task and I find the scratch buffer very useful for that. I also have my emacs running for days and often put little snippets of information/notes in there which I may want to reference later - essentially, I use it like I use to use a whiteboard prior to learning emacs. There is lots of stuff I just want to note temporarily and not clutter up my more permanent notes, Even so, a change to its default mode and possibly even having it save on quit is an insignificant change which I could easily live with. However, I would not agree with Xah's original assertion that it should just be gotten rid of. I also don't understand why, if people don't like it, they don't just ignore it - its not like its using up heaps of resources and it doesn't really cause any problems - use it if you find it useful, ignore it if you don't - whats the big deal. Part of the problem with Xah's rants is he only ever sees things from his own limited experience and always comes to the conclusion that its the software or the operating system which is wrong - there is no evidence of any recognition that his frustrations or difficulties could actually be due to his own narrow experience/opinions/world view. He reminds me of one of those programmers who always jump tot he conclusion that a bug is due to a problem in a library they are using or the OS or due to some weird virus - they look at everything else before recognising the problem is with their own code. More experienced programmers know right away that the odds are extremely high that any bug they encounter is due to their own mistakes or misunderstanding. > Both of these could be easily addressed. Make *scratch* start in > fundamental-mode and with buffer-offer-save=t. That'd take what, 2 > lines of code? > > In fact, I'm gonna do this for just me right now. > Funny, but I think the mode the scratch buffer starts in is controlled by a customize variable - I'm sure in the past it actually use to start in fundamental mode now that I think about it. I'd never really given it any thought and assumed the fact it was now in lisp interaction mode was because I had customized it that way. The fact you can change it so easily still doesn't seem to add much support for any argument to change the current default behavior. However, feel free to put it forward to the gnu development team. As I said, I'm not so worried about what happens to the scratch buffer as long as its not removed. Changing key bindings, well thats a horse of a different colour. tim -- tcross (at) rapttech dot com dot au
From: azubijan on 17 Apr 2006 05:54
Cor Gest wrote: > 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"))) |