help-emacs-windows
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AW: [h-e-w] EmacsW32, gnuserv, pathes in .emacs


From: C.Strobl
Subject: AW: [h-e-w] EmacsW32, gnuserv, pathes in .emacs
Date: Tue, 11 Jul 2006 10:49:51 +0200

hello all,

once again, i think the emacs-help-system is very good and everybody who knews 
a little bit about emacs, like me now, can find there everything what he need. 
but the emcas-help is an integrated part of emacs ant thats exactly the problem 
of a newbie. it's a little bit like learning chinese with a book completely 
written with chinese signs.
for a beginner it would be much more easy to get a pdf-file, maybe 50 pages, 
with the most important steps and commands. in this pdf-file you can also write 
the best starting point for emacs is the tutorial. after a while ist easy to 
move and search with emacs but it's difficult to read a text-file with a 
software which is explained by the textfile you read.

again, a short pdf-file with the following points would be very helpfull for a 
really beginner. a beginner who doesn't know about emacs really nothing.

1) installation and configuration (for me especially with windows)
2) simple emacs-commandos like described in the tutorial in the emacs help menu
3) more extensivly examples for typical editing tasks like search and replace, 
copy and paste, rectangle editing, ...and so on. only with examples newbies can 
see the possibilities of emacs
4) a few word about the .emacs file and customization
5) a glossary with the special emacs terms


it's a little bit like the book which was recommended by vincent:

The solution I went for was to buy Learning GNU Emacs 3rd Edition, Cameron et 
al, pub O'Reilly.
ISBN 0-596-00648-9

but with much less content. for the first activation energy to climb the 
emacs-hill. i think the activation energy you have to invest is much bigger for 
using emacs than for a comparable tool if a comparable tool exists at all.

greetings from munich
christian

p.s. i think the emacs hill for windows user is still steeper. i installed the 
windows-binaries from the gnu-page. there was no toolbar available for me, also 
no copy, paste, ... so the emacsW32 is a really important project for windows 
users, especially for beginners. but also linux users have beginning problems. 
i tested emacs also with open suse 10.0. there was no gnuserve available so 
that it starts for every .txt-file a new emacs-instance. i know the right way 
is to open files with c-x c-f or the dired and so on. but for a new user ist 
often much simpler to click at an file or to use the context-menu. also the 
interaction between the kill-ring and the clipboard is with linux more 
complicated, at least for me.



-----Ursprüngliche Nachricht-----
Von: address@hidden [mailto:address@hidden Im Auftrag von Drew Adams
Gesendet: Dienstag, 11. Juli 2006 07:43
An: address@hidden
Betreff: RE: [h-e-w] EmacsW32, gnuserv, pathes in .emacs

    > Perhaps a modular suite of short (mini) tutorials? That is,
    > a long tutorial could be tackled more easily in several
    > learning sessions and in smaller bites. You could go
    > directly to "Lesson 3, Incremental Search" or whatever,
    > if you wanted. With an outline at the top (or left) that
    > helps you find your way around the main tutorial topics,
    > that could be an improvement.

    There's nothing in the current tutorial that prevents users
    from reading it in chunks.  The Tutorial is divided into
    sections, so a user could leave after reading some of them,
    then return to where she left off.

Sorry. As I said, it's been 20 years since I used the tutorial.

If it's easy to reenter and pick up where you left off, easy to explore or not 
explore different branches, and branches are easily recognized (identified), 
then I don't see why anyone would complain about it being long. In that case, 
it's only as long as you follow it.

    The important thing is that new users should read the Tutorial
    in its entirety (but not necessarily in one go), because
    otherwise they will lack important information.  I don't know
    how to force people to do that.

Not necessarily in one go - yes! And yes, I'm sure that everything there is 
useful.

    While adding some menu or tree-like structure to the Tutorial
    is a good idea, it still cannot solve the problem of people
    who are too impatient to finish their reading before they
    start working.

Correct. There's nothing to be done with the impatient. That's OK. Let them 
play - they'll discover it all soon enough. (Though they might try *our* 
patience with impetuous questions...)

    It is okay to skip the Tutorial, but then the user should
    invest lots of time reading the manual (which does have
    structure).

The (excellent) manual is more of a reference manual than a user guide. I do 
agree that everyone (including Theuser) would do well to invest lots of time in 
it - it's a mine of interesting stuff. Print it out and park it next to the 
toilet or your bed - read something new each day. By the time you will have 
finished the last page, Emacs 22 will be out, and you can print a new 
edition... This is what life is all about - Zippy knew that. It doesn't get any 
better than this.

It's also good to have something like a tutorial that holds you by the hand and 
guides you. People learn in different ways. A tutorial can help many people. 
I'm sure we all agree on this.

    > In general, anything we think Emacs users need to use often
    > should be at least pointed out in the tutorial.

    That would make the Tutorial impossibly long.  There's too
    much to tell.

It would be impossibly long only if you stick to the idea that "new users 
should read the Tutorial in its entirety."  An expanded tutorial that points 
out the most important areas to explore first would no longer fit that strict 
prescription. Such an expanded tutorial would be a superset of the current 
tutorial, in terms of content. It would be an Adventure game with many more 
caves and rooms, that's all.

The key requirement would be to somehow point out clearly which are the things 
you really should learn first - distinguishing those from other interesting 
things to learn, which are not so essential. Make it clear to users - label the 
routes (like ski slopes?).

    > The emphasis in the tutorial (IIRC - it's
    > been twenty years since I've used it) is on text editing,
    > which is fine, but how to get help and how to customize
    > Emacs (that is, how to set preferences)
    > are also important for general use.

    The philosophy is that the default Emacs should
    work well enough for the new user not to be
    bothered by customization for quite some time.

It's not a question of bother. Setting preferences in most UI applications is 
not something users do only exceptionally and only because they are bothered. 
This is all the more true of Emacs customization. Customization is a part of 
normal Emacs use even more than it is part of the use of other apps. Emacs *is* 
customization, in oh so many ways. Do you want to customize? Get Emacs. It 
doesn't matter what - you can customize anything with Emacs.

If you're not customizing, then you are not emacsing. You may be editing, you 
may be writing code, you may be reading mail, but you're not emacsing - until 
you customize. Sorry, but that's a law of nature.

I have never, ever, ever seen anyone use Emacs as is, out of the box. Do you 
use only emacs -q? I'd be willing to bet on that one.

That doesn't mean that Emacs isn't adequate out of the box. It's not missing 
any screws. The Emacs package you get with the distribution is the best Emacs 
package to distribute: it is the lowest common denominator, in many ways, but 
it also represents wise design choices, including UI choices. But people like 
to tinker, and they have different tastes, including bad taste sometimes. 
Nothing to be done...

Have you ever seen people discussing a UI - no matter what it is? They never 
agree about anything. One wants the text larger, the other smaller. One wants 
dark on light for readability; the other wants neon on black with metalic 
borders and heavy metal surround-sound.

Customization is *not* about "bother"; it's about individual preference - look 
& feel. You like a small dog; I like a large dog; that guy likes a watchdog. 
Customized UIs are like dogs: there are 80 frillion kinds of dog because people 
just like different things.

Look at the multitudes who customize their cars, be it subtly or garrishly.
Look at the zillions of people, even in far-flung villages in the mountains of 
Asia, who dress up their cell phones with all kinds of fancy doo-dads.
Look at the untold masses who download themes, wallpaper, screensavers, and 
such for their desktops.

Think of skins - who thinks that skins are about "bother"?  [the philosophy is 
that the default should work well enough for the new user not to be bothered by 
the need for a skin for quite some time  - huh?]

People like to play and make themselves at home in an application - especially 
one like Emacs. Customization is *not* about "bother"; it is about nesting.

Honestly, we're gonna have to send you back for regrooving, Eli - make you sit 
through the 6000-node tutorial on "Preferences, What They're All About", and 
then write an essay on "How I Learned to Love Preferences". If you prefer, you 
can sit through an animated PowerPoint presentation on "I Prefer, You Prefer, 
We All Prefer". But if you _prefer_ either that or the tutorial, then, well, 
you're already on the road to recovery.

    If that is far from reality, let's hear why.  Perhaps some
    defaults need to be changed, or perhaps Emacs should do
    something automatically that it doesn't.

    > I suspect the problem is not the overall size, but the fact
    > that it is not in bite-size pieces - you need to digest it
    > all at once. You cannot easily follow the tutorial for 10
    > minutes each day - you cannot easily pick up
    > where you left off.

    I don't see why this would be impossible.  Please explain.

My bad, no doubt. Bad memory, in particular.








reply via email to

[Prev in Thread] Current Thread [Next in Thread]