Re: What alternatives are there to learn Emacs?...

Re: What alternatives are there to learn Emacs?...

[Mike Treseler]

Don Saklad wrote:
> What alternatives to the usual manuals are there to learn Emacs?...
> especially for new learners who have difficulties with the
> deficiencies in the usual manual texts and jargon.
> 
> Not all potential new users see themselves as a part of our community!

I started by using the menus.

      -- Mike Treseler

RE: What alternatives are there to learn Emacs?...

[Drew Adams]

> I started by using the menus.

Good suggestion - forgot that one. Menu organization is a great way to discover
features - things that belong together are typically grouped together.

BTW, Icicles can help you to learn Emacs, in several ways.
http://www.emacswiki.org/cgi-bin/wiki/EmacsNewbieWithIcicles

One way is by letting you match menu substrings. That can help you find things
in the menu hierarchy and discover what the hierarchy looks like.
http://www.emacswiki.org/cgi-bin/wiki/IciclesMenu

Re: What alternatives are there to learn Emacs?...

[David Combs]

How about the rms-written tutorial:

  C-h t


David

Re: What alternatives are there to learn Emacs?...

[Xah]

On May 11, 5:47 pm, Don Saklad <dsak...@gnu.org> wrote:
> What alternatives to the usual manuals are there to learn Emacs?...
> especially for new learners who have difficulties with the
> deficiencies in the usual manual texts and jargon.
>
> Not all potential new users see themselves as a part of our community!

you might try my tutorial.
http://xahlee.org/emacs/emacs.html

  Xah
∑ http://xahlee.org/

☄

problem with emacs wiki (was: What alternatives are there to learn Emacs?...)

[Xah]

Some personal experineces on emacs tutorial...

i started to use emacs in 1998. Was a full time user and beta tester
for BBEdit for several years before that.

The first tutorial i read is the bundled tutorial (C-h t, M-x help-
with-tutorial).

This tutorial is the way to get you started with emacs from the ground
up. It in written in 1980's mindset, gets you started to learn all the
emacs ways and terminologies. It is not a practicality oriented one
though.

Once you've read the bundled tutorial, you'll know about info (C-h i)
and how to use its navigation shorcuts, which you can read the whole
one-thousand pages of emacs manual. The emacs manual is a bit quaint
in today, but it is very well written and complete. It is systematic,
topics well organized, jargons are well defined and has several
comprehensive index, the writing is clear, is well cross-linked. The
technology used for the manual, the texinfo, is a excellent technology
at the time. It has hyperlinks preceding its popularity in html by
maybe 10 years. (one can think of it as plain-text system with
hyperlinks and document hierachy/paging and navigation shortcuts) The
writing quality and content of emacs manual, is far better than most
OpenSource docs such as perl, python, apache, unix man.

This only drawback today, in my opinion, is that its largely written
in the 1980s, using terms and jargons that today are not used
elsewhere, verbose, and often has sections that discuss systems that
are obsolete for 20 years.

Sometimes in 1999 i also read “Learning GNU Emacs” (O'Reilly) by Debra
Cameron et al.  This book is more practicality oriented (as with most
commercial tutorials), and it did gave me a good intro.

The book now is out dated though. Last edition, the 2nd ed, published
in 1996. Since then, emacs has gone to version 20, 21, and 22. Lots of
features are added, and lots of new computing technologies have become
important that didn't exist in mid 1990s.

The emacs wiki (http://www.emacswiki.org/), started by Alex Schroeder
sometimes in 2005 or before, is great. However, i think it could've
been better.

(1) The wiki software used is Oddmuse, which is a perl script of 4k
lines, using flat files as database. As such, it is not comprehensive
or powerful.

(2) The content, is kinda haphazard. It is somewhat in-between of a
encyclopedia-style treatment like Wikipedia and a chaotic online
forum. Specifically, when you visit a article, half of article will be
dialogues between different users on tips or issues or preferences.

I commented to Alex about these problems. I suggest that it should use
the same software Wikipedia uses, the MediaWiki. So that, it is far
more powerful, with large scale programer support, and the user
interface for the wiki will be one that's widely known to millions of
users world-wide. (note: Oddmuse is something written by Alex himself,
a petlove of sorts)

I also suggested that the writing guidlines should follow Wikipedia's
style. Specifically, the content editing should be one with the goal
of creating a comprehensive, coherent, article that gives readers info
or tutorial about the subject. (as opposed to, maintaining the
coherence of a dialogue and comments between wiki users)

I think there's a lot potential to emacs wiki. It could, for example,
develope into a comprehensive elisp library archive (e.g. CPAN).
Listing packages by category, wich each package come with a article
that discuss its author, purpose, status, caveats, tutorial, similar
packages ...etc. And the packages needs not just be modes... but
libraries as in most languages. (for example, js2 and nxml modes are
both complete parsers for javascript and xml, each of thousands lines
of elisp code. They should actually be several libraries, so that
these parsers can be widely deployed as language modules for many
purposes. Such is largely not done in emacs/elisp community due to
emacs being primarily a text-editor with relatively few elisp
programers... but is slowing happening anyway (it is something that
eventually must happen). A good wiki can be great help in ushering
necessary improvements)

For the above to take shape, the wiki must adopt a style so that
articles aim to be a coherent treatment of the subject (as opposed to
dialogue and random tips). (and this is done by crafting the
contribution guidelines or rules; examplarily done by Wikipedia) Also,
i'd think the wiki's software should adopt MediaWiki, as opposed to
one-man's petlove.

  Xah
∑ http://xahlee.org/

☄



On Jun 10, 2:43 pm, Xah <xah...@gmail.com> wrote:
> On May 11, 5:47 pm, Don Saklad <dsak...@gnu.org> wrote:
>
> > What alternatives to the usual manuals are there to learn Emacs?...
> > especially for new learners who have difficulties with the
> > deficiencies in the usual manual texts and jargon.
>
> > Not all potential new users see themselves as a part of our community!
>
> you might try my tutorial.http://xahlee.org/emacs/emacs.html
>
>   Xah
> ∑http://xahlee.org/
>
> ☄

Re: problem with emacs wiki (was: What alternatives are there to learn Emacs?...)

[tyler]

Xah <xahlee@gmail.com> writes:

> Sometimes in 1999 i also read “Learning GNU Emacs” (O'Reilly) by Debra
> Cameron et al.  This book is more practicality oriented (as with most
> commercial tutorials), and it did gave me a good intro.
>
> The book now is out dated though. Last edition, the 2nd ed, published
> in 1996. Since then, emacs has gone to version 20, 21, and 22. Lots of
> features are added, and lots of new computing technologies have become
> important that didn't exist in mid 1990s.
>

The latest edition is actually the third edition, published in 2004.
It's excellent.

I started with the built-in tutorial, and I agree with Xah's assessment.
It's the best point of entry. Following that, I read the O'Reilly book,
which is very accessible and provides lots of good practical advice.
After working through the most relevant parts of that book, I was
well-enough prepared to make efficient use of the Emacs manual. Again, I
agree with Xah that the manual is well written and comprehensive, but
there are dark corners that need some work.

Cheers,

Tyler

-- 
Power corrupts. PowerPoint corrupts absolutely.
                                       --Edward Tufte

http://www.wired.com/wired/archive/11.09/ppt2.html

Re: problem with emacs wiki

[Evans Winner]

Xah <xahlee@gmail.com> writes:

    [The Emacs tutorial was] written in 1980's mindset [...]
    It is not [...] practicality oriented[.]

Can you explain exactly what that means?  I live in the
2000's and, though it's been a few years since I went
through the tutorial, I don't recall reading anything that
did not seem clearly focused on the specific and practical
realities of how to use the Emacs editor.  Or is your
criticism really of Emacs itself?

    The emacs manual is a bit quaint in today, but it is
    very well written and complete. It is systematic, topics
    well organized, jargons are well defined and has several
    comprehensive index, the writing is clear, is well
    cross-linked.[...]  The writing quality and content of
    emacs manual, is far better than most OpenSource docs
    such as perl, python, apache, unix man.

What precisely do you mean by the term ``quaint?''  Given
your own description, ``quaint'' does not seem the
appropriate term.  Terms like ``intelligent'' and
``professional'' leap to mind instead.  I have found the
Emacs documentation and its integration and availability or
``discoverability'' the best of any computer system, program
or programming language I have ever dealt with.

    The wiki software used is Oddmuse [on EmacsWIki], which
    is a perl script of 4k lines, using flat files as
    database. As such, it is not comprehensive or powerful.

I don't know much about wiki software.  What kind of
features are you missing specifically?  You mentioned
discussing this with Alex Schröder; what did he say about
your suggestions? 

    I also suggested that the writing guidlines should
    follow Wikipedia's style. Specifically, the content
    editing should be one with the goal of creating a
    comprehensive, coherent, article that gives readers info
    or tutorial about the subject. (as opposed to,
    maintaining the coherence of a dialogue and comments
    between wiki users)

Guidelines such as those used by Wikipedia might have some
positive effect on the content that is added to the wiki,
however Wikipedia has the key to really making something
like that work: an army of busybodies ready to enforce the
guidelines.  EmacsWiki (I suspect) does not have such
resources.  It is arguable that strict guidelines on
EmacsWiki would have a dampening effect on the frequency of
contributions, which I would guess is not the goal of its
maintainers.  In some contexts a slightly anarchic and
disorganized something is better than a tightly organized
nothing.

Re: problem with emacs wiki

[Xah]

Hi Evans,

Evans Winner <tho...@timbral.net> wrote:
>     [The Emacs tutorial was] written in 1980's mindset [...]
>     It is not [...] practicality oriented[.]
>
> Can you explain exactly what that means?

Xah wrote:
>     The emacs manual is a bit quaint in today, but it is
>     very well written and complete. It is systematic, topics
>     well organized, jargons are well defined and has several
>     comprehensive index, the writing is clear, is well
>     cross-linked.[...]  The writing quality and content of
>     emacs manual, is far better than most OpenSource docs
>     such as perl, python, apache, unix man.

Evan wrote:
> What precisely do you mean by the term ``quaint?''  Given
> your own description, ``quaint'' does not seem the
> appropriate term.  Terms like ``intelligent'' and
> ``professional'' leap to mind instead.  I have found the
> Emacs documentation and its integration and availability or
> ``discoverability'' the best of any computer system, program
> or programming language I have ever dealt with.

I agree it's best, but i think it could still use some improvements to
reduce its size by perhaps 30% while maintaining the exact same
quality without losing any info.

I wrote some about this issue recently in comp.emacs, now archived
here:

http://xahlee.org/emacs/emacs_manual_problem.html

It's a bit long (1k words) so i won't paste here. Feel free to quote.
In anycase, i don't think it's a critical issue. I think changing some
of emacs's interface is more critical ... (pls see
http://xahlee.org/emacs/modernization.html )

> I don't know much about wiki software.  What kind of
> features are you missing specifically?

MediaWik, the one used by Wikipedia, has huge programer support,
massive features, extensibility, scalability, and with interface
familiar to millions of users. It was developed by a team of
programers with several rewrites and overhaul ...

See
http://en.wikipedia.org/wiki/MediaWiki
http://en.wikipedia.org/wiki/Oddmuse

> Guidelines such as those used by Wikipedia might have some
> positive effect on the content that is added to the wiki,
> however Wikipedia has the key to really making something
> like that work: an army of busybodies ready to enforce the
> guidelines.  EmacsWiki (I suspect) does not have such
> resources.  It is arguable that strict guidelines on
> EmacsWiki would have a dampening effect on the frequency of
> contributions, which I would guess is not the goal of its
> maintainers.  In some contexts a slightly anarchic and
> disorganized something is better than a tightly organized
> nothing.

Yeah you are right.

> You mentioned
> discussing this with Alex Schröder; what did he say about
> your suggestions?

I don't think Alex thought much of my suggestions.

Changing emacs wiki on the software and the philosophy of its article
writting is important though, because a wiki when done right, serves a
very important social function that can potentially change the entire
community and social habits. (one possible outcome i suggested is the
creaetion of a elisp database that urshers elisp code from being just
a emacs mode to a library of programing modules)

(Wikipedia itself, its social importance, probably rank top 50 of all
things and inventions that happened this century, with respect the
impact on of human society.)

  Xah
∑ http://xahlee.org/

☄

On Jun 10, 7:55 pm, Evans Winner <tho...@timbral.net> wrote:
> Xah<xah...@gmail.com> writes:
>
>     [The Emacs tutorial was] written in 1980's mindset [...]
>     It is not [...] practicality oriented[.]
>
> Can you explain exactly what that means?  I live in the
> 2000's and, though it's been a few years since I went
> through the tutorial, I don't recall reading anything that
> did not seem clearly focused on the specific and practical
> realities of how to use the Emacs editor.  Or is your
> criticism really of Emacs itself?
>
>     The emacs manual is a bit quaint in today, but it is
>     very well written and complete. It is systematic, topics
>     well organized, jargons are well defined and has several
>     comprehensive index, the writing is clear, is well
>     cross-linked.[...]  The writing quality and content of
>     emacs manual, is far better than most OpenSource docs
>     such as perl, python, apache, unix man.
>
> What precisely do you mean by the term ``quaint?''  Given
> your own description, ``quaint'' does not seem the
> appropriate term.  Terms like ``intelligent'' and
> ``professional'' leap to mind instead.  I have found the
> Emacs documentation and its integration and availability or
> ``discoverability'' the best of any computer system, program
> or programming language I have ever dealt with.
>
>     The wiki software used is Oddmuse [on EmacsWIki], which
>     is a perl script of 4k lines, using flat files as
>     database. As such, it is not comprehensive or powerful.
>
> I don't know much about wiki software.  What kind of
> features are you missing specifically?  You mentioned
> discussing this with Alex Schröder; what did he say about
> your suggestions?
>
>     I also suggested that the writing guidlines should
>     follow Wikipedia's style. Specifically, the content
>     editing should be one with the goal of creating a
>     comprehensive, coherent, article that gives readers info
>     or tutorial about the subject. (as opposed to,
>     maintaining the coherence of a dialogue and comments
>     between wiki users)
>
> Guidelines such as those used by Wikipedia might have some
> positive effect on the content that is added to the wiki,
> however Wikipedia has the key to really making something
> like that work: an army of busybodies ready to enforce the
> guidelines.  EmacsWiki (I suspect) does not have such
> resources.  It is arguable that strict guidelines on
> EmacsWiki would have a dampening effect on the frequency of
> contributions, which I would guess is not the goal of its
> maintainers.  In some contexts a slightly anarchic and
> disorganized something is better than a tightly organized
> nothing.