fix(?) and questions [sgnus-0.17]

fix(?) and questions [sgnus-0.17]

[Jens Lautenbacher]

There is one more fix for today, but maybe it's more a dirty
workaround than a real fix. It fixes an error that occures when
leaving a group that was selected from the list of killed groups and
topic-mode is active, because this group doesn't belong to any topic,
naturally.  


I have some questions and sugestions, also:

1)  It seems to be impossible to get rid of the root of the topic-tree
    (that topic labeled "Gnus" on startup). 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? I
    think, this decision (if I want to see my newsgroups or if I
    don't) is made on entering sgnus.

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

3)  I am still not happy with the way the killed groups are
    handled. The main point is that it is IMHO to slow (just the
    building of the buffer). And the lack of the mouse-face (which
    according to lars was made to speed things up) hurts the nice and
    colorful outfit of the rest of the program. So I have to wishes
    that exclude each other. But maybe we could do the following:

    * first of all: It should be sufficient to build the buffer of
      killed groups one time. By now it just uses the group buffer and
      the contents is lost as soon as one goes back to his/her normal
      groups.    

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

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? 

    The reason I tried this is that I want `subscribing' do only very
    limited things: It should enter the group into my group-buffer so
    I can select it, if I want to. I think it should retrieve any more
    info later on actually entering the group. Please enlighten me,
    if this is impossible.

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.


And finally: the dirty patch I told you about many lines of email ago:

With best regards,
	jens




*** gnus-topic.el~	Sun Dec  3 15:02:26 1995
--- gnus-topic.el	Sun Dec  3 16:48:51 1995
***************
*** 371,379 ****
  	 (entries (gnus-topic-find-groups (car type)))
  	 (visiblep (eq (nth 1 type) 'visible)))
      ;; Insert the topic line.
!     (gnus-delete-line)
!     (gnus-topic-insert-topic-line 
!      (car type) visiblep (not (eq (nth 2 type) 'hidden)) level entries)))
  
  ;;; Topic mode, commands and keymap.
  
--- 371,382 ----
  	 (entries (gnus-topic-find-groups (car type)))
  	 (visiblep (eq (nth 1 type) 'visible)))
      ;; Insert the topic line.
!     (if topic
! 	(progn
! 	  (gnus-delete-line)
! 	  (gnus-topic-insert-topic-line 
! 	   (car type) visiblep
! 	   (not (eq (nth 2 type) 'hidden)) level entries)))))
  
  ;;; Topic mode, commands and keymap.
  
*** ChangeLog~	Sun Dec  3 15:07:40 1995
--- ChangeLog	Sun Dec  3 16:54:08 1995
***************
*** 1,3 ****
--- 1,8 ----
+ Sun Dec  3 16:49:58 1995  Jens Lautenbacher  <jtl@tkmhp12.physik.uni-karlsruhe.de>
+ 
+ 	* gnus-topic.el (gnus-topic-update-topic-line): bombed out on exit
+ 	  from a group that was selected from the list of killed groups
+ 
  Sun Dec  3 15:03:02 1995  Jens Lautenbacher  <jtl@tkm.physik.uni-karlsruhe.de>
  
  	* gnus-topic.el (gnus-topic-update-topic): parameter `group' in

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

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

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

[Thomas Neumann]

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

I tried to rename a topic (any topic), but it bombed out on me. Here's a
quick fix


*** gnus-topic.el~	Mon Dec  4 10:35:15 1995
--- gnus-topic.el	Mon Dec  4 10:38:06 1995
***************
*** 607,611 ****
     (list
      (completing-read "Rename topic: " gnus-topic-alist nil t)
!     (read-string (format "Rename %s to: "))))
    (let ((top (gnus-topic-find-topology old-name))
  	(entry (assoc old-name gnus-topic-alist)))
--- 607,611 ----
     (list
      (completing-read "Rename topic: " gnus-topic-alist nil t)
!     (read-string "New name: ")))
    (let ((top (gnus-topic-find-topology old-name))
  	(entry (assoc old-name gnus-topic-alist)))


Renaming of topics seems to be a little bit goofy still. For instance,
after renaming a topic the new name does not show up until one 'g'ets
new news.

-t