*nntp-log* differences between M-g and g

*nntp-log* differences between M-g and g

[Mark Plaksin]

What's the difference between g in the Group buffer and M-g?  I know that g
will check all groups at the current level and M-g only checks the current
group, but if I set nntp-record-commands to t *nntp-log* shows different
commands depending on which keys I hit:

M-g:
20050130T123715.889 news.gmane.org GROUP gmane.emacs.sources

g:
20050130T123735.896 news.gmane.org GROUP gmane.emacs.sources
20050130T123736.181 news.gmane.org LIST ACTIVE gmane.emacs.sources
20050130T123736.317 news.gmane.org GROUP gmane.emacs.sources

M-g looks faster so I wonder why plain old g uses three commands.
Is it because of my configuration or something else?

Using CVS Gnus from today.

Re: *nntp-log* differences between M-g and g

[Katsumi Yamaoka]

>>>>> In <m3vf9ex17z.fsf@water.tss.usg.edu> Mark Plaksin wrote:

> What's the difference between g in the Group buffer and M-g?  I know that g
> will check all groups at the current level and M-g only checks the current
> group, but if I set nntp-record-commands to t *nntp-log* shows different
> commands depending on which keys I hit:

> M-g:
> 20050130T123715.889 news.gmane.org GROUP gmane.emacs.sources

> g:
> 20050130T123735.896 news.gmane.org GROUP gmane.emacs.sources
> 20050130T123736.181 news.gmane.org LIST ACTIVE gmane.emacs.sources
> 20050130T123736.317 news.gmane.org GROUP gmane.emacs.sources

It is natural if the `nntp-marks-is-evil' variable is nil (which
is the default).  This feature is described briefly in the
GNUS-NEWS file as follows:

--8<---------------cut here---------------start------------->8---
** The nntp back end store article marks in `~/News/marks'.

The directory can be changed using the (customizable) variable
`nntp-marks-directory', and marks can be disabled using the (back
end) variable `nntp-marks-is-evil'.  The advantage of this is that
you can copy `~/News/marks' (using rsync, scp or whatever) to another
Gnus installation, and it will realize what articles you have read
and marked.  The data in `~/News/marks' has priority over the same
data in `~/.newsrc.eld'.
--8<---------------cut here---------------end--------------->8---

> M-g looks faster so I wonder why plain old g uses three commands.
> Is it because of my configuration or something else?

> Using CVS Gnus from today.

If you think it is absolutely needless to you, you may set
`nntp-marks-is-evil' as t.

Re: *nntp-log* differences between M-g and g

[Simon Josefsson]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

>>>>>> In <m3vf9ex17z.fsf@water.tss.usg.edu> Mark Plaksin wrote:
>
>> What's the difference between g in the Group buffer and M-g?  I know that g
>> will check all groups at the current level and M-g only checks the current
>> group, but if I set nntp-record-commands to t *nntp-log* shows different
>> commands depending on which keys I hit:
>
>> M-g:
>> 20050130T123715.889 news.gmane.org GROUP gmane.emacs.sources
>
>> g:
>> 20050130T123735.896 news.gmane.org GROUP gmane.emacs.sources
>> 20050130T123736.181 news.gmane.org LIST ACTIVE gmane.emacs.sources
>> 20050130T123736.317 news.gmane.org GROUP gmane.emacs.sources
>
> It is natural if the `nntp-marks-is-evil' variable is nil (which
> is the default).  This feature is described briefly in the
> GNUS-NEWS file as follows:
>
> --8<---------------cut here---------------start------------->8---
> ** The nntp back end store article marks in `~/News/marks'.
>
> The directory can be changed using the (customizable) variable
> `nntp-marks-directory', and marks can be disabled using the (back
> end) variable `nntp-marks-is-evil'.  The advantage of this is that
> you can copy `~/News/marks' (using rsync, scp or whatever) to another
> Gnus installation, and it will realize what articles you have read
> and marked.  The data in `~/News/marks' has priority over the same
> data in `~/.newsrc.eld'.
> --8<---------------cut here---------------end--------------->8---

Why exactly does g have to issue two GROUP commands for the same
group?

And should 'g' really need to mess with the marks, except for
extending the active range?  Doesn't GROUP give Gnus enough
information to do that?

My NNTP juju is weak though.

Re: *nntp-log* differences between M-g and g

[Katsumi Yamaoka]

>>>>> In <ilu1xc2xyr9.fsf@latte.josefsson.org> Simon Josefsson wrote:

> Why exactly does g have to issue two GROUP commands for the same
> group?

> And should 'g' really need to mess with the marks, except for
> extending the active range?  Doesn't GROUP give Gnus enough
> information to do that?

That's a good point.  It is just an item to which the nntp marks
should be improved.

Re: *nntp-log* differences between M-g and g

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

>>>>> In <b9yd5vmmpki.fsf@jpl.org> Katsumi Yamaoka wrote:

>>>>>> In <ilu1xc2xyr9.fsf@latte.josefsson.org> Simon Josefsson wrote:

>> Why exactly does g have to issue two GROUP commands for the same
>> group?

>> And should 'g' really need to mess with the marks, except for
>> extending the active range?  Doesn't GROUP give Gnus enough
>> information to do that?

> That's a good point.  It is just an item to which the nntp marks
> should be improved.

The reason two GROUP commands issued when typing `g' is that
nntp.el provides the `nntp-request-update-info' function which
returns non-nil.  Because of this,
gnus-get-unread-articles-in-group calls nntp-request-group which
issues the GROUP command by way of gnus-activate-group.  I think
to issue those commands is of no use to manage the nntp marks.
The patch below avoids those futilities.  Could anyone test it?
I hope the people who are using the nntp marks in daily life
test it.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 253 bytes --]

--- nntp.el~	2004-11-15 03:59:37 +0000
+++ nntp.el	2005-01-31 12:47:01 +0000
@@ -1074,7 +1074,7 @@
 				(list (cons (car seen) (car seen)))
 			      seen)))
       (nnheader-message 8 "Updating marks for %s...done" group))
-    info))
+    nil))
 
 
 

[-- Attachment #3: Type: text/plain, Size: 9 bytes --]

Regards,

Re: *nntp-log* differences between M-g and g

[Mark Plaksin]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> The reason two GROUP commands issued when typing `g' is that
> nntp.el provides the `nntp-request-update-info' function which
> returns non-nil.  Because of this,
> gnus-get-unread-articles-in-group calls nntp-request-group which
> issues the GROUP command by way of gnus-activate-group.  I think
> to issue those commands is of no use to manage the nntp marks.
> The patch below avoids those futilities.  Could anyone test it?

It does make `g' faster--it only does one command per group.

> I hope the people who are using the nntp marks in daily life
> test it.

I don't really use marks--I always run Emacs on the same machine.  But one
day soon I may use it on multiple machines so I appreciate the fact that I
can let nntp-marks-is-evil stay nil *and* have `g' be speedy :)  Thanks!

Re: *nntp-log* differences between M-g and g

[Katsumi Yamaoka]

>>>>> In <b9ymzup69x0.fsf@jpl.org> Katsumi Yamaoka wrote:

> The patch below avoids those futilities.  Could anyone test it?
> I hope the people who are using the nntp marks in daily life
> test it.

> --- nntp.el~	2004-11-15 03:59:37 +0000
> +++ nntp.el	2005-01-31 12:47:01 +0000

Does nobody use nntp marks? ;-p

I used it for a day and realized I can live with it.  The change
prevents Gnus being slowed down.  Since I didn't find out any
harm, I've installed it in the Gnus trunk.

BTW, I noticed another usefulness of nntp marks.  When I read
articles temporarily using Gnus on another Emacs-B on the same
computer while running Gnus on Emacs-A, the information that
those articles have already been read is propagated to A.  What
I should do then on A is simply to type `g' or `M-g'.

Re: *nntp-log* differences between M-g and g

[Ralf Angeli]

* Katsumi Yamaoka (2005-01-31) writes:

> The reason two GROUP commands issued when typing `g' is that
> nntp.el provides the `nntp-request-update-info' function which
> returns non-nil.  Because of this,
> gnus-get-unread-articles-in-group calls nntp-request-group which
> issues the GROUP command by way of gnus-activate-group.  I think
> to issue those commands is of no use to manage the nntp marks.
> The patch below avoids those futilities.  Could anyone test it?
> I hope the people who are using the nntp marks in daily life
> test it.

I've been using this since you posted the patch and haven't
encountered any problems.

Before I patched the sources I did a `cvs up'.  After installing Gnus
there were some groups which showed up with unread articles although
they were marked as read before.  This problem went away after using
`c' on those groups.  As I updated the sources before applying the
patch, I don't know if this oddity is a result of your patch or
another change.

-- 
Ralf

Re: *nntp-log* differences between M-g and g

[Simon Josefsson]

Ralf Angeli <dev.null@iwi.uni-sb.de> writes:

> Before I patched the sources I did a `cvs up'.  After installing Gnus
> there were some groups which showed up with unread articles although
> they were marked as read before.  This problem went away after using
> `c' on those groups.  As I updated the sources before applying the
> patch, I don't know if this oddity is a result of your patch or
> another change.

FWIW, I noticed the same thing.  Not reproducible, though, and I have
no problems now.

Re: *nntp-log* differences between M-g and g

[Katsumi Yamaoka]

>>>>> In <iluacqnuwl9.fsf@latte.josefsson.org> Simon Josefsson wrote:

> Ralf Angeli <dev.null@iwi.uni-sb.de> writes:

>> Before I patched the sources I did a `cvs up'.  After installing Gnus
>> there were some groups which showed up with unread articles although
>> they were marked as read before.  This problem went away after using
>> `c' on those groups.  As I updated the sources before applying the
>> patch, I don't know if this oddity is a result of your patch or
>> another change.

> FWIW, I noticed the same thing.  Not reproducible, though, and I have
> no problems now.

I figured out the reason it occurred.  It was caused because of
the old marks files in your systems.  `nntp-marks-changed-p'
used `not' and `equal' to compare the time that the marks file
was read last and the present timestamp of the marks file.  It
should be `<', not `/='.  I've fixed it in CVS.

Re: *nntp-log* differences between M-g and g

[Katsumi Yamaoka]

>>>>> In <b9ywttr2nu8.fsf@jpl.org> Katsumi Yamaoka wrote:

> I figured out the reason it occurred.  It was caused because of
> the old marks files in your systems.  `nntp-marks-changed-p'
> used `not' and `equal' to compare the time that the marks file
> was read last and the present timestamp of the marks file.  It
> should be `<', not `/='.  I've fixed it in CVS.

The reason I wrote that unread articles was increased when
`nntp-marks-is-evil' was restored into nil was partially
incorrect.  Here's a corrected version:

`nntp-marks-changed-p' used `not' and `equal' to compare time-A
and time-B.  Where time-A is the time that Gnus updated the
marks info (i.e., the time that a user read articles) and time-B
is the present timestamp of the marks file.

(Phew, it's hard to explain with my poor English.)

Re: *nntp-log* differences between M-g and g

[Ralf Angeli]

* Katsumi Yamaoka (2005-02-03) writes:

> `nntp-marks-changed-p' used `not' and `equal' to compare time-A
> and time-B.  Where time-A is the time that Gnus updated the
> marks info (i.e., the time that a user read articles) and time-B
> is the present timestamp of the marks file.
>
> (Phew, it's hard to explain with my poor English.)

You don't want to hear or read me trying that in Japanese.  I just
recently learned that you have three alphabets.  かっこいい!

-- 
Ralf