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

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

Re: problem with emacs wiki


From: Xah
Subject: Re: problem with emacs wiki
Date: Wed, 11 Jun 2008 01:25:09 -0700 (PDT)
User-agent: G2/1.0

Hi Evans,

Evans Winner <address@hidden> 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 <address@hidden> wrote:
> Xah<address@hidden> 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.




reply via email to

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