on Good Net-Keeping Seal

on Good Net-Keeping Seal

[Hallvard B Furuseth]

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

Re: on Good Net-Keeping Seal

[Lars Magne Ingebrigtsen]

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."

Re: on Good Net-Keeping Seal

[Hallvard B Furuseth]

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

Re: on Good Net-Keeping Seal

[Lars Magne Ingebrigtsen]

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."

Re: on Good Net-Keeping Seal

[Hallvard B Furuseth]

> I've added this to the Red Gnus todo list.

Incidentally, where do I find the Red Gnus todo list?


Hallvard

Re: on Good Net-Keeping Seal

[Lars Magne Ingebrigtsen]

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."