* feature request: differentiate between read and automatically marked read @ 2022-02-03 8:50 Eric S Fraga 2022-02-03 9:10 ` Eric S Fraga 2022-02-03 12:26 ` dick 0 siblings, 2 replies; 11+ messages in thread From: Eric S Fraga @ 2022-02-03 8:50 UTC (permalink / raw) To: ding Hello all, a simple feature request follows. I use adaptive scoring and rely on it. It would be nice to be able to distinguish between articles that I have read and those that have automatically been marked as read because of their low score. At present, any article with a negative score (but above the automatically read threshold) that has been read and articles marked as read automatically all use the 'gnus-summary-low-read' face. It would be great to have a further level face, maybe 'gnus-summary-marked-read', one for those beyond the threshold. I must admit to not having looked at the code to see how easy this would be to do. I will try to do so but thought I'd bring up the suggestion first... ;-) Thank you, eric -- Eric S Fraga with org 9.5.2 in Emacs 29.0.50 on Debian 11.2 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: feature request: differentiate between read and automatically marked read 2022-02-03 8:50 feature request: differentiate between read and automatically marked read Eric S Fraga @ 2022-02-03 9:10 ` Eric S Fraga 2022-02-03 12:26 ` dick 1 sibling, 0 replies; 11+ messages in thread From: Eric S Fraga @ 2022-02-03 9:10 UTC (permalink / raw) To: ding Hey hum; I should have known better: gnus-summary-highlight which can be customised. Ignore the noise! <blush> -- Eric S Fraga with org 9.5.2 in Emacs 29.0.50 on Debian 11.2 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: feature request: differentiate between read and automatically marked read 2022-02-03 8:50 feature request: differentiate between read and automatically marked read Eric S Fraga 2022-02-03 9:10 ` Eric S Fraga @ 2022-02-03 12:26 ` dick 2022-02-03 12:38 ` Tassilo Horn 2022-02-03 12:50 ` Eric S Fraga 1 sibling, 2 replies; 11+ messages in thread From: dick @ 2022-02-03 12:26 UTC (permalink / raw) To: Eric S Fraga; +Cc: ding ESF> I use adaptive scoring and rely on it. You'd be the first person or bot I've heard say this. From Gnus Manual Section 8.6 "Initial impressions seem to indicate that it's [i.e., adaptive scoring] totally useless as it stands." Like most Gnus things, scoring is a bear to configure, but worse, its default bag-of-words approach would get it wrong most of the time. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: feature request: differentiate between read and automatically marked read 2022-02-03 12:26 ` dick @ 2022-02-03 12:38 ` Tassilo Horn 2022-02-03 13:04 ` dick 2022-02-03 12:50 ` Eric S Fraga 1 sibling, 1 reply; 11+ messages in thread From: Tassilo Horn @ 2022-02-03 12:38 UTC (permalink / raw) To: dick; +Cc: Eric S Fraga, ding dick <dick.r.chiang@gmail.com> writes: > ESF> I use adaptive scoring and rely on it. > > You'd be the first person or bot I've heard say this. > > From Gnus Manual Section 8.6 "Initial impressions seem to indicate > that it's [i.e., adaptive scoring] totally useless as it stands." > > Like most Gnus things, scoring is a bear to configure, but worse, its > default bag-of-words approach would get it wrong most of the time. Adaptive scoring is not a bag-of-words approach. Usually, you'd use it to up-score threads you have actively read (automatically, just by the fact that you read messages in the thread) and down-score threads you caught up without reading (again, automatically by the vitue of catching up the summary without reading some messages). Then, when sorting threads according to score, you get threads of interest on top and the others below. Like for Eric, that has served me well for years. Bye, Tassilo ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: feature request: differentiate between read and automatically marked read 2022-02-03 12:38 ` Tassilo Horn @ 2022-02-03 13:04 ` dick 2022-02-03 13:34 ` Eric S Fraga 0 siblings, 1 reply; 11+ messages in thread From: dick @ 2022-02-03 13:04 UTC (permalink / raw) To: Tassilo Horn; +Cc: Eric S Fraga, ding > Adaptive scoring is not a bag-of-words approach. It is, you just don't know it yet. The default is bag-of-lines, but setting `gnus-use-adaptive-scoring` to `(word)` is bag-of-words. In either case, it's semantic-free tallying. Far be it for me to instruct others on what works for them. Just noting my surprise to the community. I know of no companies, Google-scale or otherwise, who have stood behind an algo that opines about the read-worthiness of one's mail unless the mail is 99.98% probable spam. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: feature request: differentiate between read and automatically marked read 2022-02-03 13:04 ` dick @ 2022-02-03 13:34 ` Eric S Fraga 0 siblings, 0 replies; 11+ messages in thread From: Eric S Fraga @ 2022-02-03 13:34 UTC (permalink / raw) To: ding On Thursday, 3 Feb 2022 at 08:04, dick wrote: > In either case, it's semantic-free tallying. It is. Yes, semantic based logic could arguably be "better" but sorting without semantics can be useful. Would I make any claims about it always working? No, but what matters (to me) is that it works in practice for my use case. YMMV, of course. > I know of no companies, Google-scale or otherwise, who have stood behind > an algo that opines about the read-worthiness of one's mail unless the > mail is 99.98% probable spam. So what? Absence of evidence is not evidence of absence... ;-) -- Eric S Fraga with org 9.5.2 in Emacs 29.0.50 on Debian 11.2 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: feature request: differentiate between read and automatically marked read 2022-02-03 12:26 ` dick 2022-02-03 12:38 ` Tassilo Horn @ 2022-02-03 12:50 ` Eric S Fraga 2022-02-05 8:51 ` Uwe Brauer 1 sibling, 1 reply; 11+ messages in thread From: Eric S Fraga @ 2022-02-03 12:50 UTC (permalink / raw) To: ding On Thursday, 3 Feb 2022 at 07:26, dick wrote: > You'd be the first person or bot I've heard say this. I've never been called a bot before. :-) > From Gnus Manual Section 8.6 "Initial impressions seem to indicate that > it's [i.e., adaptive scoring] totally useless as it stands." > > Like most Gnus things, scoring is a bear to configure, but worse, its > default bag-of-words approach would get it wrong most of the time. Well, it works for me. Yes, I spent some time getting the weights right for the various actions used for scoring but, at the very least, it does sort my emails in order of decreasing relevance/importance most of the time. And it does a good job of automatically marking as read emails that I am seldom going to read. Also works well for some of the newsgroups (e.g. emacs.help and emacs.devel) and some rss feeds (arxiv). For the record, my settings are: #+begin_src emacs-lisp (setq gnus-default-adaptive-score-alist '(;(gnus-kill-file-mark) ;;(gnus-unread-mark) ;; (gnus-read-mark (from 5) (subject 30)) (gnus-replied-mark (from 50) (subject 10)) (gnus-read-mark (from 30) (subject 10)) (gnus-cached-mark (from 30) (subject 10)) (gnus-forwarded-mark (from 10) (subject 5)) (gnus-saved-mark (from 10) (subject 5)) (gnus-expirable-mark (from 0) (subject 0)) (gnus-catchup-mark (from -5) (subject -30)) (gnus-killed-mark (subject -100)) (gnus-del-mark (from -10) (subject -50))) gnus-default-adaptive-word-score-alist '((42 . 3) ;cached (65 . 2) ;replied (70 . 1) ;forwarded (82 . 1) ;read (67 . -1) ;catchup (69 . 0) ;expired (75 . -3) ;killed (114 . -3)) ;deleted ) #+end_src and I've been using these now for a few years. I should add that I do have some fixed scores as well so, for instance, emails to me from the PhD students I supervise always score high no matter what the subject is. -- Eric S Fraga with org 9.5.2 in Emacs 29.0.50 on Debian 11.2 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: feature request: differentiate between read and automatically marked read 2022-02-03 12:50 ` Eric S Fraga @ 2022-02-05 8:51 ` Uwe Brauer 2022-02-05 9:29 ` Eric S Fraga 0 siblings, 1 reply; 11+ messages in thread From: Uwe Brauer @ 2022-02-05 8:51 UTC (permalink / raw) To: ding [-- Attachment #1: Type: text/plain, Size: 3135 bytes --] >>> "ESF" == Eric S Fraga <e.fraga@ucl.ac.uk> writes: > On Thursday, 3 Feb 2022 at 07:26, dick wrote: >> You'd be the first person or bot I've heard say this. > I've never been called a bot before. :-) >> From Gnus Manual Section 8.6 "Initial impressions seem to indicate that >> it's [i.e., adaptive scoring] totally useless as it stands." >> >> Like most Gnus things, scoring is a bear to configure, but worse, its >> default bag-of-words approach would get it wrong most of the time. > Well, it works for me. Yes, I spent some time getting the weights right > for the various actions used for scoring but, at the very least, it does > sort my emails in order of decreasing relevance/importance most of the > time. And it does a good job of automatically marking as read emails > that I am seldom going to read. > Also works well for some of the newsgroups (e.g. emacs.help and > emacs.devel) and some rss feeds (arxiv). > For the record, my settings are: > #+begin_src emacs-lisp > (setq gnus-default-adaptive-score-alist > '(;(gnus-kill-file-mark) > ;;(gnus-unread-mark) > ;; (gnus-read-mark (from 5) (subject 30)) > (gnus-replied-mark (from 50) (subject 10)) > (gnus-read-mark (from 30) (subject 10)) > (gnus-cached-mark (from 30) (subject 10)) > (gnus-forwarded-mark (from 10) (subject 5)) > (gnus-saved-mark (from 10) (subject 5)) > (gnus-expirable-mark (from 0) (subject 0)) > (gnus-catchup-mark (from -5) (subject -30)) > (gnus-killed-mark (subject -100)) > (gnus-del-mark (from -10) (subject -50))) > gnus-default-adaptive-word-score-alist '((42 . 3) ;cached > (65 . 2) ;replied > (70 . 1) ;forwarded > (82 . 1) ;read > (67 . -1) ;catchup > (69 . 0) ;expired > (75 . -3) ;killed > (114 . -3)) ;deleted > ) > #+end_src Thanks for sharing, this is an issue that is in my heads for years but I never took the time to look into it further. However more and more I feel I need it. Right now I work with registries and mark threads as IMPORTANT, TODO, DONE etc, but it is not that useful as I expected, mainly because you cannot restrict the summary buffer to registries (a bug we discovered some weeks ago). So may this is a way to go > and I've been using these now for a few years. > I should add that I do have some fixed scores as well so, for instance, > emails to me from the PhD students I supervise always score high no > matter what the subject is. That is to say you score according to their email address? I am extremely interested in such a configuration, since I right now need it. Would you mind sharing (off list if necessary) Thanks Uwe [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 5673 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: feature request: differentiate between read and automatically marked read 2022-02-05 8:51 ` Uwe Brauer @ 2022-02-05 9:29 ` Eric S Fraga 2022-02-05 10:36 ` Uwe Brauer 0 siblings, 1 reply; 11+ messages in thread From: Eric S Fraga @ 2022-02-05 9:29 UTC (permalink / raw) To: ding On Saturday, 5 Feb 2022 at 09:51, Uwe Brauer wrote: > That is to say you score according to their email address? I am > extremely interested in such a configuration, since I right now need it. > > Would you mind sharing (off list if necessary) This is actually the one easy bit about scoring. In the summary buffer, if there is an email from somebody that you want to have scored high, type C-u NNN I a r p REGEXP-FOR-EMAIL-ADDRESS RET where NNN is the adjustment to the score you want to assign to the person's email, "I" means "increase score", "a" means "address", "r" means regular expression for matching (you can use exact matching if you wish), "p" for permanent storing the score, and lastly the regular expression for matching emails from that person which will be pre-filled with the address of the current email in the summary buffer. For my PhD students, I use 1000 for the adjustment to the score. If you use L instead of I, you lower the score for those you don't want to see (or you deem as less important). -- Eric S Fraga with org 9.5.2 in Emacs 29.0.50 on Debian 11.2 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: feature request: differentiate between read and automatically marked read 2022-02-05 9:29 ` Eric S Fraga @ 2022-02-05 10:36 ` Uwe Brauer 2022-02-07 12:28 ` Eric S Fraga 0 siblings, 1 reply; 11+ messages in thread From: Uwe Brauer @ 2022-02-05 10:36 UTC (permalink / raw) To: ding [-- Attachment #1: Type: text/plain, Size: 1572 bytes --] >>> "ESF" == Eric S Fraga <e.fraga@ucl.ac.uk> writes: > On Saturday, 5 Feb 2022 at 09:51, Uwe Brauer wrote: >> That is to say you score according to their email address? I am >> extremely interested in such a configuration, since I right now need it. >> >> Would you mind sharing (off list if necessary) > This is actually the one easy bit about scoring. In the summary buffer, > if there is an email from somebody that you want to have scored high, > type > C-u NNN I a r p REGEXP-FOR-EMAIL-ADDRESS RET > where NNN is the adjustment to the score you want to assign to the > person's email, "I" means "increase score", "a" means "address", "r" > means regular expression for matching (you can use exact matching if you > wish), "p" for permanent storing the score, and lastly the regular > expression for matching emails from that person which will be pre-filled > with the address of the current email in the summary buffer. > For my PhD students, I use 1000 for the adjustment to the score. > If you use L instead of I, you lower the score for those you don't want > to see (or you deem as less important). Thanks very much!! Fortunately the email is offered when running this, oops cumbersome command. I tried it out with our email of course. 🙃 Your messages are then in bold face (did you fiddle the setting of the display variable you mentioned earlier?) BTW I wish that scoring would it a bit easier to set up, what you sent me I shall copy in one of my important registers (I use copy-to-register a lot) Uwe [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 5673 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: feature request: differentiate between read and automatically marked read 2022-02-05 10:36 ` Uwe Brauer @ 2022-02-07 12:28 ` Eric S Fraga 0 siblings, 0 replies; 11+ messages in thread From: Eric S Fraga @ 2022-02-07 12:28 UTC (permalink / raw) To: ding On Saturday, 5 Feb 2022 at 11:36, Uwe Brauer wrote: > Your messages are then in bold face (did you fiddle the setting of the > display variable you mentioned earlier?) Gnus has faces for the various levels of scores: high, normal, low; and categories within these scores: ancient, read, ticked, and unread. And then settings for what is a high or low scoring article: gnus-summary-default-low-score, etc. And, yes: I had to play with gnus-summary-highlight and added the condition: ((< score gnus-summary-mark-below) . gnus-summary-cancelled) near the end of the list of conditions to use the gnus-summary-cancelled face. > BTW I wish that scoring would it a bit easier to set up, what you sent Well, I guess I find it rather easy as it's either I for increase or L for lower and then just follow the prompts with "?" available at each prompt to remind you what the options are. There are also the V keymap bindings in summary mode for seeing the effect of scores. Adaptive scoring is trickier, mind you. -- Eric S Fraga with org 9.5.2 in Emacs 29.0.50 on Debian 11.2 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-02-07 12:29 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-02-03 8:50 feature request: differentiate between read and automatically marked read Eric S Fraga 2022-02-03 9:10 ` Eric S Fraga 2022-02-03 12:26 ` dick 2022-02-03 12:38 ` Tassilo Horn 2022-02-03 13:04 ` dick 2022-02-03 13:34 ` Eric S Fraga 2022-02-03 12:50 ` Eric S Fraga 2022-02-05 8:51 ` Uwe Brauer 2022-02-05 9:29 ` Eric S Fraga 2022-02-05 10:36 ` Uwe Brauer 2022-02-07 12:28 ` Eric S Fraga
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).