No Gnus todo item

No Gnus todo item

[Simon Josefsson]

A thread on gnu.emacs.gnus reminded me of a simple thing that could be
useful to do in No Gnus:

Pressing M-x gnus RET should load gnus, load .newsrc.eld etc, and
display the group buffer.  This shouldn't take longer than 5s.  This
is in line with the GUI design criteria "minimize time the user can't
access the user interface".

Fetching new mail, and updating the article counts should be done
after pressing 'g'.

Implementing asynchronous updating of article counts while you browse
the group buffer earns bonus points.

Re: No Gnus todo item

[Reiner Steib]

On Thu, May 08 2003, Simon Josefsson wrote:

> A thread on gnu.emacs.gnus reminded me of a simple thing that could be
> useful to do in No Gnus:

What is the policy for the `todo' file included in CVS (an the
tar-ball)?  The last addition is dated 2002/02/15.  What's the story?

I think your and many other suggestions [1] should be written there.
Else most of them will probably be forgotten after a while.

Bye, Reiner.

[1] E.g. from the thread "Ideas for .no Gnus",
    <news:u8ytpvybg.fsf@hschmi22.userfqdn.rz-online.de>.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: No Gnus todo item

[Simon Josefsson]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> What is the policy for the `todo' file included in CVS (an the
> tar-ball)?  The last addition is dated 2002/02/15.  What's the story?
>
> I think your and many other suggestions [1] should be written there.
> Else most of them will probably be forgotten after a while.

A distributed writable nntodo group seems like a more Gnusish
approach, then each todo item can include discussion too.

This seems similar to adding some meta-data on top of a nntp group to
make it more useful as a bug tracking system.

But someone would have to implement this todo/bts first.

Re: No Gnus todo item

[Bill White]

On Thu May 08 2003 at 08:26, Simon Josefsson <jas@extundo.com> said:

> Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
>
>> What is the policy for the `todo' file included in CVS (an the
>> tar-ball)?  The last addition is dated 2002/02/15.  What's the story?
>>
>> I think your and many other suggestions [1] should be written
>> there.  Else most of them will probably be forgotten after a while.
>
> A distributed writable nntodo group seems like a more Gnusish
> approach, then each todo item can include discussion too.

That would be really nifty, and a good reason to start using nntodo
(isn't that one of Kai's things?).

How would the group be distributed? (I'm still not hip to some of
this lingo.)

Cheers -

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

Re: No Gnus todo item

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
>
>> What is the policy for the `todo' file included in CVS (an the
>> tar-ball)?  The last addition is dated 2002/02/15.  What's the story?
>>
>> I think your and many other suggestions [1] should be written there.
>> Else most of them will probably be forgotten after a while.
>
> A distributed writable nntodo group seems like a more Gnusish
> approach, then each todo item can include discussion too.

My suggestion is to add "distributed writable nntodo" to the existing
todo file, along with the other items.

This has the advantage that keeping the todo list can be done before
executing any other todo items :-)
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: No Gnus todo item

[Lars Magne Ingebrigtsen]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> I think your and many other suggestions [1] should be written there.
> Else most of them will probably be forgotten after a while.

Good ideas have a tendency to pop up after a while if we forget them,
in my experience.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: No Gnus todo item

[Bill White]

On Thu May 08 2003 at 06:07, Simon Josefsson <jas@extundo.com> said:

> Pressing M-x gnus RET should load gnus, load .newsrc.eld etc, and
> display the group buffer.  This shouldn't take longer than 5s.  This
> is in line with the GUI design criteria "minimize time the user can't
> access the user interface".
>
> Fetching new mail, and updating the article counts should be done
> after pressing 'g'.

That's an excellent idea!  Occasionally, I get into a situation where
I need to load without downloading because I've screwed something up,
so I have to edit mail-sources temporarily to keep new mail out of
the mess.

Cheers -

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

Re: No Gnus todo item

[Ted Zlatanov]

On Thu, 08 May 2003, billw@wolfram.com wrote:
> On Thu May 08 2003 at 06:07, Simon Josefsson <jas@extundo.com> said:
> 
>> Pressing M-x gnus RET should load gnus, load .newsrc.eld etc, and
>> display the group buffer.  This shouldn't take longer than 5s.
>> This is in line with the GUI design criteria "minimize time the
>> user can't access the user interface".
>>
>> Fetching new mail, and updating the article counts should be done
>> after pressing 'g'.
> 
> That's an excellent idea!  Occasionally, I get into a situation
> where I need to load without downloading because I've screwed
> something up, so I have to edit mail-sources temporarily to keep new
> mail out of the mess.

But that's confusing to new users, every MUA I have used will load new
mail at startup.  May I suggest either a variable like
gnus-startup-without-scan or a function gnus-fast?  The function seems
the better solution.  You startup gnus with emacs -f gnus-fast and
then `g' is still bound to the gnus function so things work like they
always have.

In fact, it seems like the gnus function already has a dont-connect
parameter.  Is that not useful?

Thanks
Ted

Re: No Gnus todo item

[Simon Josefsson]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 08 May 2003, billw@wolfram.com wrote:
>> On Thu May 08 2003 at 06:07, Simon Josefsson <jas@extundo.com> said:
>> 
>>> Pressing M-x gnus RET should load gnus, load .newsrc.eld etc, and
>>> display the group buffer.  This shouldn't take longer than 5s.
>>> This is in line with the GUI design criteria "minimize time the
>>> user can't access the user interface".
>>>
>>> Fetching new mail, and updating the article counts should be done
>>> after pressing 'g'.
>> 
>> That's an excellent idea!  Occasionally, I get into a situation
>> where I need to load without downloading because I've screwed
>> something up, so I have to edit mail-sources temporarily to keep new
>> mail out of the mess.
>
> But that's confusing to new users, every MUA I have used will load new
> mail at startup.

Before displaying the user interface?  Most MUAs I recall using
(Mozilla, Evolution, Kmail, Outlook, Pine) display the GUI immediately
and then some of them (exceptions are Pine and Outlook, as far as I
can recall) will continue to update the message counts in the
background.

> May I suggest either a variable like gnus-startup-without-scan or a
> function gnus-fast?  The function seems the better solution.  You
> startup gnus with emacs -f gnus-fast and then `g' is still bound to
> the gnus function so things work like they always have.
>
> In fact, it seems like the gnus function already has a dont-connect
> parameter.  Is that not useful?

It is, and it may be tested by using M-x gnus-no-server RET or M-x
gnus-unplugged RET depending on preference.  I'm talking about the
default behavior.

Perhaps the idea doesn't make sense unless the asynchronous update of
read counts is implemented.  If so, the consider that implemented too,
when thinking about the feature.

Re: No Gnus todo item

[Ted Zlatanov]

On Thu, 08 May 2003, jas@extundo.com wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> But that's confusing to new users, every MUA I have used will load
>> new mail at startup.
> 
> Before displaying the user interface?  Most MUAs I recall using
> (Mozilla, Evolution, Kmail, Outlook, Pine) display the GUI
> immediately and then some of them (exceptions are Pine and Outlook,
> as far as I can recall) will continue to update the message counts
> in the background.

What you suggest would be nice, but Gnus does display a read-only
interface while fetching the mail.  You would like it to be
interactive, I think - which is a good idea.

>> May I suggest either a variable like gnus-startup-without-scan or a
>> function gnus-fast?  The function seems the better solution.  You
>> startup gnus with emacs -f gnus-fast and then `g' is still bound to
>> the gnus function so things work like they always have.
>>
>> In fact, it seems like the gnus function already has a dont-connect
>> parameter.  Is that not useful?
> 
> It is, and it may be tested by using M-x gnus-no-server RET or M-x
> gnus-unplugged RET depending on preference.  I'm talking about the
> default behavior.
> 
> Perhaps the idea doesn't make sense unless the asynchronous update
> of read counts is implemented.  If so, the consider that implemented
> too, when thinking about the feature.

I think we'd need asynchronous mail fetching and article count
updates to do what you want.  It's a very good goal, but it might
require a major rewrite of Gnus.

Ted

Re: No Gnus todo item

[Simon Josefsson]

Ted Zlatanov <tzz@lifelogs.com> writes:

>>> May I suggest either a variable like gnus-startup-without-scan or a
>>> function gnus-fast?  The function seems the better solution.  You
>>> startup gnus with emacs -f gnus-fast and then `g' is still bound to
>>> the gnus function so things work like they always have.
>>>
>>> In fact, it seems like the gnus function already has a dont-connect
>>> parameter.  Is that not useful?
>> 
>> It is, and it may be tested by using M-x gnus-no-server RET or M-x
>> gnus-unplugged RET depending on preference.  I'm talking about the
>> default behavior.
>> 
>> Perhaps the idea doesn't make sense unless the asynchronous update
>> of read counts is implemented.  If so, the consider that implemented
>> too, when thinking about the feature.
>
> I think we'd need asynchronous mail fetching and article count
> updates to do what you want.  It's a very good goal, but it might
> require a major rewrite of Gnus.

I don't think it is requires much work, it should be possible to do
even without touching existing code, I think.

A somewhat IMAP specific incarnation of this idea would run a function
via the idle timer, have it pick one group, send off a few commands to
the server to request information, and return.  Takes a few
milliseconds, max.  When it is invoked the next time, it looks if it
has received outstanding requests, if so, it parses them and frob a
few Gnus data structure, redraws one line of the group buffer, and
returns.  This goes on until all groups are updated.

I would agree that doing this for mail-sources and client-side
filtering is harder, but the above approach should work for nnml,
nnfolder, nntp, nnmaildir and nnimap.

Re: No Gnus todo item

[Ted Zlatanov]

On Fri, 09 May 2003, jas@extundo.com wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:

>> I think we'd need asynchronous mail fetching and article count
>> updates to do what you want.  It's a very good goal, but it might
>> require a major rewrite of Gnus.
> 
> I don't think it is requires much work, it should be possible to do
> even without touching existing code, I think.

Simon, you would certainly know more about this than me.  My
impression was that there are a lot of global variables that relate to
the "current" newsgroup, which might be a problem if we try to be
asynchronous.  I hope you find the time to implement this.

Ted