run `J u' from Group Params

run `J u' from Group Params

[Harry Putnam]

I want to agentize a couple groups without going to the trouble of
agentizing there server.  That is, just download with J u when I
think about it.  Not have to go thru any bother agentizing the server.

I wondered if I could run the J u command from Group params some how
so that when ever I press <RET> on the group a hook runs J u 
just before I enter.

Re: run `J u' from Group Params

[Kevin Greiner]

Harry Putnam <hgp@sbcglobal.net> writes:

> I want to agentize a couple groups without going to the trouble of
> agentizing there server.  That is, just download with J u when I
> think about it.  Not have to go thru any bother agentizing the server.

None of the agent command will function on a group whose server is not
agentized.

As for actually agentizing the server, I'm don't understand why you
think that it is such a bother.  All that you need do is '^' in the
group buffer to open the server buffer then a 'J a' on the appropriate
server.

> I wondered if I could run the J u command from Group params some how
> so that when ever I press <RET> on the group a hook runs J u 
> just before I enter.

So the bother might not be on agentizing the server but in setting up
the agent group so that 'J u' will automatically fetch the desired
articles.  Well, that is a bit of a bother.  At the very least, you'll
need to set the agent predicate for the default group to true.  That
way, 'J u' will know to fetch all of the group's articles.

Just to let you know, I'm currently working on a new interface for
configuring the agent.  The major changes will be 1) agent groups will
be edited using a form similar to the group customization form, and 2)
you'll be able to customize individual groups using the group
customization form.

I'd go ahead with configuring the default agent group as the new
customization interface will not be available for a while yet.

Kevin

Re: run `J u' from Group Params

[Harry Putnam]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> Harry Putnam <hgp@sbcglobal.net> writes:
>
>> I want to agentize a couple groups without going to the trouble of
>> agentizing there server.  That is, just download with J u when I
>> think about it.  Not have to go thru any bother agentizing the server.
>
> None of the agent command will function on a group whose server is not
> agentized.

I don't see that here.  Pressing the agent command J u on a group
that has been agentized with J a (even though the server is not
agentized seems to work just fine.

Assuming my catagories setup of cat Default = false
                                cat two     = true

> As for actually agentizing the server, I'm don't understand why you
> think that it is such a bother.  All that you need do is '^' in the
> group buffer to open the server buffer then a 'J a' on the appropriate
> server.

Things happen to the groups when you do that.  For example:
The face used to display all new messages in groups in 
category default (predicate = false) changes from default to 
gnus-summary-normal-uncached-face. Now one has to fiddle with 
faces to get back to what you've come to expect when non-agentized.
Not sure what else may change, and didn't really want to find out.

>> I wondered if I could run the J u command from Group params some how
>> so that when ever I press <RET> on the group a hook runs J u 
>> just before I enter.
>
> So the bother might not be on agentizing the server but in setting up
> the agent group so that 'J u' will automatically fetch the desired
> articles.  Well, that is a bit of a bother.  At the very least, you'll
> need to set the agent predicate for the default group to true.  That
> way, 'J u' will know to fetch all of the group's articles.

That is exactly what I do.  Seems less troublesome than messing with
faces and what ever else changes when a server is agentized.

I think code can be inserted into G p that will fire off J u on the
group just before entry,,, but don't know how to write it.

Re: run `J u' from Group Params

[Kevin Greiner]

Harry Putnam <hgp@sbcglobal.net> writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>> Harry Putnam <hgp@sbcglobal.net> writes:
>>
>>> I want to agentize a couple groups without going to the trouble of
>>> agentizing there server.  That is, just download with J u when I
>>> think about it.  Not have to go thru any bother agentizing the server.
>>
>> None of the agent command will function on a group whose server is not
>> agentized.
>
> I don't see that here.  Pressing the agent command J u on a group
> that has been agentized with J a (even though the server is not
> agentized seems to work just fine.

You are correct.  However, in my opinion, you are exploiting a bug.
The agent, as documented, should only accept groups on agentized
servers.

I'm not going to do anything about this right now.  I'm willing to see
how the public opinion goes.

> Assuming my catagories setup of cat Default = false
>                                 cat two     = true
>
>> As for actually agentizing the server, I'm don't understand why you
>> think that it is such a bother.  All that you need do is '^' in the
>> group buffer to open the server buffer then a 'J a' on the appropriate
>> server.
>
> Things happen to the groups when you do that.  For example:
> The face used to display all new messages in groups in 
> category default (predicate = false) changes from default to 
> gnus-summary-normal-uncached-face. Now one has to fiddle with 
> faces to get back to what you've come to expect when non-agentized.
> Not sure what else may change, and didn't really want to find out.

Well, that's the idea.  Marking a server as agentized changes the
internals.  I'm still surprised that 'J u' functioned.

As for the faces, you can customize gnus-summary-highlight.  All you
need do is delete the three cons cells that reference the
gnus*undownloaded-face.

>
>>> I wondered if I could run the J u command from Group params some how
>>> so that when ever I press <RET> on the group a hook runs J u 
>>> just before I enter.
>>
>> So the bother might not be on agentizing the server but in setting up
>> the agent group so that 'J u' will automatically fetch the desired
>> articles.  Well, that is a bit of a bother.  At the very least, you'll
>> need to set the agent predicate for the default group to true.  That
>> way, 'J u' will know to fetch all of the group's articles.
>
> That is exactly what I do.  Seems less troublesome than messing with
> faces and what ever else changes when a server is agentized.
>
> I think code can be inserted into G p that will fire off J u on the
> group just before entry,,, but don't know how to write it.

The following is completely untested.
  (dummy-variable (gnus-agent-fetch-group)) or
  (dummy-variable (gnus-agent-fetch-group "group.name"))

What you may not have noticed is that a new command has been added to
the summary buffer.  You can now execute 'J S' to do the same thing as
'J u' in the group buffer.

Kevin

Re: run `J u' from Group Params

[Harry Putnam]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> You are correct.  However, in my opinion, you are exploiting a bug.
> The agent, as documented, should only accept groups on agentized
> servers.
>
> I'm not going to do anything about this right now.  I'm willing to see
> how the public opinion goes.

It seems kind of handy to me, at least at this point.  Allows one
to grab a few qroups when the spirit moves them without getting into
config hassles

> Well, that's the idea.  Marking a server as agentized changes the
> internals.  I'm still surprised that 'J u' functioned.

One would expect internal changes yes.  But what I see are quite
external.  It doesn't seem to me that something like an unread face
should change.  I don't think it does in other changes like nnfolder
to nnml or the like.

> As for the faces, you can customize gnus-summary-highlight.  All you
> need do is delete the three cons cells that reference the
> gnus*undownloaded-face.

Well yes, I know how to customize faces, and in fact have them
customized already.  What I sought to avoid was having to redo it.

The easy answer was that agentizing a server is no hassle but in fact
it is. Compared to just downloading on demand with no further config.

>> I think code can be inserted into G p that will fire off J u on the
>> group just before entry,,, but don't know how to write it.
>
> The following is completely untested.
>   (dummy-variable (gnus-agent-fetch-group)) or
>   (dummy-variable (gnus-agent-fetch-group "group.name"))

Oddly, neither of those does the job.  Neither does `J S' in summary
buffer  as you suggested. At least not without agentizing the server.

`J u' seems to be the lone ranger bug that works for my needs.
But if that works, there's got to be some way to call it from G p.

This has the earmarks of a bug that can become a nice feature.

An example might be for people in temporary situations or for any
reason where they might not want to setup everything for the long
haul.

Say you want to fool around with a big pile of messages from some
group.  Maybe do extensive searches or something.  Its easy to just
`J a' the group then `J u' the group.  No muss no fuss.  Instant
database. 

Now to easily automate that for a short time, I thought G p might be
the place to do it.  Rather than redoing faces and who knows what
other configs.

Re: run `J u' from Group Params

[David Abrahams]

Harry Putnam <hgp@sbcglobal.net> writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
> This has the earmarks of a bug that can become a nice feature.
>
> An example might be for people in temporary situations or for any
> reason where they might not want to setup everything for the long
> haul.
>
> Say you want to fool around with a big pile of messages from some
> group.  Maybe do extensive searches or something.  Its easy to just
> `J a' the group then `J u' the group.  No muss no fuss.  Instant
> database. 
>
> Now to easily automate that for a short time, I thought G p might be
> the place to do it.  Rather than redoing faces and who knows what
> other configs.

I know "me too" posts are generally frowned upon, but, well, "me too"!

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com