Re: on Good Net-Keeping Seal

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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