[Top][All Lists]
[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.
- RE: [h-e-w] EmacsW32, gnuserv, pathes in .emacs, (continued)
- RE: [h-e-w] EmacsW32, gnuserv, pathes in .emacs, Drew Adams, 2006/07/07
- Re: AW: [h-e-w] EmacsW32, gnuserv, pathes in .emacs, Eli Zaretskii, 2006/07/08
- Re: [h-e-w] EmacsW32, gnuserv, pathes in .emacs, Alessandro Vesely, 2006/07/10
- [h-e-w] jump hi-lock next/previous position, Pang.Ding-Hai, 2006/07/10
- Re: [h-e-w] EmacsW32, gnuserv, pathes in .emacs, Eli Zaretskii, 2006/07/10
- RE: [h-e-w] EmacsW32, gnuserv, pathes in .emacs, Drew Adams, 2006/07/10
- Re: [h-e-w] EmacsW32, gnuserv, pathes in .emacs, Eli Zaretskii, 2006/07/10
- RE: [h-e-w] EmacsW32, gnuserv, pathes in .emacs, Drew Adams, 2006/07/11
- AW: [h-e-w] EmacsW32, gnuserv, pathes in .emacs,
C.Strobl <=
- Re: AW: [h-e-w] EmacsW32, gnuserv, pathes in .emacs, Eli Zaretskii, 2006/07/11
- RE: [h-e-w] EmacsW32, gnuserv, pathes in .emacs, Nat Goodspeed, 2006/07/11
- RE: [h-e-w] EmacsW32, gnuserv, pathes in .emacs, Drew Adams, 2006/07/11
- RE: [h-e-w] EmacsW32, gnuserv, pathes in .emacs, Stephen F. Heffner, 2006/07/11
- RE: [h-e-w] EmacsW32, gnuserv, pathes in .emacs, Drew Adams, 2006/07/11
- RE: [h-e-w] EmacsW32, gnuserv, pathes in .emacs, Nat Goodspeed, 2006/07/13
- RE: [h-e-w] EmacsW32, gnuserv, pathes in .emacs, Drew Adams, 2006/07/13
- RE: [h-e-w] EmacsW32, gnuserv, pathes in .emacs, Nat Goodspeed, 2006/07/13
- RE: [h-e-w] EmacsW32, gnuserv, pathes in .emacs, Stephen F. Heffner, 2006/07/13
- Re: [h-e-w] EmacsW32, gnuserv, pathes in .emacs, Eli Zaretskii, 2006/07/11