From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "David A. Cobb" Newsgroups: gmane.emacs.xemacs.beta,gmane.emacs.devel Subject: Re: Emacs setup assistants Date: Fri, 28 May 2004 21:26:35 -0400 Sender: xemacs-beta-admin@xemacs.org Message-ID: <40B7E6CB.30602@cox.net> References: <87zn847n6a.fsf@mail.jurta.org> Reply-To: Superbiskit@cox.net, xemacs-beta@xemacs.org, emacs-devel@gnu.org NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------020200000201090605030700" X-Trace: sea.gmane.org 1085794202 8529 80.91.224.253 (29 May 2004 01:30:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 29 May 2004 01:30:02 +0000 (UTC) Cc: David Kastrup , juri@jurta.org Original-X-From: xemacs-beta-admin@xemacs.org Sat May 29 03:29:54 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BTsfZ-0007PO-00 for ; Sat, 29 May 2004 03:29:54 +0200 Original-Received: from gwyn.tux.org ([199.184.165.135]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BTsfY-00073O-00 for ; Sat, 29 May 2004 03:29:53 +0200 Original-Received: from gwyn.tux.org (localhost.localdomain [127.0.0.1]) by gwyn.tux.org (8.11.6p2/8.9.1) with ESMTP id i4T1R2o11926; Fri, 28 May 2004 21:27:02 -0400 Original-Received: (from turnbull@localhost) by gwyn.tux.org (8.11.6p2/8.9.1) id i4T1Q6X11316 for xemacs-beta-mailman@xemacs.org; Fri, 28 May 2004 21:26:06 -0400 Original-Received: (from mail@localhost) by gwyn.tux.org (8.11.6p2/8.9.1) id i4T1Q4111298 for turnbull@tux.org; Fri, 28 May 2004 21:26:04 -0400 Original-Received: from lakermmtao02.cox.net (lakermmtao02.cox.net [68.230.240.37]) by gwyn.tux.org (8.11.6p2/8.9.1) with ESMTP id i4T1Pxo11239 for ; Fri, 28 May 2004 21:25:59 -0400 Original-Received: from [192.168.1.101] (really [68.224.196.240]) by lakermmtao02.cox.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20040529012557.GPAS19971.lakermmtao02.cox.net@[192.168.1.101]>; Fri, 28 May 2004 21:25:57 -0400 User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040525) X-Accept-Language: en-us, en Original-To: Eli Zaretskii , xemacs-beta@xemacs.org, emacs-devel@gnu.org In-Reply-To: X-XEmacs-List: beta Errors-To: xemacs-beta-admin@xemacs.org X-BeenThere: xemacs-beta@xemacs.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: XEmacs Beta Testers List-Unsubscribe: , Xref: main.gmane.org gmane.emacs.xemacs.beta:14887 gmane.emacs.devel:24102 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:24102 This is a multi-part message in MIME format. --------------020200000201090605030700 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sorry for jumping into a discussion so late. It's not like I know anything. Eli Zaretskii wrote: >>From: David Kastrup >>Date: 20 May 2004 12:57:11 +0200 >> >> >> >>>A tool such as the one being discussed needs mostly small chinks of >>>plain text interspersed with hyperlinks, something for which >>>Customize (and indeed even Help functions) already have the >>>necessary infrastructure, or at least large parts of it. >>> >>> >>Small? No. An assistant has to _explain_ things, and the ways in >>which they are related. >> >> > >In my experience, long explanations are never read. People nowadays >seem to have no patience for that. That's why tutorials for setting >up software are out and FAQs are in. > > They also require a modicum of literacy to write. > > >>Isolated customization strings don't do that. >> >> > >I didn't say isolated strings. Writing a 10-sentence explanation for >a specific aspect of something doesn't require something as elaborate >as Texinfo. > > I would really hate to see the information separated physically from the code! That's a guarantee one of them will be wrong. Having gotten the negative stuff out of the way, however; I thing better formatting capabilities for DOC strings would be great - as would some form of internationalization. A "pre-processor" like JavaDoc might be very cool. Of course, I am not at this time volunteering! To say that @code{custom} needs work is almost a tautology. But most intelligent folk are rather afraid of it, it seems. Where it does not exist today, there should probably be a "setup" section for each @code{info} topic. Now, a corellation between that text and the related customization settings code -- think "link" like a Note: -- that would be nice too! > > >>You don't get a coherent explanation and layout of what to do in what >>order and what influences what. You get a twisty little maze of >>crosslinks with pieces of information scattered around, and the >>coherent ideas of the design having no place to be sitting. >> >> > >The, IMHO, challenge is to organize those pieces of information in a >way that in every specific case we only display the text that explains >what the user currently cares about. For example, when I need to set >up a port for some service, I don't want to hear a lecture about >TCP/IP and ports in general, just clear and practical suggestions for >coming up with the port number for that specific service. > > > >>That's not what an assistant is supposed to do: an assistant is >>concerned with setting up a package, not with customizing a single >>variable once you have found out that you might want to customize >>_that_ variable. >> >> > <> > Again, the challenge IMHO is to break a complex issue into a sequence > of well-defined short help messages, and a framework that guides the > user thru that sequence. No one will ever read a 10-page explanation > just to set up a package (well, perhaps except you and me). -- <>David A. Cobb, Software Engineer, Public Access Advocate <><>"By God's Grace, I am a Christian man; by my actions a great sinner." -- The Way of a Pilgrim: R.French, Tr. <>Life is too short to tolerate crappy software! <> --------------020200000201090605030700 Content-Type: text/x-vcard; charset=utf-8; name="Superbiskit.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Superbiskit.vcf" begin:vcard fn:David A. Cobb n:Cobb;David A. adr:;;7 Lenox Av #1;West Warwick;RI;02893-3918;USA email;internet:Superbiskit@cox.net title:Independent Software Consultant note:PGP Key ID#0x4C293929 effective 01/28/2004 x-mozilla-html:TRUE version:2.1 end:vcard --------------020200000201090605030700--