From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Ok, I have had it. A proposal for wizards. Date: 02 Jan 2004 04:28:42 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1073016345 23595 80.91.224.253 (2 Jan 2004 04:05:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 2 Jan 2004 04:05:45 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Jan 02 05:05:43 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 1AcGZD-0001MW-00 for ; Fri, 02 Jan 2004 05:05:43 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AcGZC-0004Qv-00 for ; Fri, 02 Jan 2004 05:05:42 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AcHUx-0004XK-TG for emacs-devel@quimby.gnus.org; Fri, 02 Jan 2004 00:05:23 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AcHUs-0004V6-B8 for emacs-devel@gnu.org; Fri, 02 Jan 2004 00:05:18 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AcHUL-0004FP-FP for emacs-devel@gnu.org; Fri, 02 Jan 2004 00:05:16 -0500 Original-Received: from [217.80.160.93] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AcHUK-0004FJ-PU for emacs-devel@gnu.org; Fri, 02 Jan 2004 00:04:45 -0500 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i0243Fws011190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 Jan 2004 05:03:15 +0100 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i023Shx2011006; Fri, 2 Jan 2004 04:28:43 +0100 Original-To: emacs-devel@gnu.org Original-Lines: 46 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 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:18951 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18951 Emacs comes bundled with a whole lot of packages that are not loaded by default. The typical scene when somebody complains to a guru "it would be so convenient if Emacs could do such-and-such" is "well, have you enabled/configured this-and-that?" -- blank stare. So what to do about that? Wizards. A wizard is a human-friendly walk-through through some configuration issue. A package registers for wizards in manner similar to autoload cookies (we usually want neither the package nor its wizard loaded unless the user is actually going to configure anything), and it will usually register for a major mode instead of a function call. Now we get a "wizard" menu with unexamined goodies highlighted, and a conditional magic wand toolbar button that appears whenever any goody for the current major mode has not yet been examined. The autoload cookie-like thing will be enough to provide a title line such as RefTeX Manage Crossreferences, Indexes and tocs in TeX modes [Mark as Seen] [Configure] [Info] When I press [Mark as Seen], this means the obvious thing (it will register the fact in a customized variable or something). When I press [Info], I get the manual, when I press [Configure], I enter a dialog with explanations of what the stuff does and Yes/No questions and the most important customizable variables. This dialog will obviously be stored in a file of its own so as to be only loaded when needed (usually once per user). When new packages get installed side-wide, appropriate wizard entries would want to get added in order to notify the users that new features are available. I mean, take a look alone at the minibuffer-related modes: we have oodles of useful things like iswitchb-mode, file-name-shadow-mode, minibuffer-electric-default-mode and so on. Nobody ever uses them because nobody knows about them. And would have to read info pages in order to find out more, and follow the instructions in each of those different files for switching the feature on, and so forth and so on. Too much trouble. Advanced modes (like AUCTeX or cperl-mode or so) would register their wizards also in the modes they are supposed to supplant. That way people would be notified if superior or different alternatives were available. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum