> Thank you. This seems to be working. Glad it worked. > But performance is the main reason I use "extra" for CC and To (after > setting gnus-extra-headers). Is there an equivalent syntax for using > "extra" matcher? It seems that you cannot use `extra' match in advanced scoring at all (see `gnus-advanced-index' variable). -- Kuba Ječmínek (http://kubajecminek.cz)
Jakub Ječmínek <kuba@kubajecminek.cz> writes:
> Hi, I think that this is the syntax you're looking for:
>
> (((&
> ("from" "Eric Abrahamsen")
> ("head" "Cc: ding@gnus.org" s))
> 1000))
>
> Please note that scoring on "non-standard" headers takes
> a while.
Thank you. This seems to be working.
But performance is the main reason I use "extra" for CC and To (after
setting gnus-extra-headers). Is there an equivalent syntax for using
"extra" matcher?
--
Husain
Hi, I think that this is the syntax you're looking for: (((& ("from" "Eric Abrahamsen") ("head" "Cc: ding@gnus.org" s)) 1000)) Please note that scoring on "non-standard" headers takes a while. Best -- Kuba Ječmínek (http://kubajecminek.cz)
On Wednesday, 6 Mar 2024 at 20:48, Husain Alshehhi wrote: > From the documentation[1], one can configure complex rules through and, > or, not operators. The documentation also states that match operators > are "header name strings followed by a match and a match type". The > documentation also provides examples[2]. My understanding is that the matches that look like this: > ("from" "example@domain.com") should have the second argument be a list, so something like > ("from" ("example@domain.com")) might do the job? I've never used the logical operators you are trying to use however. -- Eric S Fraga via gnus (Emacs 30.0.50 2024-02-28) on Debian 12.2
From the documentation[1], one can configure complex rules through and, or, not operators. The documentation also states that match operators are "header name strings followed by a match and a match type". The documentation also provides examples[2]. However, all the docs and the examples provide the simple "from", "body", "subject", "line" match operators. I am unable to create rules that use "header" or "extra" operators. Ultimately, I want to setup a rule that scores an message based on the (1) "from" header AND "to" header, (2) "from" header AND "cc" header, (3) "from" header AND an arbitrary header. gnus errors out when parsing the following rules: --8<---------------cut here---------------start------------->8--- ((& ("from" "example@domain.com") ("to" "example@domain.com")) 10) ((& ("from" "example@domain.com") ("header" "example@domain.com" "To")) 10) ((& ("from" "example@domain.com") ("header" "example@domain.com" s "To")) 10) ((& ("from" "example@domain.com") ("extra" "To: .*example@domain.com")) 10) --8<---------------cut here---------------end--------------->8--- Any help is appreciated. Thanks. [1] https://www.gnu.org/software/emacs/manual/html_node/gnus/Advanced-Scoring-Syntax.html [2] https://www.gnu.org/software/emacs/manual/html_node/gnus/Advanced-Scoring-Examples.html
[-- Attachment #1: Type: text/plain, Size: 549 bytes --] On Thu, 2024-02-22 at 15:47 +0100, Lars Ingebrigtsen wrote: > And I'm giving them away. For more details, see: > > https://lars.ingebrigtsen.no/2024/02/22/can-you-spot-the-date-i-said-im-done/ > > (If you respond to this message, leave the mailing list off of the > CCs -- otherwise I won't see your email.) > Long time no see Lars ^^^ I'm currently contemplating whether to buy a t-shirt. Once it is decided, I will email you back using Gnus. This time i send email with GNOME Evolution. Thanks, Byunghee from South Korea [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 833 bytes --]
"Eric Abrahamsen" <eric@ericabrahamsen.net> writes: > It's possible that all that would be necessary is to add a routine at > the bottom of `nnimap-transform-headers', to sort the buffer text. There's also `nnimap-request-group-scan' and probably other functions as well. -- Kuba Ječmínek (http://kubajecminek.cz)
Jakub Ječmínek <kuba@kubajecminek.cz> writes: > "Eric Abrahamsen" <eric@ericabrahamsen.net> writes: > >> Yes! That's it, thanks very much. The question remains where exactly to >> address this, but it's good to know why it's behaving this way. I'll put >> this on the list. > > I don't think we have good/elegant way to do it. I see two options: > > 1. Implement custom sorting in nnimap.el back end. > > This would require substantial work because we'd have to modify all the > definitions where we perform FETCH & SEARCH (AFAIK these two commands > are the only affected). It's possible that all that would be necessary is to add a routine at the bottom of `nnimap-transform-headers', to sort the buffer text. The SEARCH command is handled differently, I believe. > 2. Modify the functions in gnus-range.el to accept unsorted lists > > I don't know the internals good enough to tell if this would be > enough. There might be other parts in Gnus which also expect sorted > headers/messages/lists/etc that I'm not aware of. I don't think modifying gnus-range is a good idea -- if that code requires sorted ranges, we should just make sure it's always given sorted ranges.
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.
"Eric Abrahamsen" <eric@ericabrahamsen.net> writes: > Yes! That's it, thanks very much. The question remains where exactly to > address this, but it's good to know why it's behaving this way. I'll put > this on the list. I don't think we have good/elegant way to do it. I see two options: 1. Implement custom sorting in nnimap.el back end. This would require substantial work because we'd have to modify all the definitions where we perform FETCH & SEARCH (AFAIK these two commands are the only affected). 2. Modify the functions in gnus-range.el to accept unsorted lists I don't know the internals good enough to tell if this would be enough. There might be other parts in Gnus which also expect sorted headers/messages/lists/etc that I'm not aware of. -- Kuba Ječmínek (http://kubajecminek.cz)
>>>>> "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
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 :)
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."
Jakub Ječmínek <kuba@kubajecminek.cz> writes:
> "Eric Abrahamsen" <eric@ericabrahamsen.net> writes:
>
>> Huh. Yeah, I absolutely believe it's true, I just wish I could pinpoint
>> where.
>
> Ok, I think I've found it. The problem is that we're feeding unsorted
> lists into a bunch of functions that require lists to be sorted (a lot
> of functions do in 'gnus-range.el').
Yes! That's it, thanks very much. The question remains where exactly to
address this, but it's good to know why it's behaving this way. I'll put
this on the list.
Thanks,
Eric
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?
And I'm giving them away. For more details, see: https://lars.ingebrigtsen.no/2024/02/22/can-you-spot-the-date-i-said-im-done/ (If you respond to this message, leave the mailing list off of the CCs -- otherwise I won't see your email.)
>>>>> "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
"Eric Abrahamsen" <eric@ericabrahamsen.net> writes: > Huh. Yeah, I absolutely believe it's true, I just wish I could pinpoint > where. Ok, I think I've found it. The problem is that we're feeding unsorted lists into a bunch of functions that require lists to be sorted (a lot of functions do in 'gnus-range.el'). **Example 1:** Inside the body of 'gnus-select-newsgroup' ('gnus-sum.el'). (setq gnus-newsgroup-unreads (gnus-sorted-nintersection gnus-newsgroup-unreads fetched-articles)) ... (gnus-update-missing-marks (gnus-sorted-difference articles fetched-articles)) **Example 2:** Inside the body of 'nnimap-update-info' ('nnimap.el'). (let* ((unread (gnus-compress-sequence (gnus-set-difference (gnus-set-difference existing (gnus-sorted-union (cdr (assoc '%Seen flags)) (cdr (assoc '%Deleted flags)))) (cdr (assoc '%Flagged flags))))) (read (range-difference (cons start-article high) unread))) -- Kuba Ječmínek (http://kubajecminek.cz)
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!
Bjørn Mork <bjorn@mork.no> writes:
> Jakub Ječmínek <kuba@kubajecminek.cz> writes:
>> "Eric Abrahamsen" <eric@ericabrahamsen.net> writes:
>>
>>> I also wasn't able to find anything explicit in RFC 3501 or 9051 about
>>> the order of FETCH responses -- for my information, can you point me in
>>> the right direction?
>>
>> That's the thing. There's nothing explicit in RFC 3501 about the message
>> order so AFAIK the consensus is that UIDs don't have to be sorted.
>
> I was curiuos about this too and went looking. I believe the definition
> of "sequence-set" (which is what the ID range in the FETCH request is)
> on https://datatracker.ietf.org/doc/html/rfc3501#page-90 suggests that
> clients should expect replies in any order:
>
> Servers MAY coalesce overlaps and/or execute the sequence in any
> order.
Thanks! I hadn't looked as far as the formal syntax section, that's helpful.
Jakub Ječmínek <kuba@kubajecminek.cz> writes: > "Eric Abrahamsen" <eric@ericabrahamsen.net> writes: > >> I also wasn't able to find anything explicit in RFC 3501 or 9051 about >> the order of FETCH responses -- for my information, can you point me in >> the right direction? > > That's the thing. There's nothing explicit in RFC 3501 about the message > order so AFAIK the consensus is that UIDs don't have to be sorted. I was curiuos about this too and went looking. I believe the definition of "sequence-set" (which is what the ID range in the FETCH request is) on https://datatracker.ietf.org/doc/html/rfc3501#page-90 suggests that clients should expect replies in any order: Servers MAY coalesce overlaps and/or execute the sequence in any order. Bjørn
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
>>>>> "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
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?