Problem with org-gnus-follow-link

Problem with org-gnus-follow-link

[Ulf Stegemann]

(Org as of 2008-12-08, Gnus/5.110009 (No Gnus v0.9), XEmacs/21.4.21 (linux))

Hi,

I've encountered a problem with `org-gnus-follow-link' which sometimes
fails to fetch the appropriate article in Gnus. This does not happen
when a buffer is visiting the group the link points to.

After a bit of investigation I found out that the problem is
`gnus-group-read-group' which is called by `org-gnus-follow-link'.
`gnus-group-read-group' does not return an article but nil if the last
message of the group has been deleted (this is re-producable here).
Inserting a new article into the group (e.g. by moving an article from
that group into the same group again) solves the problem.

I'm not quite sure how to address the problem or the other way round: is
this a bug in `gnus-group-read-group' that should never return nil if
the first argument is 1 and there's at least one article in the group or
is it a bug in `org-gnus-follow-link' that counts on
`gnus-group-read-group' returning an article.

Ulf

Re: Problem with org-gnus-follow-link

[Tassilo Horn]

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

Ulf Stegemann <ulf-news@zeitform.de> writes:

Hi Ulf,

> After a bit of investigation I found out that the problem is
> `gnus-group-read-group' which is called by `org-gnus-follow-link'.
> `gnus-group-read-group' does not return an article but nil if the last
> message of the group has been deleted (this is re-producable here).

Not really.  But it won't open the Summary buffer if the last article
was deleted.

Please try this patch and report back if it works.


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

diff --git a/lisp/org-gnus.el b/lisp/org-gnus.el
index 1058b0d..5adfd7e 100644
--- a/lisp/org-gnus.el
+++ b/lisp/org-gnus.el
@@ -144,6 +144,7 @@ If `org-store-link' was called with a prefix arg the meaning of
 
 (defun org-gnus-open (path)
   "Follow the Gnus message or folder link specified by PATH."
+  (setq path (substring-no-properties path))
   (let (group article)
     (if (not (string-match "\\`\\([^#]+\\)\\(#\\(.*\\)\\)?" path))
 	(error "Error in Gnus link"))
@@ -157,13 +158,9 @@ If `org-store-link' was called with a prefix arg the meaning of
   (funcall (cdr (assq 'gnus org-link-frame-setup)))
   (if gnus-other-frame-object (select-frame gnus-other-frame-object))
   (cond ((and group article)
-	 (gnus-group-read-group 1 nil group)
-	 (gnus-summary-goto-article
-	  (if (string-match "[^0-9]" article)
-	      article
-	    (string-to-number article))
-	  nil t))
-	(group (gnus-group-jump-to-group group))))
+         (gnus-group-read-group t nil group)
+         (gnus-summary-goto-article article nil t))
+        (group (gnus-group-jump-to-group group))))
 
 (defun org-gnus-no-new-news ()
   "Like `M-x gnus' but doesn't check for new news."

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


Bye,
Tassilo

[-- Attachment #4: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Problem with org-gnus-follow-link

[Ulf Stegemann]

Hi Tassilo,

Tassilo Horn <tassilo@member.fsf.org> wrote:

> Please try this patch and report back if it works.

[...]

> -	 (gnus-group-read-group 1 nil group)
> -	 (gnus-summary-goto-article
> -	  (if (string-match "[^0-9]" article)
> -	      article
> -	    (string-to-number article))
> -	  nil t))
> -	(group (gnus-group-jump-to-group group))))
> +         (gnus-group-read-group t nil group)
> +         (gnus-summary-goto-article article nil t))
> +        (group (gnus-group-jump-to-group group))))

this works in principle but is not really an option. Since first
argument 't' to `gnus-group-read-group' makes every article readable in
a group, building the summary buffer takes far too long for groups with
many articles. Try it with groups containing 10.000+ articles and you'll
see what I mean.

Ulf

Re: Problem with org-gnus-follow-link

[Tassilo Horn]

Ulf Stegemann <ulf-news@zeitform.de> writes:

Hi Ulf,

> this works in principle but is not really an option. Since first
> argument 't' to `gnus-group-read-group' makes every article readable
> in a group, building the summary buffer takes far too long for groups
> with many articles. Try it with groups containing 10.000+ articles and
> you'll see what I mean.

Normally you should be asked how many articles you wanna see, if the
group is big.  If that's not the case for you, you have customized
something which controls that.

But indeed, it doesn't solve the real problem.  Even if it asks and the
user says 100 but deleted the last 100 messages in that group before,
it'll react as it is now.

I'll ask at the gnus towers...

Bye,
Tassilo

Re: Problem with org-gnus-follow-link

[Tassilo Horn]

Hi Ulf,

please try this one:

--8<---------------cut here---------------start------------->8---
diff --git a/lisp/org-gnus.el b/lisp/org-gnus.el
index 7231538..05bed5b 100644
--- a/lisp/org-gnus.el
+++ b/lisp/org-gnus.el
@@ -157,12 +157,9 @@ If `org-store-link' was called with a prefix arg the meaning of
   (funcall (cdr (assq 'gnus org-link-frame-setup)))
   (if gnus-other-frame-object (select-frame gnus-other-frame-object))
   (cond ((and group article)
+	 (gnus-activate-group group t)
 	 (gnus-group-read-group 1 nil group)
-	 (gnus-summary-goto-article
-	  (if (string-match "[^0-9]" article)
-	      article
-	    (string-to-number article))
-	  nil t))
+	 (gnus-summary-goto-article article nil t))
 	(group (gnus-group-jump-to-group group))))
 
 (defun org-gnus-no-new-news ()
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

Re: Problem with org-gnus-follow-link

[Ulf Stegemann]

Hi Tassilo,

Tassilo Horn <tassilo@member.fsf.org> wrote:

> Ulf Stegemann <ulf-news@zeitform.de> writes:
>
>> this works in principle but is not really an option. Since first
>> argument 't' to `gnus-group-read-group' makes every article readable
>> in a group, building the summary buffer takes far too long for groups
>> with many articles. Try it with groups containing 10.000+ articles and
>> you'll see what I mean.
>
> Normally you should be asked how many articles you wanna see, if the
> group is big.  If that's not the case for you, you have customized
> something which controls that.

hmmm, I'm not aware I've ever done something like that but since my Gnus
config evolved over several years I cannot completely exclude this
possibility. I know the behaviour you've mentioned from nntp groups,
maybe it's different with the nnml backend (I was actually testing this
with nnml).

> But indeed, it doesn't solve the real problem.  Even if it asks and the
> user says 100 but deleted the last 100 messages in that group before,
> it'll react as it is now.

D'accord.

Tassilo Horn <tassilo@member.fsf.org> wrote:

> please try this one:
>
> diff --git a/lisp/org-gnus.el b/lisp/org-gnus.el
> index 7231538..05bed5b 100644
> --- a/lisp/org-gnus.el
> +++ b/lisp/org-gnus.el
> @@ -157,12 +157,9 @@ If `org-store-link' was called with a prefix arg the meaning of
>    (funcall (cdr (assq 'gnus org-link-frame-setup)))
>    (if gnus-other-frame-object (select-frame gnus-other-frame-object))
>    (cond ((and group article)
> +	 (gnus-activate-group group t)
>  	 (gnus-group-read-group 1 nil group)
> -	 (gnus-summary-goto-article
> -	  (if (string-match "[^0-9]" article)
> -	      article
> -	    (string-to-number article))
> -	  nil t))
> +	 (gnus-summary-goto-article article nil t))
>  	(group (gnus-group-jump-to-group group))))
>  
>  (defun org-gnus-no-new-news ()

Unfortunately, it doesn't work. The behaviour is the same as with the
original version: jumping to the article works if the last article in
the group in question hasn't been deleted, otherwise it fails.

Ulf

Re: Problem with org-gnus-follow-link

[Tassilo Horn]

Ulf Stegemann <ulf-news@zeitform.de> writes:

Hi Ulf,

>> please try this one:
>>
>> diff --git a/lisp/org-gnus.el b/lisp/org-gnus.el
>> index 7231538..05bed5b 100644
>> --- a/lisp/org-gnus.el
>> +++ b/lisp/org-gnus.el
>> @@ -157,12 +157,9 @@ If `org-store-link' was called with a prefix arg the meaning of
>>    (funcall (cdr (assq 'gnus org-link-frame-setup)))
>>    (if gnus-other-frame-object (select-frame gnus-other-frame-object))
>>    (cond ((and group article)
>> +	 (gnus-activate-group group t)
>>  	 (gnus-group-read-group 1 nil group)
>> -	 (gnus-summary-goto-article
>> -	  (if (string-match "[^0-9]" article)
>> -	      article
>> -	    (string-to-number article))
>> -	  nil t))
>> +	 (gnus-summary-goto-article article nil t))
>>  	(group (gnus-group-jump-to-group group))))
>>  
>>  (defun org-gnus-no-new-news ()
>
> Unfortunately, it doesn't work. The behaviour is the same as with the
> original version: jumping to the article works if the last article in
> the group in question hasn't been deleted, otherwise it fails.

I tried exactly that and it solved the problem for me.  Did you apply
the patch and eval the function thereafter?  Or did you recompile
org-mode if you restarted emacs for the test?

Bye,
Tassilo

Re: Problem with org-gnus-follow-link

[Ulf Stegemann]

Hi Tassilo,

Tassilo Horn <tassilo@member.fsf.org> wrote:

> Ulf Stegemann <ulf-news@zeitform.de> writes:
>
>>> please try this one:
>>>
>>> diff --git a/lisp/org-gnus.el b/lisp/org-gnus.el
>>> index 7231538..05bed5b 100644
>>> --- a/lisp/org-gnus.el
>>> +++ b/lisp/org-gnus.el
>>> @@ -157,12 +157,9 @@ If `org-store-link' was called with a prefix arg the meaning of
>>>    (funcall (cdr (assq 'gnus org-link-frame-setup)))
>>>    (if gnus-other-frame-object (select-frame gnus-other-frame-object))
>>>    (cond ((and group article)
>>> +	 (gnus-activate-group group t)
>>>  	 (gnus-group-read-group 1 nil group)
>>> -	 (gnus-summary-goto-article
>>> -	  (if (string-match "[^0-9]" article)
>>> -	      article
>>> -	    (string-to-number article))
>>> -	  nil t))
>>> +	 (gnus-summary-goto-article article nil t))
>>>  	(group (gnus-group-jump-to-group group))))
>>>  
>>>  (defun org-gnus-no-new-news ()
>>
>> Unfortunately, it doesn't work. The behaviour is the same as with the
>> original version: jumping to the article works if the last article in
>> the group in question hasn't been deleted, otherwise it fails.
>
> I tried exactly that and it solved the problem for me.  Did you apply
> the patch and eval the function thereafter?  Or did you recompile
> org-mode if you restarted emacs for the test?

huh, that's strange. The patched version was really in effect here when
the tests failed. I've just updated Gnus to the latest (CVS) version but
again, it's not fixed for me ... and maybe it cannot be fixed. The whole
subject reminds me of the old Gnus "wrong article count problem". AFAIK
there was never a solution for this apart from moving articles into
groups or temporarily renaming groups (see also
`gnus-group-compact-group').

Ulf

Re: Problem with org-gnus-follow-link

[Tassilo Horn]

Ulf Stegemann <ulf-news@zeitform.de> writes:

Hi Ulf,

> huh, that's strange. The patched version was really in effect here
> when the tests failed. I've just updated Gnus to the latest (CVS)
> version but again, it's not fixed for me ... and maybe it cannot be
> fixed. The whole subject reminds me of the old Gnus "wrong article
> count problem".

Exactly that's the problem.

Please do a test for me:

1. Enter a group in Gnus
2. Delete the last article
3. Exit summary
4. Try `C-u 1 RET' on the group.  It should issue "No unread news".
5. Do `M-: (gnus-activate-group "<group-name>" t) RET'
6. Try `C-u 1 RET' on the group again.  Now it should be opened and
   summary should contain one article.

If you get different results it seems to be due to your gnus version.  I
use the one included in emacs 23 and update daily, so it might be more
up to date than your copy.  Maybe try to update yours, too.

Bye,
Tassilo

Re: Problem with org-gnus-follow-link

[Ulf Stegemann]

Hi Tassilo,

Tassilo Horn <tassilo@member.fsf.org> wrote:

> Ulf Stegemann <ulf-news@zeitform.de> writes:
>
>> huh, that's strange. The patched version was really in effect here
>> when the tests failed. I've just updated Gnus to the latest (CVS)
>> version but again, it's not fixed for me ... and maybe it cannot be
>> fixed. The whole subject reminds me of the old Gnus "wrong article
>> count problem".
>
> Exactly that's the problem.
>
> Please do a test for me:
>
> 1. Enter a group in Gnus
> 2. Delete the last article
> 3. Exit summary
> 4. Try `C-u 1 RET' on the group.  It should issue "No unread news".
> 5. Do `M-: (gnus-activate-group "<group-name>" t) RET'
> 6. Try `C-u 1 RET' on the group again.  Now it should be opened and
>    summary should contain one article.
>
> If you get different results it seems to be due to your gnus version.  I
> use the one included in emacs 23 and update daily, so it might be more
> up to date than your copy.  Maybe try to update yours, too.

done that. I was under the wrong impression that the CVS on cvs.gnus.org
holds the latest version of Gnus but it seems it just has the release
from 1st May. It seems that latest Gnus is now available from the Emacs
CVS only (sorry for my ignorance). I installed that version here (5.13
as of today, see User-Agent header) but again the summary buffer is not
opened. Do you know (and remember) what has changed in Gnus sources
since 1st May that made the "wrong article count"-bug go away?

Ulf

Re: Problem with org-gnus-follow-link

[Tassilo Horn]

Ulf Stegemann <ulf-news@zeitform.de> writes:

Hi Ulf,

>> Please do a test for me:
>>
>> 1. Enter a group in Gnus
>> 2. Delete the last article
>> 3. Exit summary
>> 4. Try `C-u 1 RET' on the group.  It should issue "No unread news".
>> 5. Do `M-: (gnus-activate-group "<group-name>" t) RET'
>> 6. Try `C-u 1 RET' on the group again.  Now it should be opened and
>>    summary should contain one article.
>>
>> If you get different results it seems to be due to your gnus version.
>> I use the one included in emacs 23 and update daily, so it might be
>> more up to date than your copy.  Maybe try to update yours, too.
>
> done that. I was under the wrong impression that the CVS on
> cvs.gnus.org holds the latest version of Gnus but it seems it just has
> the release from 1st May. It seems that latest Gnus is now available
> from the Emacs CVS only (sorry for my ignorance).

There's nothing to excuse.  I wasn't aware that the versions diverged
that much, too.

> I installed that version here (5.13 as of today, see User-Agent
> header)

How?  Did you checkout GNU Emacs and copy all the gnus-related files
somewhere?

> but again the summary buffer is not opened.

That's really strange.  BTW: What backend did you use for testing?  I
used nnimap.  MAybe that makes the difference...

> Do you know (and remember) what has changed in Gnus sources since 1st
> May that made the "wrong article count"-bug go away?

No, till that date there were 111 commits in emacs/lisp/gnus.

Bye,
Tassilo

Re: Problem with org-gnus-follow-link

[Ulf Stegemann]

Hi Tassilo,

Tassilo Horn <tassilo@member.fsf.org> wrote:

> Ulf Stegemann <ulf-news@zeitform.de> writes:
>
>>> Please do a test for me:
>>>
>>> 1. Enter a group in Gnus
>>> 2. Delete the last article
>>> 3. Exit summary
>>> 4. Try `C-u 1 RET' on the group.  It should issue "No unread news".
>>> 5. Do `M-: (gnus-activate-group "<group-name>" t) RET'
>>> 6. Try `C-u 1 RET' on the group again.  Now it should be opened and
>>>    summary should contain one article.
>>>
>>> If you get different results it seems to be due to your gnus version.
>>> I use the one included in emacs 23 and update daily, so it might be
>>> more up to date than your copy.  Maybe try to update yours, too.
>>
>> done that. I was under the wrong impression that the CVS on
>> cvs.gnus.org holds the latest version of Gnus but it seems it just has
>> the release from 1st May. It seems that latest Gnus is now available
>> from the Emacs CVS only (sorry for my ignorance).
>
> There's nothing to excuse.  I wasn't aware that the versions diverged
> that much, too.

yes, I really was surprised ... especially as gnus.org offers a 'nightly
snapshot' that also seems to be the version as of 1st May.

>> I installed that version here (5.13 as of today, see User-Agent
>> header)
>
> How?  Did you checkout GNU Emacs and copy all the gnus-related files
> somewhere?

Exactly, I got emacs sources by CVS and used the lisp/gnus/ files (plus
some other lisp files from gnus.org that where missing and XEmacs seems
to require). Byte-Compiling here with XEmacs 21.4 went smoothly, Gnus
runs as before ... at least until now ;)

>> but again the summary buffer is not opened.
>
> That's really strange.  BTW: What backend did you use for testing?  I
> used nnimap.  MAybe that makes the difference...

Gotcha! It works on nnimap but not on nnml which I was using for the
tests. Maybe you'll try this with your installation as well. If it fails
for nnml groups for you, too, that might be an important point for the
discussion you've started on emacs.gnus.general.

Ulf

Re: Problem with org-gnus-follow-link

[Tassilo Horn]

Ulf Stegemann <ulf-news@zeitform.de> writes:

>>> but again the summary buffer is not opened.
>>
>> That's really strange.  BTW: What backend did you use for testing?  I
>> used nnimap.  MAybe that makes the difference...
>
> Gotcha! It works on nnimap but not on nnml which I was using for the
> tests. Maybe you'll try this with your installation as well.

I can reproduce it with nnml.  Damn!  I posted to ding.  Did you get a
"I want a string but got nil" error, too?

> If it fails for nnml groups for you, too, that might be an important
> point for the discussion you've started on emacs.gnus.general.

Yeah, done so.

Bye,
Tassilo

Re: Problem with org-gnus-follow-link

[Tassilo Horn]

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

Hi Ulf,

please try this one.


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

diff --git a/lisp/org-gnus.el b/lisp/org-gnus.el
index 7231538..3cf4b1e 100644
--- a/lisp/org-gnus.el
+++ b/lisp/org-gnus.el
@@ -74,11 +74,11 @@ If `org-store-link' was called with a prefix arg the meaning of
     (if (and (string-match "^nntp" group) ;; Only for nntp groups
 	     (org-xor current-prefix-arg
 		      org-gnus-prefer-web-links))
-	(concat (if (string-match "gmane" unprefixed-group)
-		    "http://news.gmane.org/"
-		  "http://groups.google.com/group/")
-		unprefixed-group)
-      (concat "gnus:" group))))
+	(org-make-link (if (string-match "gmane" unprefixed-group)
+			   "http://news.gmane.org/"
+			 "http://groups.google.com/group/")
+		       unprefixed-group)
+      (org-make-link "gnus:" group))))
 
 (defun org-gnus-article-link (group newsgroups message-id x-no-archive)
   "Create a link to a Gnus article.
@@ -115,7 +115,7 @@ If `org-store-link' was called with a prefix arg the meaning of
       (unless group (error "Not on a group"))
       (org-store-link-props :type "gnus" :group group)
       (setq desc (org-gnus-group-link group)
-	    link (org-make-link desc))
+	    link desc)
       (org-add-link-props :link link :description desc)
       link))
 
@@ -149,6 +149,10 @@ If `org-store-link' was called with a prefix arg the meaning of
 	(error "Error in Gnus link"))
     (setq group (match-string 1 path)
 	  article (match-string 3 path))
+    (when group
+      (setq group (substring-no-properties group)))
+    (when article
+      (setq article (substring-no-properties article)))
     (org-gnus-follow-link group article)))
 
 (defun org-gnus-follow-link (&optional group article)
@@ -156,13 +160,16 @@ If `org-store-link' was called with a prefix arg the meaning of
   (require 'gnus)
   (funcall (cdr (assq 'gnus org-link-frame-setup)))
   (if gnus-other-frame-object (select-frame gnus-other-frame-object))
+  (when group
+    (setq group (substring-no-properties group)))
+  (when article
+    (setq article (substring-no-properties article)))
   (cond ((and group article)
-	 (gnus-group-read-group 1 nil group)
-	 (gnus-summary-goto-article
-	  (if (string-match "[^0-9]" article)
-	      article
-	    (string-to-number article))
-	  nil t))
+	 (gnus-activate-group group t)
+	 (unless (gnus-group-read-group 1 nil group)
+	   ;; Try again with a bigger number of messages.
+	   (gnus-group-read-group (1- gnus-large-newsgroup) nil group))
+	 (gnus-summary-goto-article article nil t))
 	(group (gnus-group-jump-to-group group))))
 
 (defun org-gnus-no-new-news ()

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


Bye,
Tassilo
-- 
      "OS's and GUI's come and go, only Emacs has lasting power."
          Per Abrahamsen in <rjbsysc7n1.fsf@zuse.dina.kvl.dk>

[-- Attachment #4: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Problem with org-gnus-follow-link

[Ulf Stegemann]

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

Hi Tassilo,

Tassilo Horn <tassilo@member.fsf.org> wrote:

> please try this one.

this works after some modifications (patch attached). XEmacs does not
know `substring-no-properties' but org-compat has
`org-substring-no-properties'. Besides, my Gnus holds
`gnus-large-newsgroup' as a string not as integer.

Unfortunately, this is not an ideal solution but from what I've read
from the Gnus gurus the best that can be done until the problems with
nnml are resolved.

Nevertheless, your patch has the great advantage that is should work
with all links to nnml group articles (I agree, more than 1-
gnus-large-newsgroup articles in a group are rather seldom).
 
> +	 (gnus-activate-group group t)
> +	 (unless (gnus-group-read-group 1 nil group)
> +	   ;; Try again with a bigger number of messages.
> +	   (gnus-group-read-group (1- gnus-large-newsgroup) nil group))
> +	 (gnus-summary-goto-article article nil t))
>  	(group (gnus-group-jump-to-group group))))

Just one other comment: After failure to get a summary buffer by reading
the last article you try it with reading 1- gnus-large-newsgroup
articles. I'd assume that in most cases where the first call to
gnus-group-read-group fails only one or a few more articles have been
deleted in the group in question. In that case, it might be quicker if
`org-gnus-follow-link' increases the number of articles to be read by
one and tries `gnus-group-read-group' again until the call succeeds. If
I find the time tomorrow I will test that. What do you think?

Ulf


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: fix-for-fix-gnus-links.patch --]
[-- Type: text/x-patch, Size: 1369 bytes --]

--- org-gnus.el.orig	2008-12-11 22:29:06.000000000 +0100
+++ org-gnus.el	2008-12-11 22:27:56.000000000 +0100
@@ -150,9 +150,9 @@
     (setq group (match-string 1 path)
 	  article (match-string 3 path))
     (when group
-      (setq group (substring-no-properties group)))
+      (setq group (org-substring-no-properties group)))
     (when article
-      (setq article (substring-no-properties article)))
+      (setq article (org-substring-no-properties article)))
     (org-gnus-follow-link group article)))
 
 (defun org-gnus-follow-link (&optional group article)
@@ -161,14 +161,14 @@
   (funcall (cdr (assq 'gnus org-link-frame-setup)))
   (if gnus-other-frame-object (select-frame gnus-other-frame-object))
   (when group
-    (setq group (substring-no-properties group)))
+    (setq group (org-substring-no-properties group)))
   (when article
-    (setq article (substring-no-properties article)))
+    (setq article (org-substring-no-properties article)))
   (cond ((and group article)
 	 (gnus-activate-group group t)
 	 (unless (gnus-group-read-group 1 nil group)
 	   ;; Try again with a bigger number of messages.
-	   (gnus-group-read-group (1- gnus-large-newsgroup) nil group))
+	   (gnus-group-read-group (1- (string-to-int gnus-large-newsgroup)) nil group))
 	 (gnus-summary-goto-article article nil t))
 	(group (gnus-group-jump-to-group group))))
 

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

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Problem with org-gnus-follow-link

[Tassilo Horn]

Ulf Stegemann <ulf-news@zeitform.de> writes:

Hi Ulf,

> this works after some modifications (patch attached). XEmacs does not
> know `substring-no-properties' but org-compat has
> `org-substring-no-properties'.

Ah, ok.

> Besides, my Gnus holds `gnus-large-newsgroup' as a string not as
> integer.

What?!?  Do you set it somewhere?  The docs say it should be a number or
nil.

> Just one other comment: After failure to get a summary buffer by
> reading the last article you try it with reading 1-
> gnus-large-newsgroup articles.  I'd assume that in most cases where
> the first call to gnus-group-read-group fails only one or a few more
> articles have been deleted in the group in question. In that case, it
> might be quicker if `org-gnus-follow-link' increases the number of
> articles to be read by one and tries `gnus-group-read-group' again
> until the call succeeds.

Yeah, I'll implement like that.  But incrementing one by one is not
optimal.  When a user deletes all messages (including the linked one)
the summary cannot be opened anyway and you'll loop till the maximum
integer (or whatever you use as upper bound).  So I think I'll try
increasing by one till 16 and then start doubling.

Bye,
Tassilo

Re: Problem with org-gnus-follow-link

[Ulf Stegemann]

Hi Tassilo,

Tassilo Horn <tassilo@member.fsf.org> wrote:

> Ulf Stegemann <ulf-news@zeitform.de> writes:
>
>> Besides, my Gnus holds `gnus-large-newsgroup' as a string not as
>> integer.
>
> What?!?  Do you set it somewhere?  The docs say it should be a number or
> nil.

Yes, I was investigating that, too ... and indeed I found that the value
was user set. What had driven me to set it as string remains a mystery
to me, I wasn't even aware I'd ever touched that value. So I think it's
save to assume that `gnus-large-newsgroup' is an integer or nil ;)

>> Just one other comment: After failure to get a summary buffer by
>> reading the last article you try it with reading 1-
>> gnus-large-newsgroup articles.  I'd assume that in most cases where
>> the first call to gnus-group-read-group fails only one or a few more
>> articles have been deleted in the group in question. In that case, it
>> might be quicker if `org-gnus-follow-link' increases the number of
>> articles to be read by one and tries `gnus-group-read-group' again
>> until the call succeeds.
>
> Yeah, I'll implement like that.  But incrementing one by one is not
> optimal.  When a user deletes all messages (including the linked one)
> the summary cannot be opened anyway and you'll loop till the maximum
> integer (or whatever you use as upper bound).  So I think I'll try
> increasing by one till 16 and then start doubling.

Yes, increasing the interval is certainly a good idea. But how about
using the Fibonacci sequence (1, 2, 3, 5, 8 ...) for this :)

Ulf

Re: Problem with org-gnus-follow-link

[Tassilo Horn]

Ulf Stegemann <ulf-news@zeitform.de> writes:

Hi Ulf,

> Yes, increasing the interval is certainly a good idea. But how about
> using the Fibonacci sequence (1, 2, 3, 5, 8 ...) for this :)

The fibonacci sequence increases too slow.  The current implementation
(which should hit the main tree soon) increases step by step till 16 and
then doubles the value till an integer overflow occurs.  Normally, that
cannot happen, only if the group is empty.  But in that case gnus
signals a quit condition, which is handled now with an appropriate
message.

If you're impatient you can pull from

   git://www.tsdh.de/org-mode.git

instead of waiting till Carsten pulled the changes.

Bye,
Tassilo

Re: Problem with org-gnus-follow-link

[Ulf Stegemann]

Hi Tassilo,

Tassilo Horn <tassilo@member.fsf.org> wrote:

> Ulf Stegemann <ulf-news@zeitform.de> writes:
>
>> Yes, increasing the interval is certainly a good idea. But how about
>> using the Fibonacci sequence (1, 2, 3, 5, 8 ...) for this :)
>
> The fibonacci sequence increases too slow.  The current implementation
> (which should hit the main tree soon) increases step by step till 16 and
> then doubles the value till an integer overflow occurs.  Normally, that
> cannot happen, only if the group is empty.  But in that case gnus
> signals a quit condition, which is handled now with an appropriate
> message.
>
> If you're impatient you can pull from
>
>    git://www.tsdh.de/org-mode.git
>
> instead of waiting till Carsten pulled the changes.

Carsten already did that. The new version works fine. Thanks for your
effort :)))))

Ulf