From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4249 Path: main.gmane.org!not-for-mail From: larsi@ifi.uio.no (Lars Magne Ingebrigtsen) Newsgroups: gmane.emacs.gnus.general Subject: Re: fix(?) and questions [sgnus-0.17] Date: 04 Dec 1995 02:51:01 +0100 Organization: Dept. of Informatics, University of Oslo, Norway Sender: larsi@ifi.uio.no Message-ID: References: <"nz11.rz.un.726:03.12.95.16.47.05"@rz.uni-karlsruhe.de> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145022 28964 80.91.224.250 (20 Oct 2002 20:17:02 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:17:02 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.6.11/8.6.9) with ESMTP id SAA20606 for ; Sun, 3 Dec 1995 18:36:45 -0800 Original-Received: from surt.ifi.uio.no (4867@surt.ifi.uio.no [129.240.76.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 4 Dec 1995 02:51:04 +0100 Original-Received: (from larsi@localhost) by surt.ifi.uio.no ; Mon, 4 Dec 1995 02:51:02 +0100 Original-To: ding@ifi.uio.no In-Reply-To: Jens Lautenbacher's message of Sun, 3 Dec 1995 17:44:50 +0100 Original-Lines: 70 Xref: main.gmane.org gmane.emacs.gnus.general:4249 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4249 Jens Lautenbacher 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.