From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel,gmane.emacs.xemacs.beta Subject: Re: Emacs setup assistants Date: Thu, 20 May 2004 15:07:35 -0400 Organization: =?us-ascii?Q?=3D=3Fkoi8-r=3Fq=3F=3DF4=3DC5=3DCF=3DC4=3D?= =?us-ascii?Q?CF=3DD2=3D20=3DFA=3DCC=3DC1=3DD4=3DC1=3DCE=3DCF=3DD7=3F?= =?us-ascii?Q?=3D_=40_Cienfuegos?= Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <4nd64y29zc.fsf@lifelogs.com> References: <87zn847n6a.fsf@mail.jurta.org> <1438-Thu20May2004203119+0300-eliz@gnu.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1085089396 6909 80.91.224.253 (20 May 2004 21:43:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 20 May 2004 21:43:16 +0000 (UTC) Cc: xemacs-beta@xemacs.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu May 20 23:43:09 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 1BQvJl-0004jk-00 for ; Thu, 20 May 2004 23:43:09 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BQvJl-0001d7-00 for ; Thu, 20 May 2004 23:43:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BQvBn-00089r-KI for emacs-devel@quimby.gnus.org; Thu, 20 May 2004 17:34:55 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BQtgq-0001b6-Vn for emacs-devel@gnu.org; Thu, 20 May 2004 15:58:53 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BQtLs-0005Eo-Es for emacs-devel@gnu.org; Thu, 20 May 2004 15:37:55 -0400 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BQt9L-00026i-0M for emacs-devel@gnu.org; Thu, 20 May 2004 15:24:15 -0400 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BQt9K-0007Mc-00 for ; Thu, 20 May 2004 21:24:14 +0200 Original-Received: from asimov.bwh.harvard.edu ([134.174.9.63]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 May 2004 21:24:14 +0200 Original-Received: from tzz by asimov.bwh.harvard.edu with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 May 2004 21:24:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 62 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: asimov.bwh.harvard.edu X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:kL+6BJmlhsJ9I0ko9qR0/piyjUM= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:23801 gmane.emacs.xemacs.beta:14778 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23801 On Thu, 20 May 2004, eliz@gnu.org wrote: > It would probably make sense to use some kind of outline mode in such > a buffer, whereby the user first sees only an outline of the > customization process (like one line per step); clicking on that line > would then reveal the details of that step. You're thinking like a programmer and/or power user :) Normal users rarely appreciate this sort of view of the wizard sequence. I think that for usability and simplicity, only the Next/Previous/Cancel buttons should be allowed for navigation. When Next can lead to multiple choices because the assistant nodes are a tree instead of straight line, Next should do a depth-first traversal in a consistent way (maybe alphabetically following nodes on the same level). The point is, give the user the illusion of a straight decision line that they can use back and forth consistently. I'm not advocating that we copy a certain GUI, only that users will be more comfortable if we confuse them less. > Other buttons or links could lead to advanced customization options > and in-depth descriptions for those who want that. That's a good idea, but it should be clearly separated from the regular assistant. Maybe @assistantadvanced tags should be used to surround such options, and the user can show or hide them. > In short, I'm talking about specialized interactive tutorial, and it > seemed to me that Customize, if appropriately enhanced and augmented, > could do the job. But even if not, I don't see why an infrastructure > for such a feature could not have some other Lispy foundation, rather > than a Texinfo foundation. I absolutely agree Customize could be useful. So far in my experiments to find a useful syntax, I have been doing something like this: @ifassistant @node Hello, choose a server @variable server :string "default.server.com" @text You can define the server: @variable{server} @end text @next (string-match ".com" server) "Set up a .com server" @next (string-match ".org" server) "Set up a .org server" @end ifassistant and I think the Customize widgetry would fit perfectly inside the text buffer. I don't think the regular Customize interface, with all its text and extra options, will be right, this needs to be a more lightweight version of the Customize interface. Ted