Feature Request. Topic Group Parameters...

Feature Request. Topic Group Parameters...

[Bob Cotton]

I have a feature request for Red Gnus. I'd like to see group
parameters associated with Topics, that apply to all groups in that
topic. Sub-topics would inherit, and could override the group
parameters from their parent topics they are in.

That way I could set several parameters for all groups in the [Mail]
topic and so on..


Comments?

- Bob
-- 
_____________________________________________________________________
Bob Cotton     	       	       	   ___________
ARC Technologies, LLC.            -----------+|
1610 Wyncoop, Suite 105          | Think Ahea||
Denver, CO  80202                |          d||
Phone: (303) 637-5089            |          !||
Fax:   (303) 623-0877            |___________|
      bob@hierArc.com                 | |
                                ~~~~~~| |~~~~~~~
--------------------------------------------------------------------

Re: Feature Request. Topic Group Parameters...

[Lars Magne Ingebrigtsen]

Bob Cotton <bcotton@hierarc.com> writes:

> I have a feature request for Red Gnus. I'd like to see group
> parameters associated with Topics, that apply to all groups in that
> topic. Sub-topics would inherit, and could override the group
> parameters from their parent topics they are in.

That's a good idea.  I've added it to the Red Gnus todo list.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Feature Request. Topic Group Parameters...

[Ken Raeburn]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> Bob Cotton <bcotton@hierarc.com> writes:
> 
> > I have a feature request for Red Gnus. I'd like to see group
> > parameters associated with Topics, that apply to all groups in that
> > topic. Sub-topics would inherit, and could override the group
> > parameters from their parent topics they are in.
> 
> That's a good idea.  I've added it to the Red Gnus todo list.

How should that deal with a group that falls under two topics?

Ken

Re: Feature Request. Topic Group Parameters...

[Lars Magne Ingebrigtsen]

Ken Raeburn <raeburn@cygnus.com> writes:

> Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> 
> > Bob Cotton <bcotton@hierarc.com> writes:
> > 
> > > I have a feature request for Red Gnus. I'd like to see group
> > > parameters associated with Topics, that apply to all groups in that
> > > topic. Sub-topics would inherit, and could override the group
> > > parameters from their parent topics they are in.
> > 
> > That's a good idea.  I've added it to the Red Gnus todo list.
> 
> How should that deal with a group that falls under two topics?

Good questions.  I'm beginning to wonder whether it's worth it to be
able to have the same group in several topics.  It leads to all sorts
of difficulties and ambiguities.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Feature Request. Topic Group Parameters...

[Colin Rafferty]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> Ken Raeburn <raeburn@cygnus.com> writes:
>>> Bob Cotton <bcotton@hierarc.com> writes:

>>>> I'd like to see group parameters associated with Topics...

>> How should that deal with a group that falls under two topics?

> Good questions.  I'm beginning to wonder whether it's worth it to be
> able to have the same group in several topics.  It leads to all sorts
> of difficulties and ambiguities.

I think that having topic parameters is worth losing the ability to have
groups in multiple topics.  I have `gnus-topic-unique' set to nil, but I
haven't found any very interesting use for it (other than to see the
bugs that still exist in the article count).

By the way, what is the replacement variable for `gnus-topic-unique'?  I
just noticed that it is no longer documented (and I set it to nil in my
.gnus).

-- 
Colin

Re: Feature Request. Topic Group Parameters...

[Ken Raeburn]

> Good questions.  I'm beginning to wonder whether it's worth it to be
> able to have the same group in several topics.  It leads to all sorts
> of difficulties and ambiguities.

That's actually one of the big things I like about topics.

Re: Feature Request. Topic Group Parameters...

[Wes Hardaker]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> Good questions.  I'm beginning to wonder whether it's worth it to be
> able to have the same group in several topics.  It leads to all sorts
> of difficulties and ambiguities.

Well, what I don't use it for but have always wanted to (IE, I'm too
lazy to hit c-k c-y) is to put my foreign mail groups next to my news
groups, but still be able to have them listed under mail groups as
well.  This way I can either enter gnus to read mail (which I do a
lot) and only read the mail groups topic or I can read the combined
subjects of 'nnml:ding' with 'nntp:gnu.emacs.gnus' at the same time...

However, as I've said, I don't tend to do this, simply because I'm
tired of spending time configuring gnus to do what I want.  I think
I'll start adding features again instead ;-)

Wes

Re: Feature Request. Topic Group Parameters...

[Per Abrahamsen]

>>>>> "KR" == Ken Raeburn <raeburn@cygnus.com> writes:

KR> That's actually one of the big things I like about topics.

I like it too.  

Re: Feature Request. Topic Group Parameters...

[Lars Magne Ingebrigtsen]

Colin Rafferty <craffert@spspme.ml.com> writes:

> By the way, what is the replacement variable for `gnus-topic-unique'?  I
> just noticed that it is no longer documented (and I set it to nil in my
> .gnus).

There is no replacement variable -- uniqueness isn't checked.  

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Feature Request. Topic Group Parameters...

[John Griffith]

>>>>> "KR" == Ken Raeburn <raeburn@cygnus.com> writes:

    KR> How should that deal with a group that falls under two topics?

    KR> Ken

How about asking the user what should be done?

Allow topics to have group parameters specified on them, but only use
these to update group parameters on actual groups when moving groups
into topics or changing topic-specified parameters.

When changing a group parameter on a topic, ask the user if all groups
should inherit this parameter, or whether s/he would like to go
through each group individually, showing old values and the possible
replacements (if they're different).  (Like the initial subscription
sequence.)

When a group is added to a topic ask if the group should inherit all
of the topics group parameters, or go through each one individually.

Since the user can only add a group to one topic at a time, there is
no conflict.

This might get irritating if the user moves groups around in the topic
hierarchy a lot and has lots of conflicting parameters specified on
topics.

Re: Feature Request. Topic Group Parameters...

[Lars Magne Ingebrigtsen]

John Griffith <griffith@sfs.nphil.uni-tuebingen.de> writes:

> How about asking the user what should be done?
> 
> Allow topics to have group parameters specified on them, but only use
> these to update group parameters on actual groups when moving groups
> into topics or changing topic-specified parameters.
> 
> When changing a group parameter on a topic, ask the user if all groups
> should inherit this parameter, or whether s/he would like to go
> through each group individually, showing old values and the possible
> replacements (if they're different).  (Like the initial subscription
> sequence.)

I think this sounds a bit annoying.  I would prefer having clear rules
for topic parameter inheretance instead of requiring lots of user
input when editing parameters.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Feature Request. Topic Group Parameters...

[John Griffith]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

    LMI> John Griffith <griffith@sfs.nphil.uni-tuebingen.de> writes:
    >> How about asking the user what should be done?
    >> 
    >> Allow topics to have group parameters specified on them, but only use
    >> these to update group parameters on actual groups when moving groups
    >> into topics or changing topic-specified parameters.
    >> 
    >> When changing a group parameter on a topic, ask the user if all groups
    >> should inherit this parameter, or whether s/he would like to go
    >> through each group individually, showing old values and the possible
    >> replacements (if they're different).  (Like the initial subscription
    >> sequence.)

    LMI> I think this sounds a bit annoying.  I would prefer having clear rules
    LMI> for topic parameter inheretance instead of requiring lots of user
    LMI> input when editing parameters.

I agree that this could get annoying, especially if you constantly
change things like I do.  So here's some ideas on possible rules.

Here's an example:

  t1
    g1
    g2
    t2
      g1
      g3
  t3
    g2

1.1) First of all it seems that if you're going to have rules to
     determine inheritance, then one should be that parameters
     specified on the group are always preferred over those specified
     on topics that it is in.

1.2) And lower topics are always preferred over higher ones, so g3 would
     take t2's parameters over t1's.

2) Another possible rule could be that if a group (g1 above) occurs in
   two topics (t1 and t2) one of which is an ancestor of the other,
   then the parameters of the lower group should be preferred.

3) The problem is, of course, what to do with a group (g2) that occurs
   in two topics (t1 and t3) which are not in the ancestor relation.

3.1) The most restrictive rule would be to disallow g2 to be under t1
     and t1's sister t3.  But I for one find that too restrictive.

3.2) Another possibility is to give every group a "home" topic.  Then
     that group only inherits from it's home topic, and possibly from
     ancestors of its home topic.  This seems fairly powerful, simple
     and easy to understand.

3.3) A less restrictive possibility would be to allow users to specify
     a precedence ordering on topics to determine which topics should
     win in a conflict.  However, it could be quite tricky to ensure
     that the user's rules completely avoid conflicts.

3.3.1) The simplest way would be to require a total order on
       topics. There could be a buffer with the list of topics, and
       the user could move these around.  You could limit the number
       of topics to be moved around by only displaying those that
       actually have parameters specified on them.

3.3.2) You actually don't need a total order, the user could specify a
       partial order on topics, but then the partial order would have
       to be checked to make sure every group's parameters could be
       uniquely determined.  I think this would require computing the
       closure of the partial order, which (I think) is O(N^3) where N
       is the number of topics.  Could be slow with lots of topics.
       Even if there were very good error messages in the case of
       conflicts, this could be very annoying and confusing.

The idea of having a home topic seems to be a nice balance between
simplicity and power.  This could be augmented with possible
inheritance from supertopics as in rules 1.1 and 1.2.  Then you could
think of part of the topic hierarchy as defining a parameter
inheritance hierarchy, and as part of it defining a hierarchical
presentation of groups.  Also, I think rule 2 wouldn't be necessary
since either t1 OR t2 (exclusively) would be the home of g1.

It seems like there should be some help to the user to recognize that
they've, for instance, just put a group in a topic which will cause it
to inherit total-expire.  A lot of damage could be done very quickly.

It would be nice if you could display the parameters associated with
each topic and group in the topic hierarchy and to mark groups when
they occur in their home topic.

Re: Feature Request. Topic Group Parameters...

[Lars Magne Ingebrigtsen]

John Griffith <griffith@sfs.nphil.uni-tuebingen.de> writes:

>   t1
>     g1
>     g2
>     t2
>       g1
>       g3
>   t3
>     g2

[Analysis snipped.  I basically agree with everything you said and I
think your conclusion is correct -- a "home topic" is the solution.]

How about looking at this in a different fashion -- use the display in
a more active fashion.  If I put point over g2 in t1 and execute some
command, then it's obvious that I want to do something to that copy of
g2, so g2 would inherit group parameters from the t1 topic.  If I do
the same command on the g2 copy in t3, then I would use the group
parameters in the t3 topic.  (And inheretance from parent topics, etc,
naturally.)  

This means that one can't in general say what
`(gnus-group-read-group "g2")' will do when called from an unknown
point, but user commands executed in a normal fashion would have
predictable outcomes.

This is certainly easy enough to implement, which is why I like it.
:-)  It's also easy to understand, I think, and requires no extra
information from the user on what she considers the "home topic" of
the group to be.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Feature Request. Topic Group Parameters...

[John Griffith]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

    LMI> How about looking at this in a different fashion -- use the
    LMI> display in a more active fashion.  If I put point over g2 in
    LMI> t1 and execute some command, then it's obvious that I want to
    LMI> do something to that copy of g2, so g2 would inherit group
    LMI> parameters from the t1 topic.  If I do the same command on
    LMI> the g2 copy in t3, then I would use the group parameters in
    LMI> the t3 topic.  (And inheretance from parent topics, etc,
    LMI> naturally.)

Ah, so you want different behavior depending which copy of the group
you select.  So you could have one copy of an nntp group in one topic
with threading, and another copy in another topic without threading
and with the `to-list' set to an alternative mail address.  That
sounds like a good idea, but some functions should be able to "stick"
with a group wherever it goes.  Like `auto-expire'.  I guess you could
say that if someone decides to read mail from their boss under a topic
which has this set, then they should not be surprised when all read
messages in that group expire.

That's more the problem that a "home topic" was suppose to address.
There should be some things about a group that don't change.  You
could force that information to be placed on the actual group itself,
but that would remove the ability to create a topic for high-volume,
low-content mailing lists and make them all `auto-expire' in one step.
So the "home topic" idea was meant to determine parameters that you
don't want to change.

If you want some parameters to be "sticky", then you need a way of
declaring them sticky (or maybe declaring a particular use of them
sticky).  There should be good (safe) defaults like `auto-expire'
should be sticky, as well.

-- 
John Griffith
Seminar fuer Sprachwissenschaft, Universitaet Tuebingen
email: griffith@sfs.nphil.uni-tuebingen.de
www: <URL:http://www.sfs.nphil.uni-tuebingen.de/~griffith/a/x0.html>

Re: Feature Request. Topic Group Parameters...

[Lars Magne Ingebrigtsen]

John Griffith <griffith@sfs.nphil.uni-tuebingen.de> writes:

> Ah, so you want different behavior depending which copy of the group
> you select.  So you could have one copy of an nntp group in one topic
> with threading, and another copy in another topic without threading
> and with the `to-list' set to an alternative mail address. 

Yup.  I've now implemented this.

> That sounds like a good idea, but some functions should be able to
> "stick" with a group wherever it goes.  Like `auto-expire'.  I guess
> you could say that if someone decides to read mail from their boss
> under a topic which has this set, then they should not be surprised
> when all read messages in that group expire.

And there are some operations that aren't really
group-buffer-conscious -- like `gnus-group-expire-all-groups'.  If a
mail group belongs to two topics, one with `total-expiry' and one
without, it's kinda hard to decide what to do.  I think I'll just have
the manual say that it's "undefined" what happens and let the user
deal with it.  

It's only `total-expiry' that has this problem, though, so perhaps one
could do something clever with that, but I don't quite know what...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Feature Request. Topic Group Parameters...

[Kai Grossjohann]

>>>>> Lars Magne Ingebrigtsen writes:

  Lars> It's only `total-expiry' that has this problem, though, so
  Lars> perhaps one could do something clever with that, but I don't
  Lars> quite know what...

How about not inheriting total-expire and auto-expire at all?  (Only
allowing these parameters in groups, not in topics.)  There are
regexps to set them automatically for many groups at once.  OTOH, this
is ugly.

kai
-- 
What's a signature?

Re: Feature Request. Topic Group Parameters...

[Lars Magne Ingebrigtsen]

Kai Grossjohann <grossjohann@ls6.informatik.uni-dortmund.de> writes:

> How about not inheriting total-expire and auto-expire at all?  (Only
> allowing these parameters in groups, not in topics.)  There are
> regexps to set them automatically for many groups at once.  OTOH, this
> is ugly.

Yup.  Especially since `total-expire' is probably the most useful
topic parameter of all, so I don't think it would be a good idea not
to let that parameter be inherited by groups.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."