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
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 &optional LIMIT)
> |
> | Inferred type: (function (&optional t) t)
>
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...@wo
uffer, 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
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 "
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?
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%
moved on to use elfeed.
I have not needed or seen the issues you mentioned.
--
Husain
