the Modernization of Emacs
in [Lisp]
|
From: roodwriter on 17 Apr 2006 15:14 M Jared Finder <jared(a)hpalace.com> writes: > Again, I had to overzeallously snip. > > My point mainly is: > > I think your overestimating the capabilities of a beginner. I know > from personal experience that not enabling cua-mode by default > severely cuts back on the number of people who use Emacs. It is much > easier for an expert to change their keymap, while it is crazy to > expect a beginner to find out about `cua-mode' -- they're just > learning! That's why I'd expect cua-mode to be enabled by default. > That just means every existing user would have to add (cua-mode -1) to > their init file. Is that so insanely difficult? > > Xah often brings up valid symptoms of actual problems, though his > solution sucks 99% of the time. > > -- MJF > > Tim X wrote: > > M Jared Finder <jared(a)hpalace.com> writes: > >> Tim X wrote: > >>> > >>> 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. > > How does the beginner know about customize? > How does the beginner know where to look in customize? (Remember, > they're a beginner, so they don't know about apropos-variable, or any > of the describe-* functions). > > A beginner should not have to navigate customize early on -- they > don't even understand the technology to know what to search for. How > would they know to find something called `cua-mode'? > > Recent CVS Emacs is much better in this regard. It has a cua-mode > option under the options menu, which is one of the first places I'd > look for such a thing. > > <snip> > > >> 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. > > Again, recent CVS Emacs is much better. It has a keymap <remap> that > allows you to bind commands to wherever existing commands are instead > of actual keys on the keyboard. A mode no longer has to assume the > "standard" keymap and can just set <remap> <find-file> to provide a > replacement to find-file, wherever it is bound to. > > I hope XEmacs copies this feature, as it is gets us 50% of the way to > where the actual keybindings don't matter. > > >> <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. > > I guess. :) > > > > >> 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. > > Because it's the first thing you're presented with. When you run an > application that you think of as a text editor, and it starts up with > an empty text field, is it reasonable to expect people to *not* put > their text there? I don't think so. > > > 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 > > I'm probably the least technically-adept person in here, since I'm a writer, not a programmer (as I've said a million times here). But, while I probably have more sympathy with Xah's position than most here, I don't see any point in changing the keybindings (or even the name keybindings) to CUA by default. Although it was sometimes frustrating, when I was learning Emacs I just accepted the keybindings as they were, reasoning there was some logic behind them that as a beginner I couldn't initially see. Plus, philosophically, any particular keybinding is arbitrary. And, obviously, since one of the big attractions at the time was the prospect of doing everything by keyboard (much more efficient than rodents) I realized keybindings had to be different to accommodate the huge number of commands. It's like trading your car for a George Jetson car. Things will work differently. Accept it. I do partly agree that longlines.el should be the default in text mode, since I use it every day, in place of autofill-mode. But I can't see the reason to make it the default everywhere. Programming is different than writing books and such. Getting rid of the scratch buffer? Why? If you don't use it--and I'm not a lisper--then ignore it. Actually I've learned just enough lisp to make a couple of macros that do some simple adding and subtracting for certain arithmetic problems I encounter every week. So even a writer can find a use for it. I think there is some validity to the argument that long-time users forget the struggles of newbies. I'm thinking that maybe the help files should incorporate right at the beginning suggestions on how to approach Emacs. Not glossing over the differences but explaining why there are differences and that fact makes Emacs the best writing or programming machine around. Explaining that Emacs is not user-unfriendly, even at the beginning, but just different because it has to be. Remember George Jetson's car. Maybe when I've got time some day I'll look into doing that. --Rod ______________________ Author of "Linux for Non-Geeks--Clear-eyed Answers for Practical Consumers" and "Boring Stories from Uncle Rod." To reply by e-mail take the second "o" out of the e-mail address.
From: Tim X on 17 Apr 2006 18:16 M Jared Finder <jared(a)hpalace.com> writes: > Again, I had to overzeallously snip. > > My point mainly is: > > I think your overestimating the capabilities of a beginner. I know > from personal experience that not enabling cua-mode by default > severely cuts back on the number of people who use Emacs. It is much > easier for an expert to change their keymap, while it is crazy to > expect a beginner to find out about `cua-mode' -- they're just > learning! That's why I'd expect cua-mode to be enabled by default. > That just means every existing user would have to add (cua-mode -1) to > their init file. Is that so insanely difficult? > Its not difficult - but my point is that doing so whill mean that new users will never get the chance to experience the productivity gains you can obtain from the existing configuration - they will not move from CUA mode and will not see the potential of the current defaults. and of course there are the other issues I mentioned regarding development and consistency of approaches. Tim -- tcross (at) rapttech dot com dot au
From: Tim X on 17 Apr 2006 18:20 roodwriter(a)core.com writes: > > I think there is some validity to the argument that long-time users > forget the struggles of newbies. I'm thinking that maybe the help > files should incorporate right at the beginning suggestions on how to > approach Emacs. Not glossing over the differences but explaining why > there are differences and that fact makes Emacs the best writing or > programming machine around. Explaining that Emacs is not > user-unfriendly, even at the beginning, but just different because it > has to be. Remember George Jetson's car. > This strikes me as a far more sensible approach to the new user issue (assuming there is an issue). Improved documentation is always a good thing and something all users would benefit from. Finding those with the style and expressive ability to write about technical issues clearly is another matter. Writing for people is *much* more difficult than writing for machines! Tim -- tcross (at) rapttech dot com dot au
From: Dave Vandervies on 17 Apr 2006 22:32 In article <m2ejzx73i7.fsf(a)Dagney.local>, Patrick May <pjm(a)spe.com> wrote: >"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. For what it's worth, as an emacs non-user[1] (I'm reading this in comp.lang.scheme), as soon as I saw `apropos' I had a pretty good idea what the command does. I can't think of any other short name for a command that does the same thing that would also have that property. (Admittedly, that probably has more to do with my knowledge of unix than with my knowledge of the English language, but I didn't have to think too hard about what it meant the first time I encountered it on unix either.) dave (vi user) [1] From what I've heard, emacs is a great desktop environment, but I'm not going to be trying it until they add a good lightweight editor. -- Dave Vandervies dj3vande(a)csclub.uwaterloo.ca I have never seen Hungarian notation used properly by anyone, except in threads discussing Hungarian notation. --Richard Bos in comp.lang.c
From: Fredrik Bulow on 17 Apr 2006 23:32
Greg Menke <gregm-xyzpdq3(a)toadmail.com> writes: > If, instead of complaining, Xah had said- "Look fellow emacs users, I've > always felt the default emacs is a bit of a trial for newbies. Here are > my new .emacs file and a couple new modes to set up Emacs how I think it > should be for newbies- and maybe also for skilled users who prefer this > sort of configuration. Could you please critique it and perhaps help me > lobby for its inclusion in the official distro?", then I think there > would be a much more positive response. Instead he "offers" his > uninformed opinions about how emacs "should" be, basically telling all > the experienced emacs users that their opinions and skills and > preferences are worthless. > > Gregm Alright, the reason I wrote my previous article is that I thought that Xah was a complete newbie and that some serious and un-just "newbie bashing" was done by expert users and that annoyed me. If he's not a newbie, he sould do more creatvie stuff than just complain in newsgroups. If you read my whoe article you see that the remedy I sugest is writing better manuals and keeping newbies in mind when implementing new features. Hardly a complete mess up of emacs! A newbie shouldn't be taken especially seriously but neither should he be punished and insulted for trying to help out; and that is what I thought was happening. Perhaps I missjudged the situation... |