From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/6016 Path: main.gmane.org!not-for-mail From: Hallvard B Furuseth Newsgroups: gmane.emacs.gnus.general Subject: Re: on Good Net-Keeping Seal Date: Mon, 22 Apr 1996 09:50:35 +0200 (MET DST) Message-ID: <199604220750.JAA04144@bombur2.uio.no> References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035146535 2219 80.91.224.250 (20 Oct 2002 20:42:15 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:42:15 +0000 (UTC) Cc: ding@ifi.uio.no Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.5/8.6.9) with SMTP id BAA02554 for ; Mon, 22 Apr 1996 01:24:39 -0700 Original-Received: from goggins.uio.no (6089@goggins.uio.no [129.240.201.2]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id ; Mon, 22 Apr 1996 09:50:38 +0200 Original-Received: from ulrik.uio.no by goggins.uio.no with local-SMTP (PP) id <29398-0@goggins.uio.no>; Mon, 22 Apr 1996 09:50:36 +0200 Original-Received: by bombur2.uio.no ; Mon, 22 Apr 1996 09:50:35 +0200 (MET DST) Original-To: Lars Magne Ingebrigtsen In-reply-to: Xref: main.gmane.org gmane.emacs.gnus.general:6016 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:6016 Lars Magne Ingebrigtsen writes: > Hallvard B Furuseth writes: > >> - Strive for a distinction between between "novice" and "expert" config >> variables. It should be difficult or impossible to diddle a "novice" >> config variable so that Gnus can post illegal articles. > > Isn't that something that's rather difficult to achieve? Yes, that's why I didn't use a stronger expression than 'strive for'. > `(setq user-mail-address "god@heaven.org")'? > > Ok, that wouldn't result in an illegal article, just a somewhat > annoying article. Rait. >> So you might have a variable with the list of headers that are always >> inserted and/or verified *in addition* to the standard ones, but >> if you want to remove/deform a standard header you must go via >> an "advanced" variable, a hook or an fset. > > Hm. Aren't the header generation variables rather "advanced" already, > in a way? `message-required-news-headers' does the insertion while > `message-header-syntax-checks' does the checking... Sorry, I haven't looked much at sgnus. The GNKS discussion gave me the impression that this was one example, so I used it. > I agree with you in principle (I think), but do you have any specific > examples? Well, not until I've used sgnus some more:-) Generally, I'd say that any variable which a not-too-unusual novice might need or want to modify, should be a novice variable. A novice variable which may contain any nonstandard values we want and an expert varible controlling what to do about it, is an idea I didn't think of. I like it. So, - Call message-required-news-headers a novice variable and message-syntax-checks an expert variable. - Add to the expert variable's doc string and Info description a scaretext like "if you think you need to *remove* an error check from this variable, your are probably breaking or misunderstanding some rules about news/mail or the etiquette on the Net. Please ask an experienced user if you should really do this." - Maybe "negate" message-syntax-checks' logic so that an "easy" statement like (setq message-syntax-checks nil) won't help, you'd have to explicitly remove the checks -- at least for the checks in GNKS: (nconc message-syntax-checks '((- (from message-id empty)))) (Why? Becuase of the infernal problem that novices copy experts' .emacs files without checking out what every statement does. Later they modify their .emacses and they still don't exactly know what they are doing...) Anyway, I suppose this is to a large degree a documentation issue, which can be done later. Interface chances, like changing variables to use "negated logic" would be more urgent, though. But I'm not going to traverse sgnus to find them all... >> - Error messages should either contain enough help to let a novice >> correct the error, or it should tell him where to read about how to >> fix it. >> >> Error messages that refer to other text, could be put in a separate >> info file, and the message would pop up in a new Info buffer, with >> menu entries pointing to further reading. > > That's a very good idea. Definitely. So if the From header is > totally invalid, an info node explaining how the From header should > look like is popped up with plenty of references to documentation on > the relevant variables. Sounds like quite a lot of writing, though. Write the framework and a few doc examples, then ask on gnu.emacs.gnus and gnu.emacs.announce for more documentation from volunteers:-) Regards, Hallvard