From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/35512 Path: main.gmane.org!not-for-mail From: Karl Kleinpaste Newsgroups: gmane.emacs.gnus.general Subject: Re: Wizards (was: Re: Oort Version) Date: 28 Mar 2001 09:47:12 -0500 Message-ID: References: <763dc0s6d0.fsf@newjersey.ppllc.com> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035171244 3481 80.91.224.250 (21 Oct 2002 03:34:04 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 03:34:04 +0000 (UTC) Keywords: gnus,emacs,bbdb,start,code,require,ignore-errors,fsf Return-Path: Original-Received: (qmail 16692 invoked by alias); 28 Mar 2001 14:47:17 -0000 Original-Received: (qmail 16687 invoked from network); 28 Mar 2001 14:47:15 -0000 Original-Received: from mesquite.slip.cs.cmu.edu (HELO cinnamon.vanillaknot.com) (128.2.207.11) by gnus.org with SMTP; 28 Mar 2001 14:47:15 -0000 Original-Received: (from karl@localhost) by cinnamon.vanillaknot.com (8.9.3/8.9.3) id JAA23696; Wed, 28 Mar 2001 09:47:12 -0500 Original-To: ding@gnus.org X-Face: "5(T0tZd{6}pd~YzBG8O/*EW,.]6]@`m^e;fv65W^Y&=d"M\1H}>T~4_.kcDD.O~y3k)a6 hR;Nmi>9|>Nm${2IpM0^RcUEa\jcq?KOP)C&~x51l~zCHTulL^_T|u0I^kB'z@]{`2YjQu In-Reply-To: (Per Abrahamsen's message of "28 Mar 2001 15:59:44 +0200") User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Urania) Original-Lines: 57 Xref: main.gmane.org gmane.emacs.gnus.general:35512 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:35512 Per Abrahamsen writes: > A couple of years ago I did some prelimenary work on integrating > customize with w3, which should allow for the creation of wizards that > guide users through customization. Unfortunately I didn't get as far > as creating a good example, and the code has likely suffered bit-rot > since. Do you still have the code? It would be worth looking at today. Rot can be cut out. >> - Prepackaged, selectable nnmail-split-rules entries to do "obvious" > That sound interesting, it may even being doable now with the : rules. Do you mean by using a long (contorted?) list of alternate selectors? That could get really hairy, I would think. But it would be good for a first pass. > A problem is that BBDB is FSF code, which makes it problematic to ( s/is/isn't/ ?) > depend on it in a FSF project like Gnus. I sometimes fantasize about > writting a LBDB for FSF just to have the functionality present always. So let's provide BBDB auto-graft iff we detect that BBDB is available. Can "require" be wrapped inside "ignore-errors"? (if (ignore-errors (require 'bbdb)) ( ... do whatever it takes to be able to auto-graft on request ... )) I don't know if this is the right elisp idiom for such a purpose, but my goal is to try to pull in BBDB, and if it succeeds ("ignore-errors" returns nil if its contained forms fail; and I assume "require" returns something other than nil when it successfully finds the feature or loads the file), then make Gnus available for graft assist. > Kyle Jones apparently have some very good code for VM which could be > rewritten for Gnus. I wish I had any experience using VM, but I've never once invoked it except by accident. > Splitting the file for automatic customization further adds > complexity without any measurable benefits. Having thought it through a bit more, I agree with you. But how does this interact with users who run >1 simultaneous Emacs? Start an Emacs, run Gnus in it. Start 2nd Emacs. Customize Gnus in 1st Emacs. Exit Gnus from 1st Emacs. Start Gnus in 2nd Emacs. The advantage of .gnus is that it is loaded with every start of Gnus. If we bury customizations in the usual auto-customize file, fresh invocations of Gnus in a new Emacs don't get needed stuff picked up, and induce another nightmare for the confused new user.