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 ( 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: Showing a full thread
hus...@alshehhi.io writes: [A T] > Thank you very much for saving me again. This is exactly what I > needed. Happy to help! Sometimes finding the right function is the hardest part. Best regards, Adam -- "Few things are less comforting than a tiger who's Adam Sjøgren up too late."a...@koldfront.dk
Re: Showing a full thread
Adam Sjøgren writes: > Have you tried A T? > > ,[ C-h f gnus-summary-refer-thread RET ] > | gnus-summary-refer-thread is an interactive native-compiled Lisp > | function in ‘gnus-sum.el’. > | > | (gnus-summary-refer-thread LIMIT) > | > | Inferred type: (function ( t) t) > | > | Fetch all articles in the current thread. > | A non-numeric prefix arg will search the entire server; without a > | prefix arg only the current group is searched. If the variable > | ‘gnus-refer-thread-use-search’ is t the prefix arg has the > | reverse meaning. If searching is not enabled for the current > | group, fetch LIMIT (the numerical prefix) old headers. If LIMIT > | is non-numeric or nil fetch the number specified by the > | ‘gnus-refer-thread-limit’ variable. > | > ` Thank you very much for saving me again. This is exactly what I needed.
Re: Gnus fetch freezes emacs
Stephen Berman writes: > 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. Same here. -- Take Back Control! -- Mesh The Planet! I do not play Nethack, I do play GNUS! o;-) Solid facts do not need 1001 pictures.
Re: Showing a full thread
hus...@alshehhi.io writes: > I would live to view the full tree of the thread: the root and all > the messages that were span off it. Have you tried A T? ,[ C-h f gnus-summary-refer-thread RET ] | gnus-summary-refer-thread is an interactive native-compiled Lisp | function in ‘gnus-sum.el’. | | (gnus-summary-refer-thread LIMIT) | | Inferred type: (function ( t) t) | | Fetch all articles in the current thread. | A non-numeric prefix arg will search the entire server; without a | prefix arg only the current group is searched. If the variable | ‘gnus-refer-thread-use-search’ is t the prefix arg has the | reverse meaning. If searching is not enabled for the current | group, fetch LIMIT (the numerical prefix) old headers. If LIMIT | is non-numeric or nil fetch the number specified by the | ‘gnus-refer-thread-limit’ variable. | ` Best regards, Adam -- "I'll dye without my hair!"Adam Sjøgren a...@koldfront.dk
Showing a full thread
When there is a single unread message, that belongs to a thread, I can view the parent of the message by the default keybinding "^". However, it seems that I am not able to view the full thread, including the sibling messages. I would live to view the full tree of the thread: the root and all the messages that were span off it. Gnus has the command "gnus-summary-show-all-threads" and "gnus-summary-show-thread". These commands do not show the full tree for me, deceivingly. Gnus also has the variable "gnus-show-threads" which is "t" in my case. I am still not able to see the full tree. I am able to see the full tree once I mark the unread message as read, quit, and then visit the group, where I can see all the messages. Any idea if there is a function that show the complete thread? To reproduce my situation, visit any newsgroup/email that has threads. Pick a message which is part of a thread. The message has to have a sibling. Mark it as unread via "gnus-summary-put-mark-as-unread". Quit. Visit the group again and you will b confronted with only that message. -- Husain
