gnus-group-change-level

gnus-group-change-level

[James Cloos]

When passing a string to gnus-group-change-level, what format should the
string take?

Eg, this just returns nil w/o changing the level:

  (gnus-group-change-level "nnimap+oxygen:INBOX" 6)

even though nnimap+oxygen13:INBOX is how the group shows up in
the *Groups* buffer and in gnus-newsrc-alist?

This works:

  (gethash "nnimap+oxygen:INBOX" gnus-newsrc-hashtb)

but the above chang-level call does not.

So what should the string look like?


I had to redo my imap setup when my prevous workstation stopped working
last summer, and I'd like to automate getting the levels back to what I
had.

I have a list of the goups w/o the nnimap+[hostname]: prefix which is
easy to awk into a bunch of calls to gnus-group-change-level, but so far
it is not working.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: gnus-group-change-level

[Andreas Schwab]

On Feb 14 2024, James Cloos wrote:

> Eg, this just returns nil w/o changing the level:
>
>   (gnus-group-change-level "nnimap+oxygen:INBOX" 6)
>
> even though nnimap+oxygen13:INBOX

There is a discrepancy between the two names.  Typo?

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: gnus-group-change-level

[James Cloos]

>>>>> "AS" == Andreas Schwab <schwab@linux-m68k.org> writes:

AS> On Feb 14 2024, James Cloos wrote:
>> Eg, this just returns nil w/o changing the level:
>> 
>> (gnus-group-change-level "nnimap+oxygen:INBOX" 6)
>> 
>> even though nnimap+oxygen13:INBOX

AS> There is a discrepancy between the two names.  Typo?

yes.  the typo is only in the email.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: gnus-group-change-level

[Eric Abrahamsen]

James Cloos <cloos@jhcloos.com> writes:

>>>>>> "AS" == Andreas Schwab <schwab@linux-m68k.org> writes:
>
> AS> On Feb 14 2024, James Cloos wrote:
>>> Eg, this just returns nil w/o changing the level:
>>> 
>>> (gnus-group-change-level "nnimap+oxygen:INBOX" 6)
>>> 
>>> even though nnimap+oxygen13:INBOX
>
> AS> There is a discrepancy between the two names.  Typo?
>
> yes.  the typo is only in the email.

I think you would need to edebug `gnus-group-change-level' and see
what's happening. That function uses `gnus-group-entry' to turn the
group string name into a group data structure, but all that macro does
is `gethash' on the `gnus-newsrc-hashtb', and you've already stated that
this works:

(gethash "nnimap+oxygen:INBOX" gnus-newsrc-hashtb)

so it looks like the function should at least be finding your group
correctly, and things are going wrong elsewhere. Are you comfortable
using edebug?

Eric

Re: gnus-group-change-level

[James Cloos]

I stepped thru gnus-group-change-level w/ edebug.

I did not spot anything obvious.  The steps converting the string all
looked correct.  The final nil return looks to be due to not having a
gnus-group-change-level-function configured, and thus innocuous.

But at least on the first step-thru I didn't see why the level does
not get changed.

I'll have to step thru when it is called via the *Groups* buffer UI
and see what is different.

(I'm currently running gnus on 29 rather than master, if it makes a
difference.  Master's font support was horibly screwed up when I last
tried using it for gnus.  Glyphs were changing their font while I was
reading the article and junk like that.  Plus it was ignoring my font
choices and choosing random fonts behind my back.  29 isn't doing so.)

-JimC
-- 
James Cloos <cloos@jhcloos.com>
            OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc

Re: gnus-group-change-level

[James Cloos]

it looks like (if (< oldlevel gnus-level-zombie) is the most
significant difference.  the default when oldlevel is not
specified seems to be to use gnus-level-killed so an (if) like
that is not run.

I didn't spot any other obviuos differences.

-JimC
-- 
James Cloos <cloos@jhcloos.com>
            OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc

Re: gnus-group-change-level

[Eric Abrahamsen]

James Cloos <cloos@jhcloos.com> writes:

> it looks like (if (< oldlevel gnus-level-zombie) is the most
> significant difference.  the default when oldlevel is not
> specified seems to be to use gnus-level-killed so an (if) like
> that is not run.

What is the current level of the group you're trying to change?

Re: gnus-group-change-level

[James Cloos]

>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:

EA> What is the current level of the group you're trying to change?

I was testing with a switch from 11 to 55 (I have this block in .gnus:

  ;;; use my levels
  (setq gnus-level-default-subscribed 1)
  (setq gnus-level-subscribed 80)
  (setq gnus-level-unsubscribed 90)
  (setq gnus-level-zombie 98)
  (setq gnus-level-killed 99)
  (setq gnus-level-default-unsubscribed 88)
  (setq gnus-activate-level 80)
  (setq gnus-activate-foreign-newsgroups 80)

and make significant use of levels for organizing the groups.)


Unfortunately adding oldlevel to the tested gnus-group-change-level call
did not help.

The function succeeded in pulling up the hash and a list along the way,
it just never changes the group's level.

-JimC
-- 
James Cloos <cloos@jhcloos.com>
            OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc

Re: gnus-group-change-level

[Eric Abrahamsen]

James Cloos <cloos@jhcloos.com> writes:

>>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> EA> What is the current level of the group you're trying to change?
>
> I was testing with a switch from 11 to 55 (I have this block in .gnus:
>
>   ;;; use my levels
>   (setq gnus-level-default-subscribed 1)
>   (setq gnus-level-subscribed 80)
>   (setq gnus-level-unsubscribed 90)
>   (setq gnus-level-zombie 98)
>   (setq gnus-level-killed 99)
>   (setq gnus-level-default-unsubscribed 88)
>   (setq gnus-activate-level 80)
>   (setq gnus-activate-foreign-newsgroups 80)

Oh wow, I've never seen anyone do this before. How long has this setup
been functioning? Is your current issue with changing the level of this
group something that's come up recently, and only for this group? If
it's just this one group, and no other groups from this nnimap backend
are behaving this way, can you show me the group parameters for this
group?

> and make significant use of levels for organizing the groups.)
>
>
> Unfortunately adding oldlevel to the tested gnus-group-change-level call
> did not help.

Was oldlevel not set in earlier tests? Oldlevel is retrieved by reading
a text property in the Group buffer -- if you put point where you've had
it in trying to set the level so far, and run M-:
(gnus-group-group-level), what do you get?

> The function succeeded in pulling up the hash and a list along the way,
> it just never changes the group's level.

In current Emacs master, the level should be changed on line 1327:

(setcar (cdadr entry) level)

Do you not reach that line?

Re: gnus-group-change-level

[James Cloos]

>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:

EA> Oh wow, I've never seen anyone do this before. How long has this setup
EA> been functioning?

A couple of decades.

EA> Is your current issue with changing the level of this
EA> group something that's come up recently, and only for this group?

I never tried to call gnus-group-change-level directly before, only S L
in the *Groups* buffer, and that as I wrote works fine.

I'm only attempting this because after my previous workstation's
mainboard failed, I ended up using a different imapd on an existing
headless node here.  And so the group names have a different hostname.

I want to get the levels back to how I had them on the previous setup,
but w/o manually calling SL thousands of times.  Or even just hundreds.
(I used to split some large lists very narrowly; that led to *lots* of
groups.  I've chosen not to split them that narrowly this time.)

EA> can you show me the group parameters for this group?

These are the params for nnimap+oxygen:ding@gnus.org:

((modseq . "51")
 (uidvalidity . "1689374630")
 (active 1 . 24)
 (timestamp . 1708309971)
 (permanent-flags %Answered %Flagged %Deleted %Seen %Draft %*))

It is at level 11.

EA> Was oldlevel not set in earlier tests?

I used awk to convert a list of '{level} {name}' to a list of

(gnus-group-change-level "nnimap+oxygen:{name}" {level})

where everything outside of {} is static, of course.

EA> if you put point where you've had
EA> it in trying to set the level so far, and run M-:
EA> (gnus-group-group-level), what do you get?

that works.

EA> In current Emacs master, the level should be changed on line 1327:

EA> (setcar (cdadr entry) level)

EA> Do you not reach that line?

I saw that line, but do not recall what edebug showed in the non-working
attempts.

I'll have to re-test.  I had to restart gnus in the interim.  I'll do
that later tonight.

-JimC
-- 
James Cloos <cloos@jhcloos.com>
            OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc

Re: gnus-group-change-level

[Eric Abrahamsen]

James Cloos <cloos@jhcloos.com> writes:

>>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> EA> Oh wow, I've never seen anyone do this before. How long has this setup
> EA> been functioning?
>
> A couple of decades.

Well that's good news in general!

> EA> Is your current issue with changing the level of this
> EA> group something that's come up recently, and only for this group?
>
> I never tried to call gnus-group-change-level directly before, only S L
> in the *Groups* buffer, and that as I wrote works fine.
>
> I'm only attempting this because after my previous workstation's
> mainboard failed, I ended up using a different imapd on an existing
> headless node here.  And so the group names have a different hostname.
>
> I want to get the levels back to how I had them on the previous setup,
> but w/o manually calling SL thousands of times.  Or even just hundreds.
> (I used to split some large lists very narrowly; that led to *lots* of
> groups.  I've chosen not to split them that narrowly this time.)

Sorry, you did mention originally that you were doing this
programmatically.

[...]

> EA> In current Emacs master, the level should be changed on line 1327:
>
> EA> (setcar (cdadr entry) level)
>
> EA> Do you not reach that line?
>
> I saw that line, but do not recall what edebug showed in the non-working
> attempts.
>
> I'll have to re-test.  I had to restart gnus in the interim.  I'll do
> that later tonight.

Another thing to try is edebugging `gnus-group-change-level', then using
"S L", and when edebug starts up make note of all the values of the
arguments. Then you can call the function yourself with those values.

Provided you give it a value for "oldlevel", and provided that level is
less than `gnus-level-zombie', the setting of the level should be
relatively straightforward, since you're not "bringing the group back
from the dead", as far as Gnus is concerned.

Last but not least, if you're doing this programmatically, you might as
well just get straight to the meat of it. Like I said, if you're not
resurrecting dead groups, all the auxiliary structures will already
contain your group and all should be well. It should be enough to do:

(let ((level 55))
  (dolist (grp very-long-list-of-group-names)
    (when-let ((entry (gnus-group-entry grp)))
      (setcar (cdadr entry) level))))

Then refresh Gnus with "g".

Back up your .newsrc.eld first!

Re: gnus-group-change-level

[James Cloos]

>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:

EA> (let ((level 55))
EA>   (dolist (grp very-long-list-of-group-names)
EA>     (when-let ((entry (gnus-group-entry grp)))
EA>       (setcar (cdadr entry) level))))

Ah.  Cool.  As a first step I tried out:

 (cdadr (gnus-group-entry "nnimap+oxygen:ding@gnus.org"))

since ding was at point and thus easy to copy-n-yank.

It errored out that (listp 0) return nil.

Some experimentation showed that:

 (cadadr (gnus-group-entry "nnimap+oxygen:ding@gnus.org"))

returned the cons (11 . 15), where 11 is the current level.
(I'm not sure what that cons' cdr is.)

I see aroung 7% of the groups' lines in .newsrc.eld have just an integer
at that point for level, whereas the others have such a cons.

Eg this returns just the integer 11:

 (cadadr (gnus-group-entry "nnimap+oxygen:GitHub-Torvalds"))

I take it setcar will not do the right thing in such cases, yes?
And something like a cl-typecase would be required?

Is cadadr setf-able in emacs?

Thanks for the help!

P.S.  setting (nnimap-expunge never) or (nnimap-expunge 'never)
      in an entry in gnus-secondary-select-methods doesn't seem
      to do anything.  dovecot removes the files everytime gnus
      quits the *Summary* buffer.  I want to set \Delete but not
      to expunge...

-JimC
-- 
James Cloos <cloos@jhcloos.com>
            OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc

Re: gnus-group-change-level

[Eric Abrahamsen]

James Cloos <cloos@jhcloos.com> writes:

>>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> EA> (let ((level 55))
> EA>   (dolist (grp very-long-list-of-group-names)
> EA>     (when-let ((entry (gnus-group-entry grp)))
> EA>       (setcar (cdadr entry) level))))
>
> Ah.  Cool.  As a first step I tried out:
>
>  (cdadr (gnus-group-entry "nnimap+oxygen:ding@gnus.org"))
>
> since ding was at point and thus easy to copy-n-yank.
>
> It errored out that (listp 0) return nil.
>
> Some experimentation showed that:
>
>  (cadadr (gnus-group-entry "nnimap+oxygen:ding@gnus.org"))
>
> returned the cons (11 . 15), where 11 is the current level.
> (I'm not sure what that cons' cdr is.)

Ah, that's "rank". Once upon a time I knew what rank meant, but have
since forgotten.

> I see aroung 7% of the groups' lines in .newsrc.eld have just an integer
> at that point for level, whereas the others have such a cons.
>
> Eg this returns just the integer 11:
>
>  (cadadr (gnus-group-entry "nnimap+oxygen:GitHub-Torvalds"))
>
> I take it setcar will not do the right thing in such cases, yes?
> And something like a cl-typecase would be required?
>
> Is cadadr setf-able in emacs?

I'd also forgotten there are tools for reliably setting the level,
whether or not rank is involved. Specifically there's a
`gnus-info-level' that advertises itself as setf-able, so try:

(let ((level 55))
   (dolist (grp very-long-list-of-group-names)
     (when-let ((info (gnus-get-info grp)))
       (setf (gnus-info-level info) level))))

Note that now we're using `gnus-get-info', not `gnus-group-entry'. Sorry
I didn't (re-)discover this the first time around!

> P.S.  setting (nnimap-expunge never) or (nnimap-expunge 'never)
>       in an entry in gnus-secondary-select-methods doesn't seem
>       to do anything.  dovecot removes the files everytime gnus
>       quits the *Summary* buffer.  I want to set \Delete but not
>       to expunge...

Hmm, that ought to work -- how are you marking your messages for deletion?

Re: gnus-group-change-level

[Andreas Schwab]

On Feb 22 2024, Eric Abrahamsen wrote:

> James Cloos <cloos@jhcloos.com> writes:
>
>> Some experimentation showed that:
>>
>>  (cadadr (gnus-group-entry "nnimap+oxygen:ding@gnus.org"))
>>
>> returned the cons (11 . 15), where 11 is the current level.
>> (I'm not sure what that cons' cdr is.)
>
> Ah, that's "rank". Once upon a time I knew what rank meant, but have
> since forgotten.

(gnus) Group Score

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: gnus-group-change-level

[Eric Abrahamsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> On Feb 22 2024, Eric Abrahamsen wrote:
>
>> James Cloos <cloos@jhcloos.com> writes:
>>
>>> Some experimentation showed that:
>>>
>>>  (cadadr (gnus-group-entry "nnimap+oxygen:ding@gnus.org"))
>>>
>>> returned the cons (11 . 15), where 11 is the current level.
>>> (I'm not sure what that cons' cdr is.)
>>
>> Ah, that's "rank". Once upon a time I knew what rank meant, but have
>> since forgotten.
>
> (gnus) Group Score

Thanks :)

Re: gnus-group-change-level

[James Cloos]

>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:

>> P.S.  setting (nnimap-expunge never) or (nnimap-expunge 'never)
>> in an entry in gnus-secondary-select-methods doesn't seem
>> to do anything.  dovecot removes the files everytime gnus
>> quits the *Summary* buffer.  I want to set \Delete but not
>> to expunge...

EA> Hmm, that ought to work -- how are you marking your messages for deletion?

I had to reboot due to a crash and gave master another try.  It looks
like the font bugs which led me to use 29 for gnus have been fixed.

In master it does work.  But in 29.2 it exhibits the above behavior.

For the level changes, today's suggestion looks perfect.  I'll try it
out tonight or tomorrow.

-JimC
-- 
James Cloos <cloos@jhcloos.com>
            OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc

Re: gnus-group-change-level

[Eric S Fraga]

On Sunday, 18 Feb 2024 at 20:26, James Cloos wrote:
> I was testing with a switch from 11 to 55 (I have this block in .gnus:

[...]

> and make significant use of levels for organizing the groups.)

Thank you for this.  Some time ago, I tried changing from the 1-5 levels
that is the gnus default and ended up with a totally confused system,
probably because I missed some of the variables I needed to set.  So I
will now try with your list of variables to see how it goes.  I don't
need 100 group levels but 10 or so would be nice.

-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-07-11) on Debian bullseye/sid

Re: gnus-group-change-level

[Eric Abrahamsen]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Sunday, 18 Feb 2024 at 20:26, James Cloos wrote:
>> I was testing with a switch from 11 to 55 (I have this block in .gnus:
>
> [...]
>
>> and make significant use of levels for organizing the groups.)
>
> Thank you for this.  Some time ago, I tried changing from the 1-5 levels
> that is the gnus default and ended up with a totally confused system,
> probably because I missed some of the variables I needed to set.  So I
> will now try with your list of variables to see how it goes.  I don't
> need 100 group levels but 10 or so would be nice.

Part of the reason I was surprised here is that the various
`gnus-level-*' variables, far from being user options, are actually
defined with `defconst', which would indicate that Gnus didn't want you
fooling with them. It's possible that was done so that the variables are
marked as "special", but defcustom would have the same effect.

Anyway, it's encouraging to know that it's been working correctly for
some people for a while.