Re: Inhibiting gnus-get-new-news at startup
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: 2999 73% - command-execute 2641 64% - funcall-interactively 2637 64% - gnus 2637 64%- gnus-1 2626 63% - # 2626 63% - gnus-setup-news 2622 63% - gnus-get-unread-articles 2403 58%- gnus-read-active-for-groups 1855 45% - gnus-read-active-file-2 1855 45% - gnus-retrieve-groups 1855 45% - nnrss-retrieve-groups 1652 40%- nnrss-check-group 1356 33% - nnrss-fetch 1288 31% - xml-parse-region 1288 31% - xml--parse-buffer 1288 31%- xml-parse-tag-1 1288 31% - xml-parse-tag-1 1288 31% - xml-parse-tag-1 1284 31% - xml-parse-tag-1 1221 29%- xml-parse-tag-1 153 3% - xml-parse-string 15 0%# 16 0% + mm-url-insert 259 6% + nnrss-make-hash-index 15 0% + nnrss-find-el 4 0% nnrss-translate-file-chars 3 0% + nnrss-get-namespace-prefix 199 4%+ nnrss-possibly-change-group 544 13% - gnus-request-scan 544 13% - nnmaildir-request-scan 541 13% - nnmaildir--scan 431 10%- nnmaildir--grp-add-art 401 9% - nnmaildir--update-nov 141 3% + nnheader-insert-file-contents 7 0% + nnmaildir--param 21 0%+ mapcar 4 0% + gnus-finish-retrieve-group-infos 162 3%+ gnus-open-server 40 0%+ gnus-request-update-info 14 0%+ gnus-retrieve-group-data-early 3 0% gnus-message 4 0% + gnus-cache-open 7 0% + gnus-splash 4 0% + gnus-read-init-file 4 0% + execute-extended-command 358 8% + byte-code 1107 26% - ... 1107 26%Automatic GC It appears that much of the time was spent on fetching and parsing rss feeds. I am using (setq nnrss-use-local t) which I expected to be much faster, but that gnus is still very slow. Some of you suggested to change the level of subscription to a higher number. What are the implications of this change? I mainly am interested in getting the list of new news of all subscribed groups about once a day.
Inhibiting gnus-get-new-news at startup
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?
Re: Reading the article/message in elisp
Robert Pluim writes:
>
> In a temp buffer, no, but you can access the article buffer using eg
> `gnus-with-article' or `gnus-with-article-buffer', or even
> `gnus-with-article-headers' if you only care about the headers.
I suppose that gnus-with-article-buffer works, almost. In the case that
I am in gnus summary page, with the point on an unopened article, when I
run the following:
(defun husain--test-gnus-with-article-buffer()
(interactive)
(gnus-with-article-buffer
(message "%s" (message-fetch-field "Subject"
It fails to read the subject. However, it works very well after I open
the article. I think this solves 95% of the cases I run into.
Thank you.
Re: Reading the article/message in elisp
Emanuel Berg writes: > You can use `message-fetch-field' to get headers, as in: > > (defun message-yank-subject () > (interactive) > (save-excursion > (let ((subj (message-fetch-field "Subject"))) > (when subj > (message-goto-body) > (insert (format "%s\n" subj)) > > More examples: > https://dataswamp.org/~incal/emacs-init/gnus/message-header.el Thank you. message-fetch-field works if the point is in a message buffer. I was not aware of this option. But when the point is in a gnus-summary buffer, then (message-fetch-field "Subject") returns nil. Even with something like: (defun husain--test-message-subject-yank () (interactive) (save-excursion (let ((subj (message-fetch-field "Subject"))) (if subj (message subj) (gnus-summary-show-article) (gnus-summary-select-article-buffer) (message (message-fetch-field "Subject")) this still doesn't work as intended because it does not restore the window if the point is in a gnus-summary buffer pointing to an article not open. Is there a gnus function that can build the message in a temp buffer?
Reading the article/message in elisp
Hello, If I am in - the summary page, with the cursor on an unopen article line, or in - the summary page, with an open article, or in - an article I would like to be able to read the article content in elisp and execute processes based on that. For example, if the message has TO:per...@work.xyz, or CC:per...@work.xyz, then I would like to open the person's profile page. Is there a gnus elisp function that allows me to access the article programmatically? Thanks.
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.
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
