* fix(?) and questions [sgnus-0.17]
@ 1995-12-03 16:44 Jens Lautenbacher
1995-12-04 1:51 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 3+ messages in thread
From: Jens Lautenbacher @ 1995-12-03 16:44 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: fix(?) and questions [sgnus-0.17]
1995-12-03 16:44 fix(?) and questions [sgnus-0.17] Jens Lautenbacher
@ 1995-12-04 1:51 ` Lars Magne Ingebrigtsen
1995-12-04 9:46 ` Thomas Neumann
0 siblings, 1 reply; 3+ messages in thread
From: Lars Magne Ingebrigtsen @ 1995-12-04 1:51 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: fix(?) and questions [sgnus-0.17]
1995-12-04 1:51 ` Lars Magne Ingebrigtsen
@ 1995-12-04 9:46 ` Thomas Neumann
0 siblings, 0 replies; 3+ messages in thread
From: Thomas Neumann @ 1995-12-04 9:46 UTC (permalink / raw)
Cc: ding
> > 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~1995-12-04 9:46 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1995-12-03 16:44 fix(?) and questions [sgnus-0.17] Jens Lautenbacher
1995-12-04 1:51 ` Lars Magne Ingebrigtsen
1995-12-04 9:46 ` Thomas Neumann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).