From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Xah Newsgroups: gmane.emacs.help Subject: Re: problem with emacs wiki Date: Wed, 11 Jun 2008 01:25:09 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <17c9e6d6-4b78-49ae-b95e-053037b05ef3@a9g2000prl.googlegroups.com> <86fxrk65or.fsf@timbral.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1213174163 8103 80.91.229.12 (11 Jun 2008 08:49:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Jun 2008 08:49:23 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Jun 11 10:50:05 2008 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K6M1g-0004GW-9o for geh-help-gnu-emacs@m.gmane.org; Wed, 11 Jun 2008 10:49:52 +0200 Original-Received: from localhost ([127.0.0.1]:42613 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K6M0s-00080W-Gm for geh-help-gnu-emacs@m.gmane.org; Wed, 11 Jun 2008 04:49:02 -0400 Original-Path: news.stanford.edu!newsfeed.stanford.edu!postnews.google.com!q24g2000prf.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 147 Original-NNTP-Posting-Host: 69.226.234.243 Original-X-Trace: posting.google.com 1213172710 11656 127.0.0.1 (11 Jun 2008 08:25:10 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: Wed, 11 Jun 2008 08:25:10 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: q24g2000prf.googlegroups.com; posting-host=69.226.234.243; posting-account=bRPKjQoAAACxZsR8_VPXCX27T2YcsyMA User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; en) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.1 Safari/525.18, gzip(gfe), gzip(gfe) Original-Xref: news.stanford.edu gnu.emacs.help:159366 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:54723 Archived-At: Hi Evans, Evans Winner 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=C3=B6der; 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 =E2=88=91 http://xahlee.org/ =E2=98=84 On Jun 10, 7:55 pm, Evans Winner wrote: > Xah 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=C3=B6der; 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.