the Modernization of Emacs
in [Lisp]
|
From: Fredrik Bulow on 17 Apr 2006 11:05 I think this discussion has gone a bit out of control. Xah is obviously a newbie trying to learn Emacs and while learning he has encountered a few thing that he thought were weird. Since he is a newbie he can't do much about these things himself and therefor he writes down a list with all the "problems" and submits the list to an emacs forum where it will be brought to the attention of people who can actually do something about these problems. Complaining that he doesn't really contribute anything is silly since he can't. I think he did the right thing and that should be encouraged, not punished. Emacs is a niche editor for those who write lots of stuff and are willing to put in the (arguably large) learning effort required because they know it will pay back in the long run. Therefor making it newbie friendly might not be the most important thing. However, I have a feeling that there are lots of emacs conservatives who simply are against all changes. This point of view makes sense when you have a massive emacs knowledge and fear that if emacs changes you will be confused by new key bindings, concept names etc. The viewpoints of these people is motivated by a "fear of loss" and is counter productive. I think it's great that every now and then a complete newbie speaks up and say "these things confuse me" so that more experienced users can be reminded of the newbie perspective when writing mode manuals or implementing new features.
From: M Jared Finder on 17 Apr 2006 12:26 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 > > > >
From: Jay Belanger on 17 Apr 2006 12:52 Fredrik Bulow <kaliumfredrik(a)gmail.com> writes: > I think this discussion has gone a bit out of control. Xah is > obviously a newbie trying to learn Emacs and while learning he has > encountered a few thing that he thought were weird. Xah is not a newbie; he is, in fact, rather proud of being a troll. Jay
From: David Kastrup on 17 Apr 2006 12:57 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. I'd say that is a good thing. Somebody who is incapable of looking into an "Options" menu is not something who is going to be happy with Emacs in the long run. > 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! What do you think the menu entry is for? > That's why I'd expect cua-mode to be enabled by default. Wrong. CUA mode immensively complicates the learning of Emacs since it meddles with keybindings in contorted and hard to understand ways. It is an _expert_ mode for people who have hardwired keyboard reflexes. > That just means every existing user would have to add (cua-mode -1) > to their init file. Is that so insanely difficult? The default of Emacs should be configured for productivity, not some ill-advised pseudo-compatibility. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Greg Menke on 17 Apr 2006 13:27
Its not fear of change that makes the emacs people grumpy, its that none of the "changes" are actual work and instead with very few exceptions can be trivially handled in a user's .emacs file. So the point we're trying to make is that the user is free to set up their emacs however they want. If there are people that think newbies need a bit of help using Emacs (I probably agree), then they are perfectly free to improve the help, market their favorite .emacs or write howto's- there is no-one stopping them. If they choose to contribute nothing more than complaints, then why must they be taken especially seriously? 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 |