`^ ... RET' server mode adds groups to *Group*?

`^ ... RET' server mode adds groups to *Group*?

[Karl Kleinpaste]

Go into the server buffer with `^'.
Wander down to an appropriate NNTP server, e.g. my primary, as
{nntp:news} (opened)
Now RET.

XEmacs cogitates at great length, presumably sorting the group list.
At the end of this effort, I am placed in my *Group* buffer, with
_all_ my server's groups added to *Group* at level 9 "killed" status.

Doubleplusungood.  I thought `^ RET' should give me a server-specific
group listing for transient or ephemeral access to groups?

Re: `^ ... RET' server mode adds groups to *Group*?

[Bill White]

On Sun Jan 28 2001 at 17:17, Karl Kleinpaste <karl@charcoal.com> said:

    kk> Go into the server buffer with `^'.  Wander down to an
    kk> appropriate NNTP server, e.g. my primary, as {nntp:news}
    kk> (opened) Now RET.

    kk> XEmacs cogitates at great length, presumably sorting the group
    kk> list.  At the end of this effort, I am placed in my *Group*
    kk> buffer, with _all_ my server's groups added to *Group* at
    kk> level 9 "killed" status.

Same here with GNU Emacs 21.0.95.1 (i586-pc-linux-gnu, X toolkit) of
2001-01-10 on g.wolfram.com.  Didn't that start happening with ognus?

Cheers -

bw
-- 
Bill White . billw@wolfram.com . http://members.wri.com/billw
"No ma'am, we're musicians."

Re: `^ ... RET' server mode adds groups to *Group*?

[Harry Putnam]

Bill White <billw@wolfram.com> writes:

> On Sun Jan 28 2001 at 17:17, Karl Kleinpaste <karl@charcoal.com> said:
> 
>     kk> Go into the server buffer with `^'.  Wander down to an
>     kk> appropriate NNTP server, e.g. my primary, as {nntp:news}
>     kk> (opened) Now RET.
> 
>     kk> XEmacs cogitates at great length, presumably sorting the group
>     kk> list.  At the end of this effort, I am placed in my *Group*
>     kk> buffer, with _all_ my server's groups added to *Group* at
>     kk> level 9 "killed" status.
> 
> Same here with GNU Emacs 21.0.95.1 (i586-pc-linux-gnu, X toolkit) of
> 2001-01-10 on g.wolfram.com.  Didn't that start happening with ognus?


Still having an older version of 5.8.8 available I see no such delay
but an immediate listing for...I guess what Karl calls:
"transient or ephemeral access"

It shows the same groups that `L' would show only limited to that
server, and in a buffer called "*Gnus Browse Server*", all at killed
status. 

Re: `^ ... RET' server mode adds groups to *Group*?

[Karl Kleinpaste]

Harry Putnam <reader@newsguy.com> writes:
> Still having an older version of 5.8.8 available I see no such delay
> but an immediate listing for...I guess what Karl calls:
> "transient or ephemeral access"

Found it.  It's deliberate.  From the ChangeLog:

2000-10-30 00:49:33  ShengHuo ZHU  <zsh@cs.rochester.edu>

	* gnus-srvr.el (gnus-server-browse-in-group-buffer): New variable.
	(gnus-server-read-server-in-server-buffer): New function.
	(gnus-browse-foreign-server): Browse in group buffer.

Setting to nil gets the old behavior.

I think having this variable defaulting to t is suboptimal.  And it's
much, much slower (due to having to go through the gyrations of adding
groups to *Group*) than browsing a server in its own server buffer.

Re: `^ ... RET' server mode adds groups to *Group*?

[ShengHuo ZHU]

Karl Kleinpaste <karl@charcoal.com> writes:

> Go into the server buffer with `^'.
> Wander down to an appropriate NNTP server, e.g. my primary, as
> {nntp:news} (opened)
> Now RET.
> 
> XEmacs cogitates at great length, presumably sorting the group list.
> At the end of this effort, I am placed in my *Group* buffer, with
> _all_ my server's groups added to *Group* at level 9 "killed" status.

It is an experimental feature in oGnus.  Only unknown or killed groups
are listed at level 9, and others groups are listed at the end of the
buffer if you use topic mode.  You may type `^ SPC' to list groups in
the old way, or (setq gnus-server-browse-in-group-buffer nil) to
disable the feature.

> Doubleplusungood.  I thought `^ RET' should give me a server-specific
> group listing for transient or ephemeral access to groups?

You can access killed groups. At least, I did it.

ShengHuo

-- 
(setq gnus-posting-styles '((".*" (signature-file "~/.signature"))))

Re: `^ ... RET' server mode adds groups to *Group*?

[ShengHuo ZHU]

Karl Kleinpaste <karl@charcoal.com> writes:

[...]

> I think having this variable defaulting to t is suboptimal.  And it's
> much, much slower (due to having to go through the gyrations of adding
> groups to *Group*) than browsing a server in its own server buffer.

The advantage is that you can access groups in group buffer, but you
cannot in server browse buffer.

ShengHuo

-- 
(setq gnus-posting-styles '((".*" (signature-file "~/.signature"))))

Re: `^ ... RET' server mode adds groups to *Group*?

[Karl Kleinpaste]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:
> The advantage is that you can access groups in group buffer, but you
> cannot in server browse buffer.

I don't understand why it's an advantage.

Having a server-browsing buffer is for the specific purpose of looking
over what a particular server has to offer, and allowing the user to
ephemerally look into any of them, or do a general subscription pick
out of the complete list.

How does tacking this monstrous mass of mostly crud into *Group* do
anything useful for me?  On my PII-450, it took well over 2 minutes of
internal hackery for Gnus to do the shovel-groups-into-*Group*-as-
killed (because managing *Group* is comparatively convoluted), whereas
going for the original buffer-browsing-server-by-itself popped up in
all of perhaps 15 seconds.  My active file is about 600K.

I just don't see what new capability this is supposed to provide.

Re: `^ ... RET' server mode adds groups to *Group*?

[Harry Putnam]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> Karl Kleinpaste <karl@charcoal.com> writes:
> 
> [...]
> 
> > I think having this variable defaulting to t is suboptimal.  And it's
> > much, much slower (due to having to go through the gyrations of adding
> > groups to *Group*) than browsing a server in its own server buffer.
> 
> The advantage is that you can access groups in group buffer, but you
> cannot in server browse buffer.


Have things already been changed?  Todays cvs shows different
behavior.

`^' in `server' buffer and <RET> on nntp server, immediately moves me to
group buffer displaying all groups I have, including unsubscribed ones
under that server.

I don't see the massive work Karl describes.  What I see is nothing
more than `L' listing but limited to nntp server groups.

A <spc> on nntp server seems to give the old behavior in tact.

What is the intent, again?

Re: `^ ... RET' server mode adds groups to *Group*?

[ShengHuo ZHU]

Harry Putnam <reader@newsguy.com> writes:

[...]

> Have things already been changed?  Todays cvs shows different
> behavior.

Nothing has been changed for three months.

> `^' in `server' buffer and <RET> on nntp server, immediately moves me to
> group buffer displaying all groups I have, including unsubscribed ones
> under that server.
> 
> I don't see the massive work Karl describes.  

If the server had thousands of groups, you would see the massive work.

> What I see is nothing more than `L' listing but limited to nntp
> server groups.

It is because all of those groups are in gnus-killed-list.

> A <spc> on nntp server seems to give the old behavior in tact.

Yes. For the sake of speed.

> What is the intent, again?

First, it is in the wish list.  Second, you can do much more things in
the group buffer than in the Gnus browse server buffer.

ShengHuo

-- 
(setq gnus-posting-styles '((".*" (signature-file "~/.signature"))))

Re: `^ ... RET' server mode adds groups to *Group*?

[Harry Putnam]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> Harry Putnam <reader@newsguy.com> writes:
> 
> [...]
> 
> > Have things already been changed?  Todays cvs shows different
> > behavior.
> 
> Nothing has been changed for three months.
> 
> > `^' in `server' buffer and <RET> on nntp server, immediately moves me to
> > group buffer displaying all groups I have, including unsubscribed ones
> > under that server.
> > 
> > I don't see the massive work Karl describes.  
> 
> If the server had thousands of groups, you would see the massive work.

I'm still confused as to what it does.  Is it different than pressing
`A A' in group buffer? 

That server has some 29,000+ groups.

Pressing `A A' in Group gives me. 
some 29,000 lines  1300K of active file

Pressing <RET> on that nntp server in server_buffer gives me some 40 lines 

> > What I see is nothing more than `L' listing but limited to nntp
> > server groups.
> 
> It is because all of those groups are in gnus-killed-list.

But it displays almost instantly.  And `A k' in group
shows some 15,000 lines

[...]

> First, it is in the wish list.  Second, you can do much more things in
> the group buffer than in the Gnus browse server buffer.

So it is different than `A A'?

Re: `^ ... RET' server mode adds groups to *Group*?

[ShengHuo ZHU]

Harry Putnam <reader@newsguy.com> writes:

> I'm still confused as to what it does.  Is it different than pressing
> `A A' in group buffer? 

There differences are that `A A'
    1. does not list groups on foreign servers;
    2. sorts groups by name and list them in flat mode;
    3. does not show the levels of groups.

> That server has some 29,000+ groups.
> 
> Pressing `A A' in Group gives me. 
> some 29,000 lines  1300K of active file
> 
> Pressing <RET> on that nntp server in server_buffer gives me some 40 lines 

Do you use it in unplugged mode?

> > > What I see is nothing more than `L' listing but limited to nntp
> > > server groups.

In unplugged mode, `^ RET' only list groups in saved active file and
killed-list, so it is nothing more than `L' listing.

> > It is because all of those groups are in gnus-killed-list.
> 
> But it displays almost instantly.  And `A k' in group
> shows some 15,000 lines

How many groups are from the nntp server?

> > First, it is in the wish list.  Second, you can do much more things in
> > the group buffer than in the Gnus browse server buffer.
> 
> So it is different than `A A'?

Yes.

ShengHuo

-- 
(setq gnus-posting-styles '((".*" (signature-file "~/.signature"))))

Re: `^ ... RET' server mode adds groups to *Group*?

[Harry Putnam]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> Harry Putnam <reader@newsguy.com> writes:
> 
> > I'm still confused as to what it does.  Is it different than pressing
> > `A A' in group buffer? 
> 
> There differences are that `A A'
>     1. does not list groups on foreign servers;
>     2. sorts groups by name and list them in flat mode;
>     3. does not show the levels of groups.
> 
> > That server has some 29,000+ groups.
> > 
> > Pressing `A A' in Group gives me. 
> > some 29,000 lines  1300K of active file
> > 
> > Pressing <RET> on that nntp server in server_buffer gives me some 40 lines 
> 
> Do you use it in unplugged mode?

Ahhh theres the rub... I was unplugged.  I see how it works now  and
the extra functionality is nice.  Esp. since we still have <spc> for
the old behavior.

Regexp matching is another good reason to move it to group buffer.

[...]

> > So it is different than `A A'?
> 
> Yes.

Yes indeed.  Another difference that isn't so apparent is that `A A'
works the same plugged or unplugged.  (long as a link is up, of course)

Whereas  the new `<RET> on server' offers different functionality
plugged and unplugged.  More options, always a plus.

One thing I noticed that may be a small bug is that under certain
conditions after pressing <spc> on a server.  When leaving that buffer
with `q'.  It can cause a major cpu drain while emacs pulls down all
available cpu and does nothing (not visibly any way).

I haven't been able to repoduce this reliably but it happened three
times (not in sequence) while I've been experimenting with this new
functionality. 

Re: `^ ... RET' server mode adds groups to *Group*?

[ShengHuo ZHU]

Harry Putnam <reader@newsguy.com> writes:

[...]

> Yes indeed.  Another difference that isn't so apparent is that `A A'
> works the same plugged or unplugged.  (long as a link is up, of course)

Right. `A A' works as if Gnus were unagentized.

> Whereas  the new `<RET> on server' offers different functionality
> plugged and unplugged.  More options, always a plus.

Maybe a prefix argument for gnus-server-read-server-in-server-buffer.

> One thing I noticed that may be a small bug is that under certain
> conditions after pressing <spc> on a server.  When leaving that buffer
> with `q'.  It can cause a major cpu drain while emacs pulls down all
> available cpu and does nothing (not visibly any way).

> I haven't been able to repoduce this reliably but it happened three
> times (not in sequence) while I've been experimenting with this new
> functionality. 

I guess Emacs was cleaning up garbage. Lots of symbols and cons are
used to list the groups.

ShengHuo

-- 
(setq gnus-posting-styles '((".*" (signature-file "~/.signature"))))