Another Oort error.

Another Oort error.

[Lloyd Zusman]

I'm using the very latest (as of this email) Oort gnus under XEmacs
21.4.3, and in this version, I'm getting the following error when I
try to enter one of my local, nnspool newsgroups.  If I use an earlier
Oort (maybe two or three weeks old), I have no problem entering this
same group.

Error:

  (malformed-list (3007 . 3008))

If this isn't a bug, then the earlier Oort version overlooked whatever
condition(s) triggered this error.

Also, here's the stack trace (manually wrapped):

 Signaling: (malformed-list (3007 . 3008))
   delq(3010 (3007 . 3008))
   gnus-update-missing-marks((3010))
   gnus-select-newsgroup("alt.language.spanish" nil nil)
   gnus-summary-read-group-1("alt.language.spanish" nil nil nil nil nil)
   ad-Orig-gnus-summary-read-group-around-gnus-summary-read-group(
     "alt.language.spanish" nil nil nil nil nil nil)
   gnus-summary-read-group("alt.language.spanish" nil nil nil nil nil nil)
   gnus-group-read-group(nil)
   call-interactively(gnus-group-read-group)

Thanks.

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Another Oort error.

[Lars Magne Ingebrigtsen]

Lloyd Zusman <ljz@asfast.com> writes:

> I'm using the very latest (as of this email) Oort gnus under XEmacs
> 21.4.3, and in this version, I'm getting the following error when I
> try to enter one of my local, nnspool newsgroups.  If I use an earlier
> Oort (maybe two or three weeks old), I have no problem entering this
> same group.

[...]

>    ad-Orig-gnus-summary-read-group-around-gnus-summary-read-group(
>      "alt.language.spanish" nil nil nil nil nil nil)

You have this function defadviced, it looks like.  Could that be the
problem? 

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

Group-specific gnus-auto-select-next? (was: Another Oort error.)

[Lloyd Zusman]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Lloyd Zusman <ljz@asfast.com> writes:
>> 
>> [...]
>> 
>>    ad-Orig-gnus-summary-read-group-around-gnus-summary-read-group(
>>      "alt.language.spanish" nil nil nil nil nil nil)
> 
> You have this function defadviced, it looks like.  Could that be the
> problem? 

Oh yeah ... I did that ages ago and forgot about it.  But why would
that be causing a problem after working fine for many months?  It's a
pretty simple defadvice.

Here it is:

 ;; Wrap `gnus-summary-read-group' so that `gnus-auto-select-next'
 ;; gets set according to `no-auto-select-pattern'

 (defadvice gnus-summary-read-group (around gnus-summary-read-group freeze)
   ad-do-it
   (setq gnus-auto-select-next
	 (not (and gnus-newsgroup-name
		   (string-match no-auto-select-pattern
                                 gnus-newsgroup-name)))))

I did this because it seemed at the time that there was no other way
to selectively set `gnus-auto-select-next' based upon the name of the
newsgroup.  I tried all the hooks (yes, I really did try *all* of
them), but none of them could be used to cause the
`gnus-auto-select-next' setting to be recognized and acted upon in a
group-specific manner.  And I tried lots of other things as well,
before finally giving up and using the defadvice.

But this was a long time ago.  Perhaps now is there a way to do this,
after all?

Thanks in advance.

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Group-specific gnus-auto-select-next? (was: Another Oort error.)

[Kai Großjohann]

Lloyd Zusman <ljz@asfast.com> writes:

> Here it is:
>
>  ;; Wrap `gnus-summary-read-group' so that `gnus-auto-select-next'
>  ;; gets set according to `no-auto-select-pattern'
>
>  (defadvice gnus-summary-read-group (around gnus-summary-read-group freeze)
>    ad-do-it
>    (setq gnus-auto-select-next
> 	 (not (and gnus-newsgroup-name
> 		   (string-match no-auto-select-pattern
>                                  gnus-newsgroup-name)))))
>
> I did this because it seemed at the time that there was no other way
> to selectively set `gnus-auto-select-next' based upon the name of the
> newsgroup.  I tried all the hooks (yes, I really did try *all* of
> them), but none of them could be used to cause the
> `gnus-auto-select-next' setting to be recognized and acted upon in a
> group-specific manner.  And I tried lots of other things as well,
> before finally giving up and using the defadvice.

Hm.  Does it work to set a local variable in the group parameters?

(setq gnus-parameters '(("e" (gnus-auto-select-next t))
                        (""  (gnus-auto-select-next nil))))

Maybe this sets it to t for all group names with e in them.

kai
-- 
Symbol's function definition is void: signature

Re: Group-specific gnus-auto-select-next? (was: Another Oort error.)

[Lloyd Zusman]

I'm sorry I took so long to reply to you.  Your response arrived when
I was out of town, and I had a lot of work to make up when I got back.
Then, the WTC was bombed in my city, and only now am I catching up
with everything.

I'm replying here, in case anyone might find this information useful.


Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Lloyd Zusman <ljz@asfast.com> writes:
> 
>> Here it is:
>>
>>  ;; Wrap `gnus-summary-read-group' so that `gnus-auto-select-next'
>>  ;; gets set according to `no-auto-select-pattern'
>>
>>  (defadvice gnus-summary-read-group (around gnus-summary-read-group freeze)
>>    [ ... etc. ... ]
>>
>> I did this because it seemed at the time that there was no other way
>> to selectively set `gnus-auto-select-next' based upon the name of the
>> newsgroup.  [ ... ]
> 
> Hm.  Does it work to set a local variable in the group parameters?
> 
> (setq gnus-parameters '(("e" (gnus-auto-select-next t))
>                         (""  (gnus-auto-select-next nil))))
> 
> Maybe this sets it to t for all group names with e in them.

I tried this, and indeed it works.

Thank you very much.


> kai
> -- 
> Symbol's function definition is void: signature


-- 
 Lloyd Zusman
 ljz@asfast.com

I lied (Was: Group-specific gnus-auto-select-next?)

[Lloyd Zusman]

Lloyd Zusman <ljz@asfast.com> writes:

> [ ... ]
>
> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> 
>> Lloyd Zusman <ljz@asfast.com> writes:
>> 
>>> Here it is:
>>>
>>>  ;; Wrap `gnus-summary-read-group' so that `gnus-auto-select-next'
>>>  ;; gets set according to `no-auto-select-pattern'
>>>
>>>  (defadvice gnus-summary-read-group (around gnus-summary-read-group freeze)
>>>    [ ... etc. ... ]
>>>
>>> I did this because it seemed at the time that there was no other way
>>> to selectively set `gnus-auto-select-next' based upon the name of the
>>> newsgroup.  [ ... ]
>> 
>> Hm.  Does it work to set a local variable in the group parameters?
>> 
>> (setq gnus-parameters '(("e" (gnus-auto-select-next t))
>>                         (""  (gnus-auto-select-next nil))))
>> 
>> Maybe this sets it to t for all group names with e in them.
> 
> I tried this, and indeed it works.
> 
> Thank you very much.

Well, I lied.  It didn't work after all.  As it turns out, I don't
think that there's any way to set `gnus-auto-select-next' in
a group-specific manner.  Here's why:

What follows at the end of this message is the code for
`gnus-summary-read-group'.  Notice the 10th line of that function,
where `gnus-auto-select-next' is set to nil in the `let' block.  This
causes any and all changes to the value of `gnus-auto-select-next'
from within `gnus-summary-read-group-1' to get undone after that
function returns.

Since all the appropriate hooks, gnus-parameters settings, etc. are
done within the invocation `gnus-summary-read-group-1', there doesn't
appear to be any place where I can set `gnus-auto-select-next' in a
group-specific manner.

Now that I'm looking at this, I remember why in the past I put a
`defadvice' around `gnus-summary-read-group', within which I ran the
original function and then set `gnus-auto-select-group' in a
group-specific way.

But this `defadvice' now causes other things to break, so it seems
like I'm completely out of luck here.

I'm starting to think that now is the time for me to come up with a
patch for `gnus-summary-read-group'.

Or am I missing something?

Thanks in advance.



(defun gnus-summary-read-group (group &optional show-all no-article
                                      kill-buffer no-display backward
                                      select-articles)
  "Start reading news in newsgroup GROUP.
If SHOW-ALL is non-nil, already read articles are also listed.
If NO-ARTICLE is non-nil, no article is selected initially.
If NO-DISPLAY, don't generate a summary buffer."
  (let (result)
    (while (and group
                (null (setq result
                            (let ((gnus-auto-select-next nil))
                              (or (gnus-summary-read-group-1
                                   group show-all no-article
                                   kill-buffer no-display
                                   select-articles)
                                  (setq show-all nil
                                        select-articles nil)))))
                (eq gnus-auto-select-next 'quietly))
      (set-buffer gnus-group-buffer)
      ;; The entry function called above goes to the next
      ;; group automatically, so we go two groups back
      ;; if we are searching for the previous group.
      (when backward
        (gnus-group-prev-unread-group 2))
      (if (not (equal group (gnus-group-group-name)))
          (setq group (gnus-group-group-name))
        (setq group nil)))
    result))


-- 
 Lloyd Zusman
 ljz@asfast.com

Re: I lied (Was: Group-specific gnus-auto-select-next?)

[Kai Großjohann]

Lloyd Zusman <ljz@asfast.com> writes:

> What follows at the end of this message is the code for
> `gnus-summary-read-group'.  Notice the 10th line of that function,
> where `gnus-auto-select-next' is set to nil in the `let' block.  This
> causes any and all changes to the value of `gnus-auto-select-next'
> from within `gnus-summary-read-group-1' to get undone after that
> function returns.

This seems to be a bad thing, and IWBNI some other way could be
devised to achieve the same effect.

Why is gnus-auto-select-next bound to nil, anyway?

Thanks for being willing to work on this.

kai
-- 
Abort this operation?   [OK]  [Cancel]

Re: I lied (Was: Group-specific gnus-auto-select-next?)

[Lloyd Zusman]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Lloyd Zusman <ljz@asfast.com> writes:
> 
>> What follows at the end of this message is the code for
>> `gnus-summary-read-group'.  Notice the 10th line of that function,
>> where `gnus-auto-select-next' is set to nil in the `let' block.  This
>> causes any and all changes to the value of `gnus-auto-select-next'
>> from within `gnus-summary-read-group-1' to get undone after that
>> function returns.
> 
> This seems to be a bad thing, and IWBNI some other way could be
> devised to achieve the same effect.
> 
> Why is gnus-auto-select-next bound to nil, anyway?

I'm going to make a wild guess as to why: perhaps it's set to nil to
avoid problems if the group being read by `gnus-summary-read-group' is
empty at the time that function is being invoked.

But whatever the case, I agree with you that there probably would be
other ways to achieve the intended effect of the temporary binding of
`gnus-auto-select-next' to nil, whatever that intended effect might
be.


> Thanks for being willing to work on this.

Tonight or tomorrow I'll experiment with this routine, to see if I can
determine the intention of binding `gnus-auto-select-next' to nil, and
if so, then to see if I can devise a different way to achieve this
intention.

For now, I have to go to work ... <sigh>


> kai
> -- 
> Abort this operation?   [OK]  [Cancel]


-- 
 Lloyd Zusman
 ljz@asfast.com