Re: How to read mail from local spool?
You may need to add/subscribe to the relevant group. Go to the server buffer (^ from the Group view) and look for an nnml server. Enter the server (RET) and subscribe (u) to whichever group makes sense. It's been so long since I did this that I cannot remember what is needed. -- Eric S Fraga via gnus (Emacs 30.0.50 2024-02-26) on Debian bullseye/sid
Re: How to read mail from local spool?
On Wednesday, 28 Feb 2024 at 12:20, Björn Bidar wrote: > Eric S Fraga writes: > >> (setq mail-sources '((file :path "/var/mail/userid"))) > > Better would be: > (setq mail-sources `,((file :path ,(concat "/var/mail/"(user-login-name) Better in the sense of most generic/universal, I guess. Maybe that is what should be in the manual! Thank you, eric -- Eric S Fraga via gnus (Emacs 30.0.50 2024-02-26) on Debian bullseye/sid
Re: How to read mail from local spool?
Putting this line in your .gnus.el should work: (setq mail-sources '((file :path "/var/mail/userid"))) Replace userid with your own login, of course. In principle, just (setq mail-sources '((file))) should also work. Check the "Fetching mail" section in the info manual for gnus. -- Eric S Fraga via gnus (Emacs 30.0.50 2024-02-26) on Debian 12.0
Re: Strange line-spacing in headers?
Hello, On Sunday, 11 Feb 2024 at 23:42, Lars-Johan Liman wrote: > I wonder if that's inherited from the GNUS default font, rather than The easy way to find out is to move point to one of the header lines and then "C-u C-x =" (what-cursor-position but with C-u to ask for all the details)! One of the things this will tell you is the face(s) associated with where point is. For the record, I don't see extra spacing in my gnus article view. -- Eric S Fraga via gnus (Emacs 30.0.50 2023-07-11) on Debian bullseye/sid
Re: Inhibiting gnus-get-new-news at startup
On Saturday, 6 Jan 2024 at 09:13, Lars-Johan Liman wrote:
> As for toggling: my queued messages are not automagically sent when I
> toggle to on-line ("plugged"). Do you know if this hinges on some
> setting somewhere? Any hints? It would be A Good Thing(tm) to have.
My bad! It's a customization I have in my .gnus.el file:
--8<---cut here---start->8---
(defun esf/gnus-agent-plugged ()
(gnus-group-send-queue))
(add-hook 'gnus-agent-plugged-hook 'esf/gnus-agent-plugged)
--8<---cut here---end--->8---
You could probably simply add 'gnus-group-send-queue to the hook without
defining an extra function.
--
Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2
Re: Inhibiting gnus-get-new-news at startup
I do the same: starting unplugged. This works well as I use nnml to store my emails and have all nttp groups under control of the agent. To avoid forgetting about queued emails, I have my queue group at level 1 and it's the first group in the Group buffer view. To manually send queued emails, it's "J S" and you don't have to be in the queue group for this: it works from the Group buffer. But, for me, when I toggle to plugged status, all of my queued emails are sent. If you wish to remain unplugged, J S will send them regardless. -- Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2
Re: Inhibiting gnus-get-new-news at startup
That sounds great! I look forward to trying it out. Thank you. -- Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2
Re: Inhibiting gnus-get-new-news at startup
Eric S Fraga writes: > On Tuesday, 2 Jan 2024 at 21:34, Husain Alshehhi wrote: >> I might have spoken too soon. It appears that the issue is not with nntp >> groups, but with nnrss. I ran the profile and saw the following: > > Which is why I switched to elfeed for rss feeds. I would prefer to use > gnus for everything (email, news, blogs) but the performance hit is too > high. elfeed is very fast in comparison. There will be a newly-implemented backend for Atom landing in Gnus before too long, and I think we're hoping to make it work for RSS as well. I'll try to make sure that it does better with situations like this. I also find nnrss too slow for practical use, and hope it's something fixable.
Re: Inhibiting gnus-get-new-news at startup
On Tuesday, 2 Jan 2024 at 21:34, Husain Alshehhi wrote: > I might have spoken too soon. It appears that the issue is not with nntp > groups, but with nnrss. I ran the profile and saw the following: Which is why I switched to elfeed for rss feeds. I would prefer to use gnus for everything (email, news, blogs) but the performance hit is too high. elfeed is very fast in comparison. -- Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2
Re: Inhibiting gnus-get-new-news at startup, Re: Inhibiting gnus-get-new-news at startup, Re: Inhibiting gnus-get-new-news at startup
James Thomas writes: > Husain Alshehhi wrote: > >> Is there a way to prevent gnus to get new news at startup time, and >> only do it manually? > > Eric Abrahamsen wrote: > >> The command `gnus-no-server' will likely do what you want. > > IIRC this will only stop the primary select method. By default it will only activate groups at levels 1 and 2. In my case, anyway, that only connects to the nndraft server.
Re: Inhibiting gnus-get-new-news at startup
Husain Alshehhi writes: > Hello, > > When gnus starts (M-x gnus), it automatically get new news. This is a > reasonable default. But when I start gnus multiple times to look up a > message, I have to wait few seconds for it to start. Is there a way to > prevent gnus to get new news at startup time, and only do it manually? The command `gnus-no-server' will likely do what you want.
Re: Emphasizing text when composing mails?
Untested but maybe M-x org-emphasize? -- Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2
Re: Need help writing predicate function
You might want to look at what gnus does. In particular, it copies the article buffer first using gnus-copy-article-buffer (in gnus-msg.el) before considering the styles. That copy of the article buffer should be accessible in your max-gnus-predicate function... if I understand the gnus code correctly which is a big *if*. -- Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2
Re: Gnus and authinfo
Just in case, my auth-sources variable is set to ((:source "~/s/dotfiles/authinfo.gpg") (:source "~/.authinfo")) I wonder whether something has changed along the way that requires the :directive element? -- Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2
Re: Gnus and authinfo
"Otto J. Makela" writes: > Sorry if this is a very much FAQ item, but I really don't know where > else I could ask this question. > > With an operating system upgrade (to Fedora Linux 39) I also got a emacs > upgrade (to version 29.1) Some time in the ancient past I've simply set > > (setq gnus-select-method '(nntp "news.eternal-september.org")) > > in my .gnurc, and this still seems to work to select this as my default > nntp server. However, for some reason, the gnus 5.13 that came with this > emacs version no longer seems to read the plain-text .authinfo file from > my home directory. > > So at every gnus start time it asks me to manually enter the username > and password for this nntp server. What has changed, has the plain-text > file been depreciated in favor of the pgp-encrypted version? I couldn't > find any information on such a change. Both encrypted and unencrypted versions are supported; maybe the `auth-sources' option only points at the encrypted version?
Re: Gnus threads too many articles together
John Haman writes: > Everyday I get an email from my bank saying what my account balance > is. These are all different emails, but Gnus puts them all in one > thread, I think because they have the same subject. If I go into my > bank group and insert old articles, I get > > > O Jan 24, 2023 Alliant Alerts 0 Account Balance Notification > O Jan 24, 2023 Alliant Alerts 0 ╰─► > O Jan 25, 2023 Alliant Alerts 0 ╰─► > O Jan 27, 2023 Alliant Alerts 0 ╰─► > O Jan 30, 2023 Alliant Alerts 0 ╰─► > O Jan 31, 2023 Alliant Alerts 0 ╰─► > > > I don't know the most informative way to ask this question, but is there a > way to make Gnus just thread distinct conversations together (like Outlook.) > > I'd like to not disable threads entirely. By default, `gnus-summary-thread-gathering-function' is set to the function `gnus-gather-threads-by-subject', which produces the behavior you're seeing. Try setting it to `gnus-gather-threads-by-references' instead.
Re: Correct ordering of items in mail threads
On Tuesday, 24 Oct 2023 at 09:58, Pankaj Jangid wrote: > Yes. I tried this suggestion. But this doesn't have any effect on the > output. I tried it with all the combinations of > "gnus-summary-make-false-root". Default being 'adopt'. Interesting. Adding this to my config (years ago) fixed the problem I was having that, IIRC, was essentially the same as what you are seeing. Oh well, complex systems... -- Eric S Fraga via gnus (Emacs 30.0.50 2023-06-19) on Debian 12.0
Re: Correct ordering of items in mail threads
Have you tried what I suggested initially: (setq gnus-sort-gathered-threads-function 'gnus-thread-sort-by-date) which tells gnus how to sort the individual posts in a thread, as opposed to how to sort the threads in the summary? -- Eric S Fraga via gnus (Emacs 30.0.50 2023-06-19) on Debian 12.0
Re: How to search for ticked articles
Julien Cubizolles writes: > Julien Cubizolles writes: > > >> I'm using the imap search engine. When I shut off search parsing, >> the "FLAGGED" search query does indeed return the ticked articles, when >> "mark:flag" didn't. But I tried again (with search parsing on) with the >> query "mark:flagged" and it works ! > > Actually, I was wrong, I'm using notmuch to search a maildir group. The > results, with gnus-search-use-parsed-queries turned off, are : > > No results with : > mark:flag > tag:flag > flagged > > Success with : > mark:flagged > tag:flagged > FLAGGED Is this a maildir that used to be managed by IMAP (like Dovecot)? I can't believe that notmuch uses a "FLAGGED" notation on its own. Nor does it use a "mark" search term. Are you sure it isn't just finding messages with "mark:flagged" in them?
Re: Correct ordering of items in mail threads
Adam Sjøgren writes: > Eric writes: > >> I meant the articles don't always arrive at Gnus in the order they >> were originally authored. > > Got it :-) > > I have configured Gnus to sort a bunch of groups by date instead of by > number, and I can't feel the difference (in speed) -- this on a 4 year > old laptop. > > Maybe I'm just growing slower ;-) Or all this just seems to matter less!
Re: Correct ordering of items in mail threads
Adam Sjøgren writes: > Eric writes: > >> sorting by number _usually_ means sorting by arrival time, but >> there's no contract there. > > When do the numbers given to articles in Gnus not reflect _arrival_ > time? Sorry, that was backwards -- I meant the articles don't always arrive at Gnus in the order they were originally authored.
Re: Correct ordering of items in mail threads
Pankaj Jangid writes: > Eric S Fraga writes: > >> On Saturday, 21 Oct 2023 at 10:41, Pankaj Jangid wrote: >>> ;; Threading >>> '(gnus-thread-sort-functions >>>'(gnus-thread-sort-by-number)) >>> '(gnus-summary-thread-gathering-function >>>'gnus-gather-threads-by-references) >>> >> >> I have >> >> (setq gnus-sort-gathered-threads-function 'gnus-thread-sort-by-date) >> >> along with similar (but slightly different) settings for the variables >> you've set. This variable says how to sort *within* a thread which may >> be what you are looking for. > > In fact, I wanted to use 'gnus-thread-sort-by-date for > gnus-thread-sort-functions. But the docstring discouraged me. > > Also note that sorting by date is often much slower than sorting by > number, and the sorting order is very similar. (Sorting by date means > sorting by the time the message was sent, sorting by number means > sorting by arrival time.) I think this is the trade-off, though -- sorting by number _usually_ means sorting by arrival time, but there's no contract there. It's entirely possible for messages to arrive out-of-order, and when they do, you get a weird display. I think a lot of what was slow in Gnus is gradually becoming less slow (with things like native compilation and whatnot) and you might try sorting by date and just seeing how bad it is.
Re: Correct ordering of items in mail threads
On Saturday, 21 Oct 2023 at 10:41, Pankaj Jangid wrote: > ;; Threading > '(gnus-thread-sort-functions >'(gnus-thread-sort-by-number)) > '(gnus-summary-thread-gathering-function >'gnus-gather-threads-by-references) > I have (setq gnus-sort-gathered-threads-function 'gnus-thread-sort-by-date) along with similar (but slightly different) settings for the variables you've set. This variable says how to sort *within* a thread which may be what you are looking for. -- Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.1
Re: How to search for ticked articles
Julien Cubizolles writes: > Eric Abrahamsen writes: > >> Julien Cubizolles writes: >> >>> I used to use the "mark:flag" search query to look for ticked articles >>> with gnus-search. I recently noticed that it doesn't return any articles >>> anymore in groups with ticked articles. >>> >>> What exactly does the "flag" mark represent, and is there a better way >>> to look for dormant or ticked articles ? >> >> These things are all search-engine dependent. Notmuch will turn >> "mark:flag" into "tag:flag", and IMAP will turn it into "FLAGGED". >> >> What search engine are you using in this case? The first thing to try >> is always shutting off search parsing (either fully, by setting >> `gnus-search-use-parsed-queries' to nil, or temporarily, using the >> prefix argument). Then get the search working using the search engine's >> native syntax. Then come back here and tell me how it went :) > > I'm using the imap search engine. When I shut off search parsing, > the "FLAGGED" search query does indeed return the ticked articles, when > "mark:flag" didn't. But I tried again (with search parsing on) with the > query "mark:flagged" and it works ! Hmm, that doesn't seem right; you can see that both "mark:flag" and "mark:flagged" get transformed into the same IMAP search term, namely "FLAGGED". (let ((srv (make-instance 'gnus-search-imap)) (flag (gnus-search-parse-query "mark:flagged")) (flagged (gnus-search-parse-query "mark:flag"))) (format "%s == %s" (gnus-search-transform srv flag) (gnus-search-transform srv flagged))) => "FLAGGED == FLAGGED" I just tried it with an IMAP server, and all of "mark:flag", "mark:flagged", and "mark:!" were transformed into "FLAGGED" and produced the right search results. If you have a moment, you could try edebugging the `gnus-search-imap-search-command' function, and seeing what's happening there. The QUERY parameter should already be "FLAGGED" at that point. Thanks, Eric
Re: Does Gnus read and sync the read with IMAP?
Björn Bidar writes: > Dan Christensen writes: > >> On Oct 20, 2023, Eric Abrahamsen wrote: >> >>> Dan Christensen writes: >>> >>>> Here's a followup question: how can I make Gnus update the marks >>>> for >>>> *all* IMAP groups. >>> >>> I once asked Lars about this -- since the IMAP server should be the >>> source of truth for all information about the messages, why does >>> Gnus >>> store its own marks data for IMAP groups at all? Why not just > > How many imap server support imap metadata? Clients such as Thunderbird > already safe their metadata in imap. > >>> refresh >>> from the server at each startup? I think he said that for many large >>> groups that would end up being prohibitively slow. >> >> I agree that it would be too slow for many people, especially with >> remote IMAP servers. So I'd like an optional setting. But I don't >> think it should have anything to do with Gnus shutdown and startup. > > Why would it be to slow? Other mail clients fetch the read > status for each mail when they update the state of each > imap mailbox. I have never tried it, so I don't know if it would be slow or not. But this wouldn't just update the read status, this would remove all existing marks and refresh them from the server: ticks, replied, forwarded, everything. I could imagine that being pretty slow.
Re: How to search for ticked articles
Julien Cubizolles writes: > I used to use the "mark:flag" search query to look for ticked articles > with gnus-search. I recently noticed that it doesn't return any articles > anymore in groups with ticked articles. > > What exactly does the "flag" mark represent, and is there a better way > to look for dormant or ticked articles ? These things are all search-engine dependent. Notmuch will turn "mark:flag" into "tag:flag", and IMAP will turn it into "FLAGGED". What search engine are you using in this case? The first thing to try is always shutting off search parsing (either fully, by setting `gnus-search-use-parsed-queries' to nil, or temporarily, using the prefix argument). Then get the search working using the search engine's native syntax. Then come back here and tell me how it went :)
Re: Does Gnus read and sync the read with IMAP?
Dan Christensen writes: > On Oct 19, 2023, Björn Bidar wrote: > >> How can I make Gnus to fetch the read status from Imap? > > In the *Group* buffer, you can make Gnus update the marks from the IMAP > server using `M-g'. > > Here's a followup question: how can I make Gnus update the marks for > *all* IMAP groups. I've tried various incantations. `g' doesn't work, > nor does `M-g' on a topic containing the IMAP groups. In fact, I'd > like Gnus to always refresh IMAP groups in the thorough way that `M-g' > on the group does, since I'm accessing a local IMAP server. I once asked Lars about this -- since the IMAP server should be the source of truth for all information about the messages, why does Gnus store its own marks data for IMAP groups at all? Why not just refresh from the server at each startup? I think he said that for many large groups that would end up being prohibitively slow. I guess that might be true, I don't know. I do think that Gnus should be much, much more willing to dump its marks store and refresh if anything at all seems to be getting out of whack. Maybe we could put in a customization option that would clear out Gnus' nnimap group marks at shutdown, which would force a full refresh at the next startup. That feels like a pretty major change, I'm not sure what the knock-on consequences might be. The other common problem (that Bob Newell ran into recently) is that Gnus' article numbers are purely an internal convention, and don't have any real correspondence to external reality, yet are relied upon pretty heavily within Gnus to "make sense" as an indicator of sequence. When they get out of whack you are SOL. I don't see a great solution to that. Eric
Re: Does Gnus read and sync the read with IMAP?
Michael Heerdegen writes: > Bob Newell writes: > >> This goes well beyond my very limited knowledge so I did an >> experiment. I went to the gmail web interface and found an >> already-opened message in the All Mail folder (really a label) >> that I knew for certain I had originally opened in gnus, so >> therefore gnus would have known about the message. I marked >> it unread (on the web) and moved it back to INBOX. >> >> Then I started up gnus and gnus saw the message as an unread >> INBOX message. Based on this it appears the answer is yes, >> gnus did update the status of this previously seen email. >> However I don't know how much if any status information gnus >> actually keeps (and I don't use the registry) so this may or >> may not be meaningless. It certainly seems as if, when >> reopening the group subsequent to shutting down gnus at some >> point, gnus gets a fresh set of information. > > Thanks for doing this experiment. I hoped for that result. > > AFAIU Gnus stores such stuff in a file named ".newsrc.eld" (AFAIR > ".newsrc.el" in older Emacs versions). And indeed, among other things > there seems to be information about "seen" status of messages in that > file, as well as saved status, ticked and dormant status, all of that > Gnus specific stuff, but nothing related to the "read" (or "old") > status. So I guess the "read" status is fetched every time when you > open the group, along with the rest (list of existing messages etc). Here's the mapping between Gnus' marks and IMAP flags, I believe things like "gnus-save" are set as user flags on servers that support that: (defvar nnimap-mark-alist '((read "\\Seen" %Seen) (tick "\\Flagged" %Flagged) (reply "\\Answered" %Answered) (expire "gnus-expire") (dormant "gnus-dormant") (score "gnus-score") (save "gnus-save") (download "gnus-download") (forward "gnus-forward")))
Re: slow saving of scores when leaving a virtual (nnml+) group
On Sunday, 16 Jul 2023 at 04:55, Michael Heerdegen wrote: > At least avoided. Ok, good. Yes, that's a better description! > We should nonetheless create a bug report (M-x report-emacs-bug). Could > you please do that? I think we still need somebody to provide the (more > or less complete) data that shows the slowdown - with other words, a > recipe that doesn't involve setting up Gnus + scoring, to ease the work > of the developers. I will create a bug report. Thank you, eric -- Eric S Fraga via gnus (Emacs 30.0.50 2023-07-10) on Debian 12.0
Re: slow saving of scores when leaving a virtual (nnml+) group
On Friday, 14 Jul 2023 at 01:56, Michael Heerdegen wrote: > I think so, yes. These numbers cannot be interpreted directly as used > memory. It's more like "time spent inside the function, measured > memory-usage wise. Ah, okay. Total misunderstanding on my part! > Hmm. Ok. We could try with M-x trace-function pp-to-string RET > directly before `gnus-summary-exit'. A popup buffer should appear, and > it would be helpful if you could again post the output (with any private > data obfuscated; we are interested in the argument(s) of the function > call(s)). But before that please M-x untrace-all RET. The trace output is difficult to obfuscate so I won't include it here but what it shows is that the function is passed the full contents of the adaptive scoring file, not the static score file. > Are things significantly faster when setting this to pp-28? Very much so! Group exists almost immediately, back to what I used to see. With pp-28, I'm happy! Problem solved. :-) Thank you, eric -- Eric S Fraga via gnus (Emacs 30.0.50 2023-07-10) on Debian 12.0
Re: slow saving of scores when leaving a virtual (nnml+) group
On Thursday, 13 Jul 2023 at 02:18, Michael Heerdegen wrote: > From what source of information do you have the 0.5 GB? >From the original post I made which included mem profiler results: --8<---cut here---start->8--- and memory report, also partly expanded: 832,940,181 99% - command-execute 805,535,710 96% - funcall-interactively 540,874,166 64% - gnus-summary-exit 537,712,423 64%- gnus-score-save 536,634,533 64% - gnus-pp [...] --8<---cut here---end--->8--- It could be that I am misinterpreting those profiler results. > Thanks. I tried the following: I inserted this expression into a buffer > (*scratch* and a buffer in fundamental mode): [...] > then I replaced all line breaks with spaces and called M-: > (pp-fill (point-min) (point-max)). But that succeeds almost > immediately... Not sure what the important different aspect in your > scenario is. I tried this as well and also get results immediately. > Have you tried to change the value of `pp-default-function' btw? No, it's set to pp-fill. Thank you, eric -- Eric S Fraga via gnus (Emacs 30.0.50 2023-07-10) on Debian 12.0
Re: slow saving of scores when leaving a virtual (nnml+) group
On Wednesday, 12 Jul 2023 at 02:48, Michael Heerdegen wrote:
> The slowness, is it only happening for that 600 Bytes file?
I have no idea but I would assume not as I cannot believe that pretty
printing a file (see below) with 12 lines would take 0.5 GB of data to
process.
> How do the contents of that file look like -can you share some of the
> contents so that we can maybe find a recipe (you can replace any
> private information of course)?
--8<---cut here---start->8---
(("subject"
("^xxx .*" 100 nil r))
("from"
("\"name\" " 1 nil e)
[... elided ...]
("name " -1000 nil e)))
--8<---cut here---end--->8---
where the elided are lines that look like the one before or the one
after.
> And...you are using a master built (from when)?
On this computer, yes, master built two days ago.
I hope some of the above helps. But, to be clear, this is not a
critical issue, just a minor annoyance. :-)
--
Eric S Fraga via gnus (Emacs 30.0.50 2023-07-10) on Debian 12.0
Re: slow saving of scores when leaving a virtual (nnml+) group
On Tuesday, 11 Jul 2023 at 04:56, Michael Heerdegen wrote: > Seems the variable is only respected for adaptive score files. For all > others pretty-printing is always used. I guess your score file is not > an adaptive one? I use both adaptive and permanent scores. I have: ((score-file . "/.../work.scores") (adapt-file . "/.../work.adaptive.scores")) for my "work" topic which includes a few nnml groups. The score-file is small (600 bytes!) but the adaptive scores file is around 350 kB in size. Pretty printing the score file should be instantaneous, I would have thought. Puzzled I be! -- Eric S Fraga via gnus (Emacs 30.0.50 2023-06-19) on Debian 12.0
Re: slow saving of scores when leaving a virtual (nnml+) group
On Sunday, 9 Jul 2023 at 07:23, Michael Heerdegen wrote: > And you did not just turn on `gnus-adaptive-pretty-print' by accident? Well, I've had this variable set to t for years now. In any case, I have set it to nil and it's made no difference unfortunately. Which seems strange. Could there be another variable that affects this as I really don't need the score files prettified? I've looked at the parameter settings for individual groups (G p) but seen nothing strange in the nnml groups I'm dealing with. thank you, eric -- Eric S Fraga via gnus (Emacs 30.0.50 2023-07-10) on Debian 12.0
Re: slow saving of scores when leaving a virtual (nnml+) group
On Friday, 7 Jul 2023 at 08:41, Eric Abrahamsen wrote: > Bummer. You can always escalate and just open an Emacs bug -- this is a > perfectly normal type of thing to open a bug about. I'll keep this as my fallback position, once any discussion here has petered out. Thank you. -- Eric S Fraga via gnus (Emacs 30.0.50 2023-07-07) on Debian 12.0
Re: slow saving of scores when leaving a virtual (nnml+) group
On Saturday, 8 Jul 2023 at 03:22, Michael Heerdegen wrote: > And - is it worth the time to pretty print this data at all? This is what I was wondering. The pretty printing could be saved for when somebody wishes to edit the scores, at which point a little delay is not intrusive (or as intrusive). Most of the time, I just want the scores updated quickly so I can go on to the next group. What puzzles me is the very large amount of memory use. My scores file is 334 kB in size. Why does this require half a GB of memory to process? -- Eric S Fraga via gnus (Emacs 30.0.50 2023-07-07) on Debian 12.0
Re: slow saving of scores when leaving a virtual (nnml+) group
Eric S Fraga writes: > On Thursday, 6 Jul 2023 at 08:43, Eric Abrahamsen wrote: >> I've attached a patch that reverts it, you might give this a try? If it >> clearly fixes the problem, I would open a bug report and cc Stefan. > > Hi Eric, > > thank you for this patch. Unfortunately, it does not seem to have had > any impact in my case. Bummer. You can always escalate and just open an Emacs bug -- this is a perfectly normal type of thing to open a bug about.
Re: slow saving of scores when leaving a virtual (nnml+) group
On Thursday, 6 Jul 2023 at 08:43, Eric Abrahamsen wrote: > I've attached a patch that reverts it, you might give this a try? If it > clearly fixes the problem, I would open a bug report and cc Stefan. Hi Eric, thank you for this patch. Unfortunately, it does not seem to have had any impact in my case. -- Eric S Fraga via gnus (Emacs 30.0.50 2023-07-07) on Debian 12.0
Re: slow saving of scores when leaving a virtual (nnml+) group
Eric S Fraga writes: > Hello all, > > recently (past week or two), I've noticed a slow down in leaving some of > my nnml groups. Using the profiler, I see the outcomes shown below, > capturing cpu and memory when entering a virtual group, that collects 3 > different nnml groups, and then immediately leaving that group. A > significant amount of time is taken saving scores, as far as I can tell. > I use adaptive scoring. Nothing with respect to scoring has changed in > my configuration in some time (years probably). > > The offending function appears to be "lisp--local-defform-body-p" with > large memory and cpu use. > > Cpu report (partly expanded): > >10133 79% - command-execute > 8519 66% - funcall-interactively > 4767 37% - gnus-summary-exit > 4659 36%- gnus-score-save > 4655 36% - gnus-pp > 4655 36% - pp > 4655 36% - pp-to-string > 4655 36%- pp-fill > 4647 36% - pp--object > 4627 36% - pp-fill > 4615 36% - pp-fill > 4555 35%- pp-fill > 4263 33% - pp-fill > 4243 33% - indent-according-to-mode > 4243 33% - lisp-indent-line > 4163 32%- calculate-lisp-indent > 4163 32% - lisp-indent-function > 4163 32%lisp--local-defform-body-p > 48 0%+ lisp-ppss A few weeks ago Stefan Monnier made a change to lisp-ppss. It was meant to improve performance, but the timing looks very suspicious and it may have had unexpected side effects. The commit is f411cc3a9578eae4ea4549, I've attached a patch that reverts it, you might give this a try? If it clearly fixes the problem, I would open a bug report and cc Stefan. diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el index 1990630608d..3613c8d88ec 100644 --- a/lisp/emacs-lisp/lisp-mode.el +++ b/lisp/emacs-lisp/lisp-mode.el @@ -876,7 +876,7 @@ lisp-ppss 2 (counting from 0). This is important for Lisp indentation." (unless pos (setq pos (point))) (let ((pss (syntax-ppss pos))) -(if (and (not (nth 2 pss)) (nth 9 pss)) +(if (nth 9 pss) (let ((sexp-start (car (last (nth 9 pss) (parse-partial-sexp sexp-start pos nil nil (syntax-ppss sexp-start))) pss)))
slow saving of scores when leaving a virtual (nnml+) group
Hello all, recently (past week or two), I've noticed a slow down in leaving some of my nnml groups. Using the profiler, I see the outcomes shown below, capturing cpu and memory when entering a virtual group, that collects 3 different nnml groups, and then immediately leaving that group. A significant amount of time is taken saving scores, as far as I can tell. I use adaptive scoring. Nothing with respect to scoring has changed in my configuration in some time (years probably). The offending function appears to be "lisp--local-defform-body-p" with large memory and cpu use. Cpu report (partly expanded): 10133 79% - command-execute 8519 66% - funcall-interactively 4767 37% - gnus-summary-exit 4659 36%- gnus-score-save 4655 36% - gnus-pp 4655 36% - pp 4655 36% - pp-to-string 4655 36%- pp-fill 4647 36% - pp--object 4627 36% - pp-fill 4615 36% - pp-fill 4555 35%- pp-fill 4263 33% - pp-fill 4243 33% - indent-according-to-mode 4243 33% - lisp-indent-line 4163 32%- calculate-lisp-indent 4163 32% - lisp-indent-function 4163 32%lisp--local-defform-body-p 48 0%+ lisp-ppss 240 1% + indent-according-to-mode 72 0%+ gnus-run-hooks 32 0%+ gnus-close-group 4 0%+ gnus-summary-update-info 3688 28% + gnus-topic-select-group 60 0% + file-notify-handle-event 3 0% + execute-extended-command 1614 12% + byte-code 2260 17% Automatic GC 407 3% + timer-event-handler 0 0% ... and memory report, also partly expanded: 832,940,181 99% - command-execute 805,535,710 96% - funcall-interactively 540,874,166 64% - gnus-summary-exit 537,712,423 64%- gnus-score-save 536,634,533 64% - gnus-pp 535,956,310 64% - pp 535,618,670 64% - pp-to-string 535,610,465 64%- pp-fill 533,695,189 63% - pp--object 533,684,957 63% - pp-fill 533,683,933 63% - pp-fill 533,651,141 63%- pp-fill 532,169,752 63% - pp-fill 531,888,880 63% - indent-according-to-mode 531,888,880 63% - lisp-indent-line 484,726,608 58%- calculate-lisp-indent 484,661,024 58% - lisp-indent-function 484,661,024 58%lisp--local-defform-body-p 902,445 0% + indent-according-to-mode 21 0% nnheader-set-temp-buffer 1,609,314 0%+ gnus-summary-update-info 924,174 0%+ gnus-close-group 579,308 0%+ gnus-run-hooks 2,069 0% gnus-score-adaptive 1,529 0%+ gnus-configure-windows 21 0% gnus-set-global-variables 263,358,645 31% + gnus-topic-select-group 839,207 0% + execute-extended-command 463,692 0% + file-notify-handle-event 27,404,471 3% + byte-code 983,687 0% + timer-event-handler 53,056 0% + redisplay_internal (C function) 14,903 0% Automatic GC 6,224 0% + hl-line-highlight 21 0% gnus-set-global-variables 0 0% ... Any suggestions on how to improve the performance? Or is it something I may have done inadvertently? Thank you, eric -- Eric S Fraga via gnus (Emacs 30.0.50 2023-06-29) on Debian 12.0
Re: Gnus fetch freezes emacs
Stephen Berman writes: > On Wed, 05 Jul 2023 11:55:36 -0700 Eric Abrahamsen > wrote: > >> On 07/05/23 10:04 AM, Stephen Berman wrote: >>> On Tue, 04 Jul 2023 20:50:05 -0700 Eric Abrahamsen >>> wrote: > [...] >>>> Using `nntp-connection-timeout' is the proper fix for this problem, it's >>>> just got a bit of unfortunate behavior that needs to be remedied. I'd be >>>> inclined to start a whole new bug report for a fix for that, because >>>> it's really a new issue, with its own larger-reaching design decisions. >>>> I suppose we could merge #52735 with that, though. >>> >>> Feel free to open a new bug for fixing nntp-connection-timeout. I don't >>> know if I can help, other than trying out suggestions and providing >>> feedback. In the meantime I'll keep using my workaround replacement >>> function. >>> >>> But I wonder, could this issue have been triggered by some change in >>> news.gmane.io around early to mid December 2021? Because that's when >>> the problem start for me, and prior to that I don't recall ever having >>> this problem (perhaps sporadically but not with such persistance). >> >> The nntp-connection-timeout variable has been present and nil since >> 1999. I put my original buggy fix in at the end of October 2021, so that >> seems suspicious, but that should only have had an effect if you had set >> nntp-connection-timeout to something other than the default of nil. > > I've never touched nntp-connection-timeout, I only became aware of it > when you mentioned it in this thread. Also, October 2021 is too early: > the early to mid December date stands out to me because in early > December of that year there was a change in my internet service, and I > started experiencing the Gnus problem soon thereafter. At first I > thought it might be due to my change in internet service, but the > problem really was and remains only with fetching news with Gnus (and > not with fetching email with Gnus, which I do from different mail > servers). I also only use news.gmane.io for fetching news, so that's > why I thought maybe something changed there. It's entirely possible! The buggy fix was reverted in early May, so if you stopped seeing the bad behavior then, that would be pretty conclusive.
Re: Gnus fetch freezes emacs
On 07/05/23 10:04 AM, Stephen Berman wrote: > On Tue, 04 Jul 2023 20:50:05 -0700 Eric Abrahamsen > wrote: > >> Stephen Berman writes: >> >>> On Tue, 04 Jul 2023 10:02:34 -0700 Eric Abrahamsen >>> wrote: >>> >>>> Stephen Berman writes: >> >> [...] >> >>> This: >>> >>> (defun srb-gnus-group-get-new-news (&optional arg one-level) >>>(interactive "P") >>>(with-timeout (1 (kill-buffer (nntp-find-connection-buffer >>> nntp-server-buffer)) >>>(gnus-group-get-new-news)) >>> (gnus-group-get-new-news arg one-level))) >>> >>> (define-key gnus-group-mode-map "g" 'srb-gnus-group-get-new-news) >>> >>>> Eric F is just describing the >>>> unfortunate behavior of nntp-connection-timeout, which interrupts the >>>> entire fetching process when it hits the timeout. >>> >>> Is that different than what the above function does with the kill-buffer >>> sexp? (Not a rhetorical question, I know next to nothing about news >>> servers and their connectivity issues.) >> >> The `nntp-connection-timeout' variable has different behavior in that >> NNTP servers are allowed one "retry" if the connection fails. The code >> around that is very confusing to me (which is why my earlier fix was >> buggy). > > I don't follow you, but no need to elaborate further here. > >>>>>> Yeah, I'd put in a dumb fix for this that turned out to be buggy, so we >>>>>> just recently reverted it. I have a more thorough fix in progress >>>>>> somewhere here, that would report a server connection failure without >>>>>> interrupting the rest of the servers, but it's not done yet. I've had >>>>>> very little time for coding recently, but will get to it At Some Point. >>>>>> >>>>>> Glad it's at least better than it was. I wonder if we should have some >>>>>> generous timeout set by default... >>>>> >>>>> It might make sense to continue this discussion in bug#52735. >>>> >>>> This doesn't seem like the same issue -- this problem is pretty well >>>> understood. >>> >>> Hm, I had understood from both Prashant Tak and Eric Fraga that the >>> problem they have is essentially the same as I do and what I reported in >>> that bug. But that problem doesn't seem to be understood. If by the >>> understood problem you mean the effect of nntp-connection-timeout, >>> doesn't that just mean using it isn't a real fix for the hang the three >>> of us (at least) are experiencing? That's why I thought other >>> approaches need to be considered and bug#52735 seems like the >>> appropriate venue for that. But I'm fine with continuing the discussion >>> here instead. >> >> Oh I see what you mean. In your bug report I'd gotten the idea that >> something was going wrong with accepting process output, and had a >> missed-the-forest-for-the-trees moment around it simply being a dead >> process. >> >> Using `nntp-connection-timeout' is the proper fix for this problem, it's >> just got a bit of unfortunate behavior that needs to be remedied. I'd be >> inclined to start a whole new bug report for a fix for that, because >> it's really a new issue, with its own larger-reaching design decisions. >> I suppose we could merge #52735 with that, though. > > Feel free to open a new bug for fixing nntp-connection-timeout. I don't > know if I can help, other than trying out suggestions and providing > feedback. In the meantime I'll keep using my workaround replacement > function. > > But I wonder, could this issue have been triggered by some change in > news.gmane.io around early to mid December 2021? Because that's when > the problem start for me, and prior to that I don't recall ever having > this problem (perhaps sporadically but not with such persistance). The nntp-connection-timeout variable has been present and nil since 1999. I put my original buggy fix in at the end of October 2021, so that seems suspicious, but that should only have had an effect if you had set nntp-connection-timeout to something other than the default of nil. In general it's pretty hard to say, though...
Re: Getting Keywords: from parent article in message-setup-hook when following up
Adam Sjøgren writes: > Eric writes: > >> When you think about it, updating a global variable is all the Gnus code >> is doing! But better to rely on someone else's ugly hack, I suppose... > > Haha, yes, and if you take a couple of more steps back, all computing > is manipulation of global memory ;-) > > But I think not having one hook storing the information and another > one using it will be a little less ugly, so thanks for the hint - the > naming of these variables is often not obvious to me. Ugh, don't get me started. What's the difference between gnus-current-article and gnus-article-current? No one will ever know.
Re: Gnus fetch freezes emacs
Stephen Berman writes: > On Tue, 04 Jul 2023 10:02:34 -0700 Eric Abrahamsen > wrote: > >> Stephen Berman writes: [...] > This: > > (defun srb-gnus-group-get-new-news (&optional arg one-level) >(interactive "P") >(with-timeout (1 (kill-buffer (nntp-find-connection-buffer > nntp-server-buffer)) > (gnus-group-get-new-news)) > (gnus-group-get-new-news arg one-level))) > > (define-key gnus-group-mode-map "g" 'srb-gnus-group-get-new-news) > >> Eric F is just describing the >> unfortunate behavior of nntp-connection-timeout, which interrupts the >> entire fetching process when it hits the timeout. > > Is that different than what the above function does with the kill-buffer > sexp? (Not a rhetorical question, I know next to nothing about news > servers and their connectivity issues.) The `nntp-connection-timeout' variable has different behavior in that NNTP servers are allowed one "retry" if the connection fails. The code around that is very confusing to me (which is why my earlier fix was buggy). >>>> Yeah, I'd put in a dumb fix for this that turned out to be buggy, so we >>>> just recently reverted it. I have a more thorough fix in progress >>>> somewhere here, that would report a server connection failure without >>>> interrupting the rest of the servers, but it's not done yet. I've had >>>> very little time for coding recently, but will get to it At Some Point. >>>> >>>> Glad it's at least better than it was. I wonder if we should have some >>>> generous timeout set by default... >>> >>> It might make sense to continue this discussion in bug#52735. >> >> This doesn't seem like the same issue -- this problem is pretty well >> understood. > > Hm, I had understood from both Prashant Tak and Eric Fraga that the > problem they have is essentially the same as I do and what I reported in > that bug. But that problem doesn't seem to be understood. If by the > understood problem you mean the effect of nntp-connection-timeout, > doesn't that just mean using it isn't a real fix for the hang the three > of us (at least) are experiencing? That's why I thought other > approaches need to be considered and bug#52735 seems like the > appropriate venue for that. But I'm fine with continuing the discussion > here instead. Oh I see what you mean. In your bug report I'd gotten the idea that something was going wrong with accepting process output, and had a missed-the-forest-for-the-trees moment around it simply being a dead process. Using `nntp-connection-timeout' is the proper fix for this problem, it's just got a bit of unfortunate behavior that needs to be remedied. I'd be inclined to start a whole new bug report for a fix for that, because it's really a new issue, with its own larger-reaching design decisions. I suppose we could merge #52735 with that, though. Eric
Re: Gnus fetch freezes emacs
Stephen Berman writes: > On Mon, 03 Jul 2023 09:36:26 -0700 Eric Abrahamsen > wrote: > >> Eric S Fraga writes: >> >>> On Sunday, 2 Jul 2023 at 16:59, Eric Abrahamsen wrote: >>>> If everyone's hitting this with NNTP servers, you can set >>>> `nntp-connection-timeout' to a number of seconds. It is nil by default, >>>> which I guess would result in permanent hangs. > > Is this variable supposed to be set in the value of gnus-select-method? > For example, like this: > > (setq gnus-select-method '(nntp "news.gmane.io" > (nntp-connection-timeout 3))) It's a defvoo, so it can either be set globally, or as a server parameter. >>> So this works, in the sense that it stops me waiting forever... However, >>> it seems (early days yet) that when it fails to open the connection to >>> an NNTP server, it stops retrieving news and I have to hit 'g' again to >>> get the counts etc. updated for other servers. [...] > > That sounds basically like what the function I'm using in place of > gnus-group-get-new-news (see my first post in this thread) does. Could > such a function take effect if added to one of the server hook variables > nntp-server-opened-hook, nntp-server-action-alist or > nntp-open-connection-function? From the descriptions in the manual it > isn't clear to me. Or is there some better Gnus hook variable for this > purpose? If not could one be added? I'm not sure what function you mean. Eric F is just describing the unfortunate behavior of nntp-connection-timeout, which interrupts the entire fetching process when it hits the timeout. >> Yeah, I'd put in a dumb fix for this that turned out to be buggy, so we >> just recently reverted it. I have a more thorough fix in progress >> somewhere here, that would report a server connection failure without >> interrupting the rest of the servers, but it's not done yet. I've had >> very little time for coding recently, but will get to it At Some Point. >> >> Glad it's at least better than it was. I wonder if we should have some >> generous timeout set by default... > > It might make sense to continue this discussion in bug#52735. This doesn't seem like the same issue -- this problem is pretty well understood. Eric
Re: Getting Keywords: from parent article in message-setup-hook when following up
Adam Sjøgren writes: > Eric writes: > >> I think the "big" solution is to visit `message-reply-buffer', if that's >> a live buffer, and parse its contents. > > That sounds better than the ugly hack I have now, where I update a > global variable from gnus-article-prepare-hook and use it in > message-setup-hook - eeek. When you think about it, updating a global variable is all the Gnus code is doing! But better to rely on someone else's ugly hack, I suppose...
Re: Getting Keywords: from parent article in message-setup-hook when following up
Adam Sjøgren writes: > How do I get hold of the parent articles' Keywords: in > message-setup-hook when I do a follow up? > > I can get eg From: by lookin in message-reply-headers - but Keywords: > are not in there. > > Is there a trick I can use? I think the "big" solution is to visit `message-reply-buffer', if that's a live buffer, and parse its contents.
Re: Gnus fetch freezes emacs
Eric S Fraga writes: > On Sunday, 2 Jul 2023 at 16:59, Eric Abrahamsen wrote: >> If everyone's hitting this with NNTP servers, you can set >> `nntp-connection-timeout' to a number of seconds. It is nil by default, >> which I guess would result in permanent hangs. > > So this works, in the sense that it stops me waiting forever... However, > it seems (early days yet) that when it fails to open the connection to > an NNTP server, it stops retrieving news and I have to hit 'g' again to > get the counts etc. updated for other servers. But much better than > waiting forever. Yeah, I'd put in a dumb fix for this that turned out to be buggy, so we just recently reverted it. I have a more thorough fix in progress somewhere here, that would report a server connection failure without interrupting the rest of the servers, but it's not done yet. I've had very little time for coding recently, but will get to it At Some Point. Glad it's at least better than it was. I wonder if we should have some generous timeout set by default...
Re: Gnus fetch freezes emacs
On Sunday, 2 Jul 2023 at 16:59, Eric Abrahamsen wrote: > If everyone's hitting this with NNTP servers, you can set > `nntp-connection-timeout' to a number of seconds. It is nil by default, > which I guess would result in permanent hangs. So this works, in the sense that it stops me waiting forever... However, it seems (early days yet) that when it fails to open the connection to an NNTP server, it stops retrieving news and I have to hit 'g' again to get the counts etc. updated for other servers. But much better than waiting forever. Thank you, eric -- Eric S Fraga via gnus (Emacs 30.0.50 2023-06-29) on Debian 12.0
Re: Gnus fetch freezes emacs
On Sunday, 2 Jul 2023 at 16:59, Eric Abrahamsen wrote: > If everyone's hitting this with NNTP servers, you can set > `nntp-connection-timeout' to a number of seconds. It is nil by default, > which I guess would result in permanent hangs. Thank you for the suggestion. I have set this to 15 seconds and we'll see if this makes any difference! I'll report back in due course hopefully. -- Eric S Fraga via gnus (Emacs 30.0.50 2023-06-29) on Debian 12.0
Re: Gnus fetch freezes emacs
Prashant Tak writes: > Stephen Berman writes: > >> On Fri, 30 Jun 2023 20:03:11 +0530 Prashant Tak >> wrote: >> >>> Gnus has been freezing sporadically when `gnus-group-get-new-news` is run. >>> And it keeps on going for hours, I have to manually intercept and signal >>> `keyboard-quit` and then perform the fetch operation again. This happens >>> in a very unpredictable manner, so it's hard to replicate. I did manage >>> to get a profiler report when that happened. >>> >>> 6416 86% - nntp-accept-response >>> 6068 82%- nntp-accept-process-output >>> 5873 79% - nnheader-accept-process-output >>> 19 0% + accept-process-output >>> >>> The main culprit seems to be `nnheader-accept-process-output` but I >>> don't know how to proceed further. Appreciate any help/input into the >>> matter. >> >> This sounds like the issue I've been having with gnus-group-get-new-news >> and similar Gnus commands for more than a year and a half, see >> bug#52735. As reported there, I did some debugging but couldn't >> pinpoint the problem, nor have I tried profiling yet. But as a >> workaround, I've been using the following replacement for >> gnus-group-get-new-news: >> >> (defun srb-gnus-group-get-new-news (&optional arg one-level) >> (interactive "P") >> (with-timeout (1 (kill-buffer (nntp-find-connection-buffer >> nntp-server-buffer)) >> (gnus-group-get-new-news)) >> (gnus-group-get-new-news arg one-level))) >> >> (define-key gnus-group-mode-map "g" 'srb-gnus-group-get-new-news) >> >> This usually suffices but not always. When Gnus (and hence Emacs) hangs >> even when using this workaround, I've resorted to manually killing the >> server buffer " *server news.gmane.io nntp *nntpd**" and then typing `g' >> pretty reliably works again. >> >> This is a very annoying issue, and if what you're experiencing is the >> same, I commiserate with you, but your report also gives me hope that >> it's not just some quirk of my setup or network connection. Now we just >> need some Gnus expert to chime in and guide us to try and track down the >> cause of this issue and get it fixed. > > I took a look at your bug report and indeed, the behaviour described is > identical to what I've been experiencing, hopefully someone does chime > in with an idea on how to improve the situation. Thanks for sharing your > solution for the meantime though. If everyone's hitting this with NNTP servers, you can set `nntp-connection-timeout' to a number of seconds. It is nil by default, which I guess would result in permanent hangs.
Re: Gnus fetch freezes emacs
On Friday, 30 Jun 2023 at 21:33, Stephen Berman wrote: > This is a very annoying issue, and if what you're experiencing is the > same, I commiserate with you, but your report also gives me hope that > it's not just some quirk of my setup or network connection. If it's further consolation, I seem to have the same problem with hangs on a non-reproducible basis. I've not had the time to dig into it but it definitely sounds similar to what you and the OP are seeing. -- Eric S Fraga via gnus (Emacs 30.0.50 2023-06-29) on Debian 12.0
Re: Marking thread as read
On Friday, 30 Jun 2023 at 04:28, Michael Heerdegen wrote: > After reading the Gnus manual a bit I take "killed" as a subset of > "read". k for example behaves, and is documented, similarly. > > Internally `gnus-summary-mark-article-as-read' is used, just marking is > done with `gnus-killed-mark' - probably to indicate that you have not > handled the articles by hand. This makes sense but has some side effects, IIUC. In particular, adaptive scoring may be affected? But I see that Adam has posted some code so all is good. :-) Thank you, eric -- Eric S Fraga via gnus (Emacs 30.0.50 2023-06-19) on Debian 12.0
Re: Marking thread as read
On Thursday, 29 Jun 2023 at 04:02, Alshehhi Family wrote: > It seems that like it is the right command because it says "as > read". But when I run it, gnus mark the thread as kill. Am I missing > something? Not sure what you tried exactly. What happens if you try "C-u T k", i.e. passing a positive argument to the command? -- Eric S Fraga via gnus (Emacs 30.0.50 2023-06-29) on Debian 12.0
Re: Marking thread as read
I've had a chance to try this and you are correct: the documentation does not match the behaviour. "T k" with no argument marks all articles as killed which is not the same as read. The other mentioned options (positive, 0, and negative arguments) do behave as documented. -- Eric S Fraga via gnus (Emacs 30.0.50 2023-06-29) on Debian 12.0
Re: Face: not showing?
On Tuesday, 4 Apr 2023 at 16:16, Adam Sjøgren wrote: > Yes, when it's a little more functional - it's doesn't do much yet, but > it's kind of fun trying to make it work. Excellent and glad you're having fun playing with it. I would love a gnus interface to ActivityPub, mastodon in particular at the moment, giving me adaptive scoring and threading although I imagine the latter may be challenging if not impossible. -- Eric S Fraga via gnus (Emacs 30.0.50 2023-04-01) on Debian 11.6
Re: Face: not showing?
On Tuesday, 4 Apr 2023 at 15:43, Adam Sjøgren wrote: > because I am implementing an ActivityPub server with an nntp-interface > and wanted to see user icons) :-) Oh, that sounds interesting! Are you intending on making it public? -- Eric S Fraga via gnus (Emacs 30.0.50 2023-04-01) on Debian 11.6
Re: Face: not showing?
On Tuesday, 4 Apr 2023 at 12:45, Richmond wrote: > Ah, it's a face! I am not sure who though, David Grohl perhaps? You'll have to ask Adam that... -- Eric S Fraga via gnus (Emacs 30.0.50 2023-04-01) on Debian 11.6
Re: Face: not showing?
On Tuesday, 4 Apr 2023 at 14:03, Adam Sjøgren wrote: > Maybe it works for you because you are using a monospaced face? Interesting. Maybe. It could be that the image is considered to be 0 width...? It's not as if many people use the face capability so I guess it's not tested very thoroughly? My own emails show a face but I think that comes from gravatar (setq gnus-treat-from-gravatar 'head) as I have not defined the face header details. Out of curiosity, does my (colourful and young ;-)) face appear if you set that? -- Eric S Fraga via gnus (Emacs 30.0.50 2023-04-01) on Debian 11.6
Re: Face: not showing?
On Tuesday, 4 Apr 2023 at 12:12, Richmond wrote: > Eric S Fraga writes: > >> A data point: your face appears for me when reading your posts. I'm on >> Emacs from git updated three days ago now. > > I can see an x-face header in the original post, but no other evidence > of a face. What is it supposed to look like? Assuming I can send attachments, attached is a screenshot of what I see. -- Eric S Fraga via gnus (Emacs 30.0.50 2023-04-01) on Debian 11.6
Re: Face: not showing?
On Tuesday, 4 Apr 2023 at 12:49, Adam Sjøgren wrote: > Thanks! What is the value of gnus-treat-fold-headers in your setup? head -- Eric S Fraga via gnus (Emacs 30.0.50 2023-04-01) on Debian 11.6
Re: Face: not showing?
A data point: your face appears for me when reading your posts. I'm on Emacs from git updated three days ago now. -- Eric S Fraga via gnus (Emacs 30.0.50 2023-04-01) on Debian 11.6
Re: How to open gnus agent category buffer
J c (aka gnus-enter-category-buffer) -- Eric S Fraga via gnus (Emacs 30.0.50 2023-03-21) on Debian 11.6
Re: Is gnus-demon-scan-news supposed to scan nnselect search groups?
Julien Cubizolles writes: > I noticed that the permanent search groups I've created don't get > rescanned by (gnus-demon-scan-news), I need to run > (gnus-summary-rescan-group) in its summary to get the new search > results. Is there a way to trigger a rescan of all nnselect groups when > the contents of the groups searched has changed ? The Select Groups section of the manual has information on this: Refreshing the selection of an nnselect group by running the ‘nnselect-function’ may take a long time to complete. Consequently nnselect groups are not refreshed by default when ‘gnus-group-get-new-news’ is invoked. In those cases where running the function is not too time-consuming, a non-‘nil’ group parameter of ‘nnselect-rescan’ will allow automatic refreshing. A refresh can always be invoked manually through ‘gnus-group-get-new-news-this-group’.
Re: wrong gnus-search in nnml folder
Fernando de Morais writes:
> Hello Angel and Eric,
>
> Angel de Vicente writes:
>
>> What I don't get to work is compound queries like since:3d from:alex
>> (they work separetely, but nothing gets returned if I try to combine
>> two queries...
>
> I use mairix as my search engine on nnmaildir servers and this behavior
> has always annoyed me, although I wasn't able to figure out why it
> cannot perform this kind of search, until Eric pointed out the
> possibility of debugging `gnus-search-run-search'.
Please report all annoyance as a bug! :)
> The mairix command interprets each query as an individual argument.
> When we pass a query like:
>
> #+begin_example
> Query: from:alex since:3d
> #+end_example
>
> In `gnus-search-run-search' it will become a sole string
> ("f:alex d:20230129-"), and mairix will return nothing.
>
> Just for a simple experiment, I reevaluated the `gnus-search-run-search'
> with the following lines changed:
>
> --- #
> +++ #
> @@ -1332,7 +1332,8 @@
> (message "Doing %s query on %s..." program groups)
> (message "Doing %s query..." program))
>(setq proc (apply #'start-process (format "search-%s" server)
> - buffer program cp-list))
> + buffer program (flatten-list (mapcar #'split-string
> + cp-list
>(while (process-live-p proc)
> (accept-process-output proc))
>(setq exitstatus (process-exit-status proc))
>
> And the result of a search like the give example above was the same
> given by mairix via terminal.
>
>
> P.S.: To clarify, I'm using Emacs 28.2.
That's very interesting! And odd, since none of the other
command-line-type search engines seem to care that the whole query is
passed in as a single string. I wonder if that behavior is an accident,
though, and the mairix behavior is actually the one we should be
expecting. Instead of the patch above, would you confirm that eval'ing
the following produces the right behavior?
(cl-defmethod gnus-search-indexed-search-command ((engine gnus-search-mairix)
(qstring string)
query &optional _groups)
(with-slots (switches config-file) engine
(append `("--rcfile" ,config-file "-r")
switches
(when (alist-get 'thread query) (list "-t"))
(split-string qstring
Though I'll continue investigating this, and might end up implementing
this for all engines.
Thanks for the bug-hunting,
Eric
Re: wrong gnus-search in nnml folder
Angel de Vicente writes: > Hello, > > Angel de Vicente writes: >> oh, indeed it was nil. Changed it and queries like "since:3d" work now >> beautifully. What I don't get to work is compound queries like since:3d >> from:alex (they work separetely, but nothing gets returned if I try to >> combine two queries... > > just tried again today. I thought I would have to fire edebug again, but > I tried quoting the whole query and it works fine. > > So, to clarify: > > + for simple queries I just type: > > Query: since:3d > > + for compound queries I need to quote it like: > > Query: "from:alex since:3d" > > I take it from section 9.3 of the Gnus manual that this is not intended. No, that's not how it's supposed to work! So here's our query: (gnus-search-transform (make-instance 'gnus-search-mairix) (gnus-search-parse-query "from:alex since:3d")) -> "f:alex d:20230128-" And you've confirmed that running "mairix f:alex d:20230128-" works correctly on the command line? There's not much other processing going on. Mairix is weird about how it ANDs and ORs search terms -- you can only OR on the same key -- but that shouldn't be coming into play here. For the record, you don't really need to be using gnus-search. If you're happy with mairix's search language, and you don't expect to ever run searches against both nnml and nnimap backends at the same time, it probably won't get you much. Eric
Re: wrong gnus-search in nnml folder
Angel de Vicente writes: > Hello, > > Angel de Vicente writes: >> I will try, though I'm really rusty with Emacs debugging, I will have to >> refresh my memory.. > > ok, it was really easy to remember how to use Edebug. What I found is > that apparently I cannot use "since:3d", "from:angel", etc. and instead I > just have to use the mairix search patterns > > so, "d:3d-" or "f:angel" work fine. > > I guess the translation from the common format to the mairix specific > one is missing somewhere? That just sounds like you're not using gnus-search at all. What's your value of `gnus-search-use-parsed-queries'? It is nil by default, and my guess is you've still got it at nil. If it is t, how about `gnus-search-mairix-raw-queries-p'? Or have you added config to the mairix search engine to only use raw queries?
Re: wrong gnus-search in nnml folder
Angel de Vicente writes: >>> You haven't said what search engine you're using, but if it's notmuch: >> >> it is ages since I configured this, but I'm not using notmuch, it is >> just whatever stock method comes with Gnus, *I think* > > should be mairix. > > my gnus-search-default-engines variable' value is: > > , > | ((nnimap . gnus-search-imap) > | (nnml . gnus-search-mairix)) > ` So that's: (gnus-search-transform (make-instance 'gnus-search-mairix) (gnus-search-parse-query "since:3d")) -> "d:20230127-" As I read the spec, that's the correct format (actually, mairix could also handle the "3d" directly, but there's currently no option to pass the unparsed search string through). Can you check on the command line, outside of Gnus, and confirm that you see the correct messages returned? You can also edebug `gnus-search-run-search' for the `gnus-search-indexed' engine (gnus-search.el:1394 in master), and see if anything funky is happening in there.
Re: wrong gnus-search in nnml folder
Angel de Vicente writes: > Hello, > > piggypbacking from the thread started by Julien Cubizolles... > > I have all my mail in nnml folders, but searching seems really broken > here. In a folder where I keep all my 2022 mails, if I do > > G G since:3d > > I get mails for the following dates: > > , > | O (20-Jan-2022) ( 11k) > | O (02-Feb-2022) (1.1k) > | O (10-Mar-2022) ( 10k) > | OA (10-Mar-2022) ( 11k) > | O (10-Mar-2022) (0.6k) > | O (10-Mar-2022) ( 18k) > | O (11-Mar-2022) ( 17k) > | OA (12-Mar-2022) ( 18k) > | O (12-Mar-2022) (0.6k) > | O (12-Mar-2022) (1.7k) > | O (17-Mar-2022) (2.5k) > | O (17-Mar-2022) (3.0k) > | O (17-Mar-2022) (5.6k) > | O (24-Mar-2022) (9.6k) > | O (12-May-2022) ( 36k) > | O (04-Jun-2022) ( 11k) > | OA (29-Aug-2022) (5.1k) > | O (30-Aug-2022) (1.1k) > | O (30-Aug-2022) (3.0k) > ` > > G G since:5d > > or > > G G since:1d > > return nothing. > > Any idea what could be going on in here? Okay, same test for you! What does this return? (gnus-search-query-parse-date "3d") (gnus-search-parse-query "since:3d") You haven't said what search engine you're using, but if it's notmuch: (gnus-search-transform (make-instance 'gnus-search-notmuch) (gnus-search-parse-query "since:3d")) -> "date:1/27/2023.." And can you tell me what locale your machine is in? Does Julien's last patch fix the problem?
Re: gnus-search since: not working for nnimap
Julien Cubizolles writes: > Julien Cubizolles writes: > >> 'gnus-search-transform seems to be at fault here. It uses >> '(format-time-string "%e-%b-%Y") where %b returns the "locale’s >> abbreviated month name" when imap commands expects the english abbreviated >> month name. > > It's working with the attached patch. I'm not sure this is the best way > to go but I'm happy with it. > > diff --git a/lisp/gnus/gnus-search.el b/lisp/gnus/gnus-search.el > index 27c71fa6c6..0d9a62f911 100644 > --- a/lisp/gnus/gnus-search.el > +++ b/lisp/gnus/gnus-search.el > @@ -1330,9 +1330,10 @@ elements are present." > (1- nyear) > nyear)) > (setq dmonth 1 > -(format-time-string > - "%e-%b-%Y" > - (encode-time 0 0 0 dday dmonth dyear > +(with-locale-environment "C" > + (format-time-string > + "%e-%b-%Y" > + (encode-time 0 0 0 dday dmonth dyear) > > (cl-defmethod gnus-search-imap-handle-string ((engine gnus-search-imap) > (str string)) Ooh, that's a great catch, thank you very much. I'll look around and see if there are any other similar issues in this library, and push a fix to master soon. Thanks for the report, Eric
Re: gnus-search since: not working for nnimap
Julien Cubizolles writes: > Eric Abrahamsen writes: > >> You can play with the bits and pieces to see where things might be going >> wrong: >> >> (gnus-search-query-parse-date "1y") -> (28 1 2022) >> (gnus-search-parse-query "since:1y") - > ((since 28 1 2022)) >> >> So far so good. >> >> (gnus-search-transform >> (make-instance 'gnus-search-imap) >> (gnus-search-parse-query "since:1y")) -> "SINCE 28-Jan-2022" >> >> Still looking correct (right?). > > Everything is fine up until this point. > >> Try doing "C-u G G" on an nnimap group to shut off gnus-search parsing, >> and enter "SINCE 28-Jan-2022" as the search string. Does that return >> anything? > > Sill nothing: > > Group nnselect:nnselect-87cz6x1zv6.fsf contains no messages We'll have to get closer to the IMAP server, then. If you don't have TLS enabled on your local dovecot you can probably log in and test with: telnet localhost 143 Then: a login b select "INBOX" c UID SEARCH SINCE 28-Jan-2022 To confirm that messages are found. Then it's a matter of seeing that same conversation between Gnus and Dovecot, to find where things are going wrong. You can set `nnimap-record-commands' to t, then conduct a search, and also find which of your " *nnimap localhost nil *nntpd**-373470" buffers corresponds to this server. That should allow you to reconstruct the conversation. Another option would be to edebug the `gnus-search-imap-search-command' function, and see what we're getting back from Dovecot. Hopefully something in there will be revealing.
Re: gnus-search since: not working for nnimap
Julien Cubizolles writes: > I've gnus-search configured to use gnus-search-imap for a nnimap > method. G G (gnus-group-read-ephemeral-search-group) doesn't return any > result when using a query like "since:1y" on a nnimap group whereas: > > + the same query works in a nnml group > + a query like "from:user" returns many results in this time range on > the same nnimap group. > > Isn't "since:1y" a valid query for nnimap ? It should be! > The nnimap group is managed by a local dovecot server. Does it > matter ? No, I don't think so. I tried it on one of my own nnimap servers, backed by local dovecot, and it returned several thousand messages. You can play with the bits and pieces to see where things might be going wrong: (gnus-search-query-parse-date "1y") -> (28 1 2022) (gnus-search-parse-query "since:1y") - > ((since 28 1 2022)) So far so good. (gnus-search-transform (make-instance 'gnus-search-imap) (gnus-search-parse-query "since:1y")) -> "SINCE 28-Jan-2022" Still looking correct (right?). Try doing "C-u G G" on an nnimap group to shut off gnus-search parsing, and enter "SINCE 28-Jan-2022" as the search string. Does that return anything? Eric
Re: Removing the first nntp server from the list
Emanuel Berg writes: > Richmond wrote: > >> Thanks it worked. I thought you had a repeating n key, but >> it's really a thing, nnnil. >> >> https://github.com/emacs-mirror/emacs/blob/master/lisp/gnus/nnnil.el > > What's nn anyway, network news? The naming is built on the original protocol, nntp: Network News Transfer Protocol. As Gnus grew the ability to speak more protocols, they all got the same nn* prefix. I actually find it sort of handy for distinguishing discussions about IMAP or maildir from the Gnus backends, but I agree there shouldn't be any need for nnnil.
Re: Keeping IMAP connection alive when using it in mail-sources
Adam Sjøgren writes:
> Hi,
>
>
> I was wondering if there is a way to use IMAP in mail-sources ("as
> POP"), but without closing the connection after every
> gnus-group-get-new-news?
Not with the code as it's written! There's a very definite
(imap-close buf) at the end of the mail source fetching, then the buffer
is deleted. I guess it wouldn't be a bad idea to add a keepalive option
to imap.el, but someone would have to do that!
Re: gnus-article-summary-next
On Friday, 16 Dec 2022 at 09:58, Juan José García-Ripoll wrote: > They are not consistent with each other, right? Yes, not consistent and, more to the point, they are not the defaults. You (or something in your configuration) is changing these. Generally, n/p go to next/prev unread and N/P next/prev whether read or not. -- Eric S Fraga via gnus (Emacs 30.0.50 2022-12-02) on Debian 11.5
Re: gnus-article-summary-next
On Thursday, 15 Dec 2022 at 10:45, Juan José García-Ripoll wrote: > Hi, > > a brief question. Has anything changed in Emacs 28? I am used to Shift-p > and Shift-n to navigate the emails but now those keys act in reversed > order: previous means later date and next means earlier date, moving > downwards and upwards in a sorted summary buffer. This seems to be > contrary to what I did not too long ago. What are the keys actually bound to? For me, in a summary buffer, I have N: gnus-summary-next-article P: gnus-summary-prev-article Whether that is next/prev date obviously depends on the sorting in your buffer but for me they move point down (N) or up (P), as I would expect. -- Eric S Fraga via gnus (Emacs 30.0.50 2022-12-05) on Debian bullseye/sid
Re: delete downloaded marked emails after specific days & pop3 advice
"jindam, vani" writes:
> after much trials, i found its impossible to run
> dovecot on debian 11 on userland (1). i have a
> copy of gnus manual (by lars magne, 1995-2015,
> no version). recently disvovered check paren
> for looking errors on .gnus
>
> i have few questions:
>
> (a) is it possible to download all emails on my
> local machine, i dont want to retain email copies
> on server
mbsync doesn't offer this: the only available setting is the Sync
directive in the config file, and that doesn't allow deleting messages
remotely but not locally. This sounds more like using pop3 as a
mail-source, with the :leave setting at `nil'.
> (b) do i have to specify all email directories
> on .gnus for downloading, ex: spam, draft
With "Patterns *" in your mbsync config, mbsync will sync all folders.
Gnus will make all those folders available through the nnmaildir
backend, though you can also subscribe/unsubscribe to them within Gnus, so you
can choose what you see.
> (c) how do i auto expunge all marked emails on
> .gnus or mbsync.rc after specific period
See the "Expiring Mail" section of the Gnus manual. With the settings
you've shown below, when Gnus eventually deletes a message that deletion
will get synced to the server, as well.
> (d) seriously, reconsidering to use getmail
> to fetch all emails through pop3, is it good
> idea. pop3 supports or recognises only one
> directory —inbox & does it mean it will include
> spam emails in inbox?
If you don't care about the state of the server, and would prefer to not
leave messages there, then yes I think using a pop3 mail-source might be
a better option than mbsync. You can still use nnmaildir locally, with
split rules that send incoming mail there.
I don't use this and I don't know if pop will pull messages from
multiple folders; the docs don't mention any relevant config.
Note that you've got this in your nnmaildir config:
(get-new-mail t)
That *only* comes into play if you're using mail sources. That means
that given the config below you don't need it: mbsync will add messages
to nnmaildir, which nnmaildir will detect automatically.
> * mbsync.rc:
> IMAPAccount disroot
> Host disroot.org
> User jindam.v...@disroot.org
> SSLType IMAPS
> SSLVersions TLSv1.2
>
> # you may have to tweak the awk here + filename to your netrc/authinfo:
> # PassCmd "gpg2 -q --for-your-eyes-only --no-tty -d $HOME/.netrc.gpg |
> awk '$2==\"mail.messagingengine.com\" && $4==\"m...@fastmail.com\"
> {print $6;exit(0)}'"
> # Port 992
> # Port 992 has a "flat" hierarchy; use with
> # mail_location = maildir:~/.Maildir/:LAYOUT=fs:INBOX=~/.Maildir/INBOX
> # in dovecot (see also MaildirStore.Inbox below)
>
> IMAPStore disroot-remote
> Account disroot
>
> MaildirStore disroot-local
> # The trailing "/" is meaningful
> Path ~/.Maildir/
> Inbox ~/.Maildir/INBOX
> SubFolders Legacy
>
> Channel disroot
> Master :disroot-remote:
> Slave :disroot-local:
> Patterns *
> Create Slave
> Sync All
> Expunge Both
> SyncState *
>
> * .gnus:
> (setq gnus-select-method '(nnnil ""))
>
> (add-to-list 'gnus-secondary-select-methods
> '(nnmaildir ""
> (directory "/home/jin/.Maildir/")
> (get-new-mail t)
> (directory-files nnheader-directory-files-safe)))
>
> (setq mail-user-agent 'gnus-user-agent)
> (setq read-mail-command 'gnus)
>
>
> (1) https://github.com/CypherpunkArmory/UserLAnd
>
> regards,
> jindam, vani
Re: Help needed: nnmaildir and expire-group parameter.
Fernando de Morais writes: > Hello Eric, > > Eric Abrahamsen writes: > >> Look for the value of "pgname", and the 'expire-age parameter, and >> later the 'expire-group parameter. Something in there should jump out >> at you as "wrong". > > This was a very wise advice: in the end, `nnmaildir' was looking for the > parameters of the group "inbox", not "nnmaildir:inbox". That did the > trick! 🎉 [...] > Thank you very much! Glad it wasn't any harder to resolve! > *P.S.:* I imagine there must be a rationale behind this and it was > defined a long time ago, but why doesn't `nnmaildir' make use of the > `expiry-target' parameter like other backends do? Apparently it's not using the same parameter names as everyone else, because nnmaildir lets the user put arbitrary Lisp expressions in as values -- it runs the values through `eval' at Gnus startup time. I think the idea is that, because the parameter values are handled differently, the parameter names should be different. This doesn't particularly make sense, and the use of `eval' in regular code is pretty heavily discouraged these days. This code seems to have been in nnmaildir.el since The Dawn of Time, and I'm sure that at one point someone depended heavily on being able to `eval' their parameter values. It would be relatively simple to fix: we could leave the existing handling of nnmaildir's own parameters in place, but also start retrieving the normal expiry parameters, using Gnus' regular `gnus-group-parameter-*' functions. Eric
Re: Help needed: nnmaildir and expire-group parameter.
Fernando de Morais writes:
> Hello everyone,
>
> According to the manual[1][2], `nnmaildir' uses its own group parameters
> to handle expiration.
>
> Excepting `nnmail-expiry-wait(-function)' variables, to handle
> expiration per group, the user needs to set values for `expire-age' and
> `expire-group' parameters. Ok, so considering the snippet below:
>
> #+begin_src emacs-lisp
> (customize-set-variable 'gnus-parameters
> '("nnmaildir:inbox"
> (expire-age . 0) ; <-- Here
> (expire-group . "nnmaildir:trash"))) ; <-- Here
> (customize-set-variable 'gnus-secondary-select-methods
> '((nntp "news.gwene.org")
> (nnmaildir ""
>(directory "~/Mail/")
>(target-prefix "")
>(get-new-mail t
> (customize-set-variable 'gnus-select-method '(nnnil ""))
> (customize-set-variable 'gnus-total-expirable-newsgroups
> (regexp-opt '("nnmaildir:trash")))
> #+end_src
A quick check you can do is to evaluate (after Gnus has loaded):
(nnmaildir--param "nnmaildir:inbox" 'expire-age)
And see what that gives you. I'm not entirely sure that
"nnmaildir:inbox" is correct, and I wonder if the problem you're seeing
comes from the fact that your nnmaildir server has a blank string for a
name.
The real check would be to edebug `nnmaildir-request-expire-articles'
and see what it's doing. You may already be familiar with edebug; if not
then put point inside that function and hit "C-u C-M-x". The next time
expiry runs the process will halt and display this function, and you can
step through it with . As point passes over various sexps, their
return value will be shown in the minibuffer. Look for the value of
"pgname", and the 'expire-age parameter, and later the 'expire-group
parameter. Something in there should jump out at you as "wrong".
(Apologies if you already know edebug.)
Eric
Re: Help needed: nnmaildir and create-directory parameter.
Andrew Cohen writes: >>>>>> "EA" == Eric Abrahamsen writes: > > EA> Fernando de Morais writes: > >> Hello Eric, > >> > >> I've managed to figure out. The TL;DR is: simply, don't use the > >> `create-directory' server parameter. Using only `target-prefix' > >> is what is needed. 😅 > >> > >> Eric Abrahamsen writes: > >> > > [...] > > > EA> I just don't understand how any of this is supposed to work -- I > EA> don't even know why you'd use symlinks in your maildirs to begin > EA> with. This part of the manual was written by Andy Cohen and I'm > EA> cc'ing him here, though he doesn't have a lot of time for Emacs > EA> these days and we might not get him. > > False and true:) I didn't have anything to do with this part of the > manual (or the nnmaildir code), and I have very little time for emacs > these days. Thanks for the quick response! magit-blame in gnus.texi found your commit 8a1cdce, but you might have been merging docs from different places. But no matter! So long as the question is resolved. > [...] > > EA> (I suspect the end result of all this will be the removal of > EA> 'create-directory altogether.) > > Looking back through git I see that Paul Jarc (the author of nnmaildir) > replaced 'create-directory with 'target-prefix in 2003. It was supposed > to be a /complete/ replacement, but it appears that 'create-directory > was accidentally left in the code and the manual . Eric's suspicion is > exactly right: don't use 'create-directory, and the variable should be > removed from nnmaildir.el and the manual. Excellent, thanks a lot for this confirmation. I'll yank that stuff out in a bit. Eric
Re: Help needed: nnmaildir and create-directory parameter.
Fernando de Morais writes: > Hello Eric, > > I've managed to figure out. The TL;DR is: simply, don't use the > `create-directory' server parameter. Using only `target-prefix' is what > is needed. 😅 > > Eric Abrahamsen writes: > >> So maybe try taking out the (target-prefix "") server config completely? > > With something like this: > > #+begin_src emacs-lisp > ... > (nnmaildir "" > (directory "~/Dir") > ;; (target-prefix "") > (get-new-mail t) > (create-directory "")) > ... > #+end_src > > Gnus will create groups (and respective folders) specified in > `nnmail-split-method', however it will raise an error, saying that the > directories already exists (?) and we will get a crash box, again. With > my testes, any other value besides `""' will result in error. > > But, uncommenting the `target-prefix' line and removing the > `create-directory' one, we'll end with the expected behaviour, without > errors. I'm guessing this is because, if you use create-directory instead of target-prefix, the empty string additionally gets run through `file-name-as-directory', which converts the "" to "./" and sets that as the value of target-prefix, and lord knows what that ends up doing. I just don't understand how any of this is supposed to work -- I don't even know why you'd use symlinks in your maildirs to begin with. This part of the manual was written by Andy Cohen and I'm cc'ing him here, though he doesn't have a lot of time for Emacs these days and we might not get him. Andy, you wrote this section of the manual 10+ years ago, do you still remember how it's supposed to work? What is the intended relationship between 'remove-prefix and 'create-directory, when the latter simply gets copied to the former if the former is nil? (I suspect the end result of all this will be the removal of 'create-directory altogether.) Thanks, Eric
Re: Help needed: nnmaildir and create-directory parameter.
Fernando de Morais writes:
> Hello everyone,
>
> According to the manual, for a `nnmaildir' server, if my split rules
> create new groups, I need to supply a `create-directory' server
> parameter[1]. Ok, so considering the following example snippet:
>
> #+begin_src emacs-lisp
> (customize-set-variable 'gnus-select-method '(nnnil ""))
> (customize-set-variable 'gnus-secondary-select-methods
> '((nntp "news.gwene.org")
> (nnmaildir ""
>(directory "~/Mail/maildirs")
>(target-prefix "")
>(get-new-mail t)
>(create-directory ... ; <-- Here
> (customize-set-variable 'mail-sources '((file :path "~/Mail/emaple_mbox")))
> (customize-set-variable 'nnmail-split-methods '(("inbox" "")))
> #+end_src
>
> Following the example snippet above, what is the expected value for the
> parameter `create-directory'? Unfortunately the manual brings no
> details about it.
I won't claim to understand how this is supposed to work, but in
`nnmaildir-open-server' we've got the following chunk of
lisp-as-imperative-code:
(setq x (assq 'target-prefix defs))
(if x
(progn
(setq x (cadr x)
x (eval x t)) ;FIXME: Why `eval'?
(setf (nnmaildir--srv-target-prefix server) x))
(setq x (assq 'create-directory defs))
(if x
(progn
(setq x (cadr x)
x (eval x t) ;FIXME: Why `eval'?
x (file-name-as-directory x))
(setf (nnmaildir--srv-target-prefix server) x))
(setf (nnmaildir--srv-target-prefix server) "")))
This makes it look to me like, if you've got a 'target-prefix set (even
if it's the empty string), then 'create-directory never comes into play
at all.
So maybe try taking out the (target-prefix "") server config completely?
I really don't know how this is meant to work. If you figure it out we
should update the manual.
Thanks,
Eric
Re: gnus-read-init-file: Error in ~/.gnus: disroot.org
"jindam, vani" writes: > November 22, 2022 at 6:56 PM, "Adam Sjøgren" wrote: > > >> >> vani writes: >> >> > >> > running M-x gnus has thrown another error: >> > Debugger entered--Lisp error: (void-function nnimap) > > i intentionally did not provided full log: > > Debugger entered--Lisp error: (void-function nnimap) > (nnimap "disroot.org" (nnimap-inbox "INBOX") (nnimap-split-methods > default) (nnimap-expunge t) (nnimap-stream ssl)) > eval-buffer(# nil "/home/jindam/.gnus" nil t) ; > Reading at buffer position 440 You're missing a quote before this definition. However you've got it in your init file, say if you're defining this as a part of `gnus-secondary-select-methods', the value of that variable needs to be quoted: (setq gnus-secondary-select-methods '((nnimap "disroot.org" (nnimpa... Note the quote before the value.
Re: Multi frame setup: get frame autodeletion?
How about making use of message-sent-hook, say? The actual message composition and sending is not technically handled by gnus but by message mode instead, IIUC. -- Eric S Fraga via gnus (Emacs 29.0.50 2022-11-13) on Debian 11.4
Re: How to subsribe to a general mailing list?
On Tuesday, 12 Apr 2022 at 19:53, Durand via "Announcements and discussions for GNUS, the GNU Emacs Usenet newsreader (in English)" wrote: > In particular, I am trying to subscribe to the following mailing list > <https://lists.sr.ht/~protesilaos/modus-themes>. But I don't know how > to do so in Gnus. All you need to do is click on the subscribe link on that page (top left) and it will add your email address to the mailing list, IIUC. The subscription link is simply a "mailto:"; link. -- Eric S Fraga with org 9.5.2 in Emacs 29.0.50 on Debian 11.3
Re: Need help; cannot send email in gnus and emacs anymore; 550 relay not permitted
You don't give any detail so it's hard to know what the problem is. However, one possibility is that you are using gmail and google expects a form of multi-factor authentication. There was a long thread in the emacs help mailing list about this and how to get it working from gnus. -- Eric S Fraga via gnus (Emacs 29.0.50 2022-07-20) on Debian 11.3
customization of digest parsing?
Hello all, I receive emails from a particular forum that has multiple posts in a single email. The format is not compatible with what gnus-summary-enter-digest-group expects. Is there any way to customize how gnus identifies the individual posts in the email? Thank you, -- Eric S Fraga via gnus (Emacs 29.0.50 2022-11-01) on Debian 11.4
Re: How to subsribe to a general mailing list?
The impression I have is that you wish to treat a mailing list as a newsgroup. Is this correct? I just wish to clarify as these are two very different animals. A mailing list consists of a list of email addresses to which all contributions are sent. That's it. There may be an archive for the contents of the list. There is no "server" per se. What is it about the mailing list that you do not like or wish it would do differently? In gnus, you can split any emails that go to a specific list to a different group and therefore treat it like a newsgroup in that all the articles will be in the same place. HTH, eric -- Eric S Fraga with org 9.5.2 in Emacs 29.0.50 on Debian 11.3
Re: Frequent daemon errors
Juan José García-Ripoll writes: > > Hi, > > I am using Gnus currently to access both IMAP and nntp > messages. However, I frequently find error messages such as > "*nntpd**-629172 has no process" or similar for nnimap. > > If I go back to the groups frame and enter "G" to gather all new emails > and messages, things work again, so it does not seem to be critical, but > it is very annoying -- specially because I have my system setup for > debugging any error messages that pop up. > > Any idea how to investigate this further or solve it? If you're running debug-on-error, could you post the backtrace you get in these situations?
Re: Subscribing to nnimap folders that are subscribed on IMAP servers
Ryan Kavanagh via "Announcements and discussions for GNUS, the GNU Emacs Usenet newsreader (in English)" writes: > Hi, > > I am trying to use gnus as an IMAP mail client. I have folders marked as > subscribed on my IMAP server (listed by LSUB). I would like to have gnus > automatically subscribe to these folders, or at least list them so that > I can manually subscribe gnus to them myself. How can I do so? I am > using gnus 5.13 under Emacs 27.1. Best to read the "New Groups" section of the Gnus manual: that will give you the background on `gnus-check-new-newsgroups' (you could also read its docstring), as well as methods of subscribing to new groups. Let us know if that doesn't clear it up! Eric
Re: gnus-summary-followup-with-original not working (nnheader-parse-naked-head)
Angel de Vicente writes: > Hello, > > I've been using this command for ages, but yesterday I did upgrade my > system, and now it has stopped working. I wonder if anybody has seen > this error and/or has some advice on fixing it. > > When using the command gnus-summary-followup-with-original, I now get a > reply buffer without the original mail text, and a message in the > minibuffer that reads: > > , > | save-restriction: Symbol’s function definition is void: > nnheader-parse-naked-head > ` > > My Emacs and Gnus versions are: > > + GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu) of 2022-04-27 > + Gnus v5.13 That's kind of looking like an out-of-date third party package, though it's hard to be sure. You mention upgrading your system, and Emacs was a part of that system upgrade, right? (Meaning, you're not running Emacs from its development repository?) Try running M-x toggle-debug-on-error and triggering that error again -- that should show us what is calling `nnheader-parse-naked-head'.
Re: nnimap gmail "A T" and "^" not working
JibStyle writes: > Eric Abrahamsen writes: > >> Hey there! Thanks for the report. It looks like Gmails' IMAP weirdness >> might be weird enough to break the thread-searching code in Gnus. I >> think it's definitely worth special-casing code for Gmail; give me a few >> days and I'll see what I can figure out. > > Thank you for investigating. Are you able to reproduce the issue? I am > unsure if there is a problem with Gnus <--> Gmail, or if I am doing > something wrong. That is why I ask how other users approach nnimap gmail > threading. > > My `gnus-secondary-select-methods' (primary method is nnnil): > > ((nnimap "imap.gmail.com" > (nnimap-address "imap.gmail.com") > (nnimap-server-port 993) > (nnimap-stream ssl) > (nnimap-split-methods default) > (nnimap-inbox "INBOX") > (nnimap-expunge immediately) > (nnmail-expiry-wait immediate)) > (nntp "news.gmane.io")) > > Please let me know if any additional information is useful, or any > suggested workarounds. Thank you! I technically have a gmail account, but can't access it from Gnus, so I probably won't be able to reproduce. But it's a good idea to adapt some code specifically for Gmail anyway, so I hope to be able to provide some code to test on the list here in the next week or so.
Re: nnimap gmail "A T" and "^" not working
JibStyle writes: > Hi, I am new Gnuser coming from Gmail web interface. I have mostly > configured my nnimap server for gmail and I see it has great power! > > Unfortunately, I am unable to get "A T" and "^" to work in the nnimap > summary buffer. I would like to reconstruct threads, and some articles > may be in another group. Even if they are in same group, "A T" only gets > parents but not siblings or children. I have spent days trying the > various configurations cited in `(gnus) Finding the Parent' info page to > no avail. > > Does anyone have any tips? What is your configuration for nnimap gmail > threading? Hey there! Thanks for the report. It looks like Gmails' IMAP weirdness might be weird enough to break the thread-searching code in Gnus. I think it's definitely worth special-casing code for Gmail; give me a few days and I'll see what I can figure out. Eric
Re: G g and delete mails with Emacs
Michael Heerdegen writes: > Eric Abrahamsen writes: > >> > I use G g to create a search group, open it, process mark the messages I >> > want to archive, and use b to move the messages to my local archive >> > folder. >> > >> > But after that procedure, those messages are still available in my INBOX >> > (and displayed prefixed with "O"). >> >> I'm not the one to make this decision, but this sounds like it might be >> potentially surprising behavior to users, maybe something that should be >> behind a user option similar to `nnselect-allow-ephemeral-expiry'. > > Somebody here who wants to decide? Or say something about the idea? I expect Andy Cohen would be the one to ask about this. I've cc'd him, he might not be looking at this list.
Re: G g and delete mails with Emacs
Michael Heerdegen writes: > Hello, > > since threads are not a super reliable way to find all messages related > to a discussion, I decided to try to delete related messages in my > INBOX (consulted via imap) like the following: > > I use G g to create a search group, open it, process mark the messages I > want to archive, and use b to move the messages to my local archive > folder. > > But after that procedure, those messages are still available in my INBOX > (and displayed prefixed with "O"). > > Is there a way to vary this procedure so that those messages on the imap > server are deleted? I'm not the one to make this decision, but this sounds like it might be potentially surprising behavior to users, maybe something that should be behind a user option similar to `nnselect-allow-ephemeral-expiry'.
Re: Update topic unread counts on group exit?
Adam Sjøgren writes: > Eric writes: > >> I'll remove the checks now. > > The line the error is triggered in is: > > (defun gnus-topic-update-topic-line (topic-name &optional reads) > (let* ((top (gnus-topic-find-topology topic-name)) > (type (cadr top)) > (children (cddr top)) > (entries (gnus-topic-find-groups >(car type) (car gnus-group-list-mode) >(cdr gnus-group-list-mode))) > (all-groups (gnus-topic-find-groups >(car type) (car gnus-group-list-mode) >(cdr gnus-group-list-mode) t)) <-- HERE > (parent (gnus-topic-parent-topic topic-name)) > > gnus-topic-find-groups: Wrong type argument: number-or-marker-p, t > > gnus-group-list-mode is (5) here, so the cdr is nil, and > gnus-topic-find-groups doesn't like that, apparently. I didn't have time > to step through that to pinpoint it further. Looks like Dick Chiang has already opened a bug report containing the fix, so expect this to work Real Soon Now.
Re: Update topic unread counts on group exit?
Adam Sjøgren writes: > Adam writes: > >> Eric writes: >> >>> It looks to me like you could add a function to >>> `gnus-summary-exit-hook', which calls >>> `gnus-topic-update-topics-containing-group' on the value of >>> `gnus-newsgroup-name'. At that stage in summary exit, >>> `gnus-newsgroup-name' won't have been cleared yet, so it should still >>> hold the name of the group you're coming out of. > > [...] > >> I will see if I can get your suggestion going after dinner :-) > > This is what I did: > > (defun asjo-update-topics () > (gnus-topic-update-topics-containing-group gnus-newsgroup-name)) > > (add-hook 'gnus-summary-exit-hook 'asjo-update-topics) > > But simpler than my hack - but nothing is updated. > > When I edebug-defun it, I can see that gnus-newsgroup-name is indeed the > full newsgroup name, e.g. "nntp+gm:gmane.emacs.gnus.user", but the topic > counts aren't updated. And if I'd looked at that function before recommending it, I would have immediately seen that it's buggy! That and `gnus-topic-update-topic' check to see if the major-mode is 'gnus-topic-mode, which of course it never is, because gnus-topic-mode is a minor mode. In fact, gnus-topic.el already thinks it's doing what you want -- updating topic lines on group exit -- but because of the bug in `gnus-topic-update-topic', the update never happens. Lars added that major-mode check as part of a larger commit last year, I have to assume it was a mistake. I'll remove the checks now. Eric
Re: Update topic unread counts on group exit?
Adam Sjøgren writes: > Eric writes: > >>> Is there a way to get Gnus to update the counts automatically on group >>> exit as well? > >> It looks to me like you could add a function to >> `gnus-summary-exit-hook', which calls >> `gnus-topic-update-topics-containing-group' on the value of >> `gnus-newsgroup-name'. At that stage in summary exit, >> `gnus-newsgroup-name' won't have been cleared yet, so it should still >> hold the name of the group you're coming out of. > > Any reason for Gnus not to do that by default? I can't think of any reason off the top of my head. It's not like it's such a costly procedure. gnus-topic is a little fiddly about how it hooks into the rest of the Gnus machinery, but it shouldn't be hard to figure out. > I will see if I can get your suggestion going after dinner :-) It ought to work without the hacky dance, but I'll be curious to hear!
Re: Update topic unread counts on group exit?
Adam Sjøgren writes: > Hi, > > > When I exit a group, the unread count in the topic it is under doesn't > update. > > If I collapse the topic, the count gets updated. That's cool. > > Is there a way to get Gnus to update the counts automatically on group > exit as well? It looks to me like you could add a function to `gnus-summary-exit-hook', which calls `gnus-topic-update-topics-containing-group' on the value of `gnus-newsgroup-name'. At that stage in summary exit, `gnus-newsgroup-name' won't have been cleared yet, so it should still hold the name of the group you're coming out of.
Re: using agent to accumlate post in agentized groups
hput via "Announcements and discussions for GNUS, the GNU Emacs Usenet newsreader (in English)" writes: > I once had some working knowledge of using gnus agent. But it leaked > away over the last 20 and more yrs. As it became faster and faster to > get news. > > I want to acquire several thousand messages from certain groups. > > Ones that likely carry info I most want to access. So back then I used to > download Thousands of old messages overtime so as not to bog down any > servers. > > I lost all my old thousands of messages over many host changes, moves > and fool blunders. Have you considered setting up your own local nntp server, a Leafnode instance or something? Listening to what you're describing, I think that might end up being a more feasible approach, and might give you several other side benefits.
