Re: fix(?) and questions [sgnus-0.17]

[larsi@ifi.uio.no (Lars Magne Ingebrigtsen)]

Jens Lautenbacher <jtl@tkm.physik.uni-karlsruhe.de> writes:

> 1)  It seems to be impossible to get rid of the root of the topic-tree
>     (that topic labeled "Gnus" on startup). 

Yes.  But you can rename it.  To "", for instance, if it really bugs
you. 

>     But this topic makes no sense. It would be (_very much_) better
>     to allow for multiple roots. Why should anyone want to hide/show
>     the whole tree?

Why not?  I think it's *neat*.  

> 2)  Topic rearrangement doesn't work very good by now. One needs a key
>     (perhaps shift-tab) for un-indenting a topic.

`C-u TAB'.

>     Also the topics behave a little unexpected. They seem to jump to
>     the end of the list, when they are taken back one level of
>     indentation. I think they should arrange _befor_ the former
>     parent (so with one keystroke they can be moved back again).

Well...  I'm not sure.

>     * first of all: It should be sufficient to build the buffer of
>       killed groups one time.

Keeping a buffer updated when new groups are added and so on is just a
pain.  Which I'd like to avoid.

>     * Perhaps it would be possible to use something similiar as
>       topic-mode to browse the list of killed groups (LOKG) Just build
>       the topics based on the usenet hirachy, say 3 or 4 levels
>       deep. Browsing could be done oneline (one would need an
>       additional list that holds just the `topics', and maybe a flag
>       if there are real groups at this level already): Present the
>       user the highest topics, and if he/she selects "comp", just the
>       new info is prepared and inserted into the buffer. So we
>       wouldn't be faster if one wants to open all topics down to the
>       group level, but the time the user sits and waits
>       without any interaction would be reduced in almost all cases.

Yes, that might be helpful.  However, when I list all groups, I do
that so I'm able to `C-s' for groups I'm interested in.  If you get a
hidden hierarchical topics view of the groups, you'd have to know
where the groups are located before you find them.  Then you might as
well just `U' and enter the name (and TAB a bit).  Much faster.

> 4)  I tried a little change in gnus-group-unsubscribe-group: I just
>     removed the calls to (gnus-group-update-group group) (2 of them)
>     which was a dramatic speedup on subscribing to killed groups. But
>     I am not in the position to see the nasty sideeffects this
>     (undoubtly) will have. Could you tell me, please? 

You won't get mouse-face on the group.  :-)  And stuff.

> 5)  I think, gnus-group-goto-unread should be bound to nil while
>     browsing the LOKG. It always takes forever if you leave a group
>     and it searches around 8000 lines only to find that there is no
>     more unread group.

I don't know...  I feel that programs shouldn't do unexpected things.
If you have `gnus-group-goto-unread' set to t, then Gnus should
attempt to do that.  (`gnus-group-goto-unread' should perhaps be nil
by default, though.)

-- 
Home is where the cat is.