* on Good Net-Keeping Seal @ 1996-04-11 22:12 Hallvard B Furuseth 1996-04-22 0:48 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 6+ messages in thread From: Hallvard B Furuseth @ 1996-04-11 22:12 UTC (permalink / raw) There was a recent discusson about Gnus vs. The Good Net-Keeping Seal of Approval somewhere. Here are a few resulting thoughts that occurred to me afterwards: - 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. 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. - 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. Or perhaps some sort of pseudo-Info mode, with fewer keys that a novice can get lost with. To insert error messages from the NNTP server and such things into the Info node at run-time, the node must probably be written to a temporary file so that it can be visited later. Otherwise you can't get back to the node after following the references it contains. (Well, it is possible to modify an Info node at run-time; you put `execute: (sexp)' after the node. But I can't figure out how to make sure you get rid of the modification when you leave the node. Regards, Hallvard ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: on Good Net-Keeping Seal 1996-04-11 22:12 on Good Net-Keeping Seal Hallvard B Furuseth @ 1996-04-22 0:48 ` Lars Magne Ingebrigtsen 1996-04-22 7:50 ` Hallvard B Furuseth 0 siblings, 1 reply; 6+ messages in thread From: Lars Magne Ingebrigtsen @ 1996-04-22 0:48 UTC (permalink / raw) Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 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? `(setq user-mail-address "god@heaven.org")'? Ok, that wouldn't result in an illegal article, just a somewhat annoying article. > 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... I agree with you in principle (I think), but do you have any specific examples? > - 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. -- "Yes. The journey through the human heart would have to wait until some other time." ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: on Good Net-Keeping Seal 1996-04-22 0:48 ` Lars Magne Ingebrigtsen @ 1996-04-22 7:50 ` Hallvard B Furuseth 1996-04-22 19:39 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 6+ messages in thread From: Hallvard B Furuseth @ 1996-04-22 7:50 UTC (permalink / raw) Cc: ding Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes: > Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: on Good Net-Keeping Seal 1996-04-22 7:50 ` Hallvard B Furuseth @ 1996-04-22 19:39 ` Lars Magne Ingebrigtsen 1996-04-24 12:30 ` Hallvard B Furuseth 0 siblings, 1 reply; 6+ messages in thread From: Lars Magne Ingebrigtsen @ 1996-04-22 19:39 UTC (permalink / raw) Hallvard B Furuseth <h.b.furuseth@usit.uio.no> writes: > - 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)))) I've now made the default for `message-syntax-checks' be nil. To disable a check, you now have to add elements that look like `(signature . disabled)' to the alist. So to disable all the checks, you have to really work a bit. > Write the framework and a few doc examples, then ask on gnu.emacs.gnus > and gnu.emacs.announce for more documentation from volunteers:-) I've added this to the Red Gnus todo list. -- "Yes. The journey through the human heart would have to wait until some other time." ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: on Good Net-Keeping Seal 1996-04-22 19:39 ` Lars Magne Ingebrigtsen @ 1996-04-24 12:30 ` Hallvard B Furuseth 1996-04-28 9:02 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 6+ messages in thread From: Hallvard B Furuseth @ 1996-04-24 12:30 UTC (permalink / raw) Cc: ding > I've added this to the Red Gnus todo list. Incidentally, where do I find the Red Gnus todo list? Hallvard ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: on Good Net-Keeping Seal 1996-04-24 12:30 ` Hallvard B Furuseth @ 1996-04-28 9:02 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 6+ messages in thread From: Lars Magne Ingebrigtsen @ 1996-04-28 9:02 UTC (permalink / raw) Hallvard B Furuseth <h.b.furuseth@usit.uio.no> writes: > Incidentally, where do I find the Red Gnus todo list? <URL:http://www.ifi.uio.no/~larsi/sgnus/todo>. -- "Yes. The journey through the human heart would have to wait until some other time." ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1996-04-28 9:02 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-04-11 22:12 on Good Net-Keeping Seal Hallvard B Furuseth 1996-04-22 0:48 ` Lars Magne Ingebrigtsen 1996-04-22 7:50 ` Hallvard B Furuseth 1996-04-22 19:39 ` Lars Magne Ingebrigtsen 1996-04-24 12:30 ` Hallvard B Furuseth 1996-04-28 9:02 ` Lars Magne Ingebrigtsen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).