Li'l Feature Wish

Li'l Feature Wish

[Kai Grossjohann]

WIBNI there was a way to toggle threading from the *Group* buffer?
Right now you have to be in a summary buffer to do that, AFAIK.

Also, it'd be nice if toggling the threading would print some useful
message in the echo area, along the lines of `Threading is now
(on|off).' or something.

kai
-- 
Life is hard and then you die.

Re: Li'l Feature Wish

[Lars Magne Ingebrigtsen]

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

> WIBNI there was a way to toggle threading from the *Group* buffer?
> Right now you have to be in a summary buffer to do that, AFAIK.

Yes.  Well, I don't know whether that would be all that useful...

> Also, it'd be nice if toggling the threading would print some useful
> message in the echo area, along the lines of `Threading is now
> (on|off).' or something.

I've added this to Gnus 5.2.34.

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

Re: Li'l Feature Wish

[Kai Grossjohann]

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

  Kai> WIBNI there was a way to toggle threading from the *Group* buffer?
  Kai> Right now you have to be in a summary buffer to do that, AFAIK.

>>>>> On 05 Jul 1996 03:15:37 +0200, Lars Magne Ingebrigtsen
>>>>> <larsi@ifi.uio.no> said:

  Lars> Yes.  Well, I don't know whether that would be all that useful...

Here's why I use it.  Determine for yourself if you think others might
want to use it, too.

I have a group foo for the ongoing FoO project.  I also have
foo.archive which is for stuff that has been talked about before but
isn't that important any longer.  Of course, sometimes I have to look
into the foo.archive group anyway.  Often I know that the message I'm
looking for must have been from some date (give or take a few weeks).
Then I would enter the group unthreaded and search for the article.

Of course, entering the group first then toggling threading isn't the
best thing to do as the group is large -- 2000 messages or so.

Maybe keeping an extra archive group is no good and I should instead
be keeping all articles in one group and make the old ones dormant?

Btw, gnus-summary-toggle-threads always seems to do the trick, if
invoked from the Group buffer, even though strange things happen...

kai
-- 
Life is hard and then you die.

Re: Li'l Feature Wish

[Lars Magne Ingebrigtsen]

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

> Of course, entering the group first then toggling threading isn't the
> best thing to do as the group is large -- 2000 messages or so.

That's a good point.  But it does feel kinda unclean to provide
commands like that in the group buffer.  I'll put it on the Red Gnus
todo list and see whether I like the idea or not after implementing
it. 

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

Re: Li'l Feature Wish

[Hallvard B Furuseth]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
>Kai Grossjohann <grossjoh@ls6.informatik.uni-dortmund.de> writes:
> 
>> Of course, entering the group first then toggling threading isn't the
>> best thing to do as the group is large -- 2000 messages or so.
> 
> That's a good point.  But it does feel kinda unclean to provide
> commands like that in the group buffer.

Suggestion: If `gnus-show-treads' is an integer, only thread if there
are at most gnus-show-treads articles in the summary buffer.


Regards,

Hallvard

Re: Li'l Feature Wish

[Lars Magne Ingebrigtsen]

Hallvard B Furuseth <h.b.furuseth@usit.uio.no> writes:

> Suggestion: If `gnus-show-treads' is an integer, only thread if there
> are at most gnus-show-treads articles in the summary buffer.

Generating and unthreaded summary buffer isn't really that much faster
than generating a threaded display (I think), so I don't think it
would be all that useful determine whether to use threads based on the
number of articles...

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

Re: Li'l Feature Wish

[Kai Grossjohann]

>>>>> On Mon, 15 Jul 1996 18:55:44 +0200 (MET DST), Hallvard B
>>>>> Furuseth <h.b.furuseth@usit.uio.no> said:

  Hallvard> Suggestion: If `gnus-show-treads' is an integer, only
  Hallvard> thread if there are at most gnus-show-treads articles in
  Hallvard> the summary buffer.

What I wanted was to be able to decide whether I wanted to enter a
threaded or an unthreaded summary buffer.  As Lars explained, the
speed difference isn't all that great.  The problem is with having to
generate the summary twice in the `enter the group, then toggle
threading' scheme.

I still wish there were one of the following:
  - an extra key to toggle the threading in the *Group* buffer
  - a way to decide, when entering the group, whether it should
    be threaded or not.

Btw, RET vs M-RET comes close to the second goal, but after limiting,
threading is turned on again (after M-RET).

kai
-- 
Life is hard and then you die.

Re: Li'l Feature Wish

[Hallvard B Furuseth]

> Generating and unthreaded summary buffer isn't really that much faster
> than generating a threaded display (I think),

Oh well.  Other ways I can think of:

a) You didn't like a key to set threading from the *group* buffer -- is
   that because you'd have to duplicate a lot of *summar* things in the
   *group* buffer?  If so, generalize: "K S keys" will execute "keys" on
   behalf of the next summary buffer to be entered (or it will be saved
   and executed *when* the next summary buffer is entered).  K A -- for
   the next *article* buffer.  K G -- for the "next" *group* buffer:-)

b) A key (and possibly a per-group flag) to enter a group without
   threading, scoring and filling the summmary buffer.  Maybe it'd just
   show a single "article" named "get summary".  Then we could set
   threading/scoring flags from the summary buffer and *then* push SPC
   to generate the summary.
   (BTW, the key could be ^G: Let ^G while entering a group take us to
   the *summary* buffer instead of back to the *group* buffer.)

c) The same, but you don't enter the summary - you get the *article*
   buffer *without* summary.  Then you can read news without a summary
   buffer, or you can do stuff on behalf of the group, and enter (thus
   generating) a summary.

Hope I'm not totally off target; I don't quite remember how this thread
started.

Hallvard

Re: Li'l Feature Wish

[Lars Magne Ingebrigtsen]

Hallvard B Furuseth <h.b.furuseth@usit.uio.no> writes:

> a) You didn't like a key to set threading from the *group* buffer -- is
>    that because you'd have to duplicate a lot of *summar* things in the
>    *group* buffer?  If so, generalize: "K S keys" will execute "keys" on
>    behalf of the next summary buffer to be entered (or it will be saved
>    and executed *when* the next summary buffer is entered).  K A -- for
>    the next *article* buffer.  K G -- for the "next" *group* buffer:-)

This is a very interesting idea...  Hm.  However, the `t' command in
the summary buffer regenerates the summary buffer, so `K S t' & `RET'
would enter the group, toggle threading, generate the summary buffer
and generate the summary buffer.  Which isn't really a win.  :-)

> b) A key (and possibly a per-group flag) to enter a group without
>    threading, scoring and filling the summmary buffer.

`M-RET' bypasses all scoring, highlighting and stuff and should allow
as quick as possible summary buffer generation.

>    Maybe it'd just show a single "article" named "get summary".
>    Then we could set threading/scoring flags from the summary buffer
>    and *then* push SPC to generate the summary.

That's a possibility.  Hm, yes.  Well, we don't even need that; we
could just have a general "(re)generate summary" command.  Yes, I
think I like this one; I'll add it to the Red Gnus todo list.  

> c) The same, but you don't enter the summary - you get the *article*
>    buffer *without* summary.  Then you can read news without a summary
>    buffer, or you can do stuff on behalf of the group, and enter (thus
>    generating) a summary.

That would require a total rewrite of Gnus, which might be a bit
excessive considering the gains to be had.  :-)

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

Re: Li'l Feature Wish

[Lars Magne Ingebrigtsen]

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

> What I wanted was to be able to decide whether I wanted to enter a
> threaded or an unthreaded summary buffer.  As Lars explained, the
> speed difference isn't all that great.  The problem is with having to
> generate the summary twice in the `enter the group, then toggle
> threading' scheme.

The `0 RET' command will now avoid generating the summary buffer, so
you can `0 RET T T' to toggle the threading and yet avoid generating
the buffer twice.  I've also bound `M-C-g' to `gnus-summary-prepare',
so that it's easier to generate the buffer.

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