Inhibiting gnus-get-new-news at startup

Inhibiting gnus-get-new-news at startup

[Husain Alshehhi]

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: Inhibiting gnus-get-new-news at startup

[Bartosz Kaczyński]

Husain Alshehhi <husain@alshehhi.io> writes:

> Hello,
>

Hi,

> 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 variable `gnus-check-new-newsgroups` might help you

regards,
bk

Re: Inhibiting gnus-get-new-news at startup

[Lars-Johan Liman]

Hi!

husain@alshehhi.io 2023-12-30 10:41 [-0600]:
> 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 usually start Gnus with M-x gnus-unplugged when I don't want to
contact any servers at startup.

The drawback is that once Gnus is up, it's important to run
gnus-agent-toggle-plugged (keys "J J") from the Groups menu. That will
put Gnus back in normal mode (without downloading new messages). If one
doesn't toggle back, Gnus will remain in off-line mode, which includes
just queueing outgoing mail in nndraft:queue, and they will _NOT_ be
sent automagically when one toggles back to on-line mode. One has to do
that manually (i.e., go to that folder an issue "D S"
(send-all-messages, or some such)), which is very easy to forget, in
which case one's messages will remain unsent until the dusk of eternity.
;-)

				Best regards,
				  /Liman

Re: Inhibiting gnus-get-new-news at startup

[Eric S Fraga]

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

[Lars-Johan Liman]

[My previous message came from the wrong sender address. Apologies.]

e.fraga@ucl.ac.uk 2024-01-04 13:55 [+0000]:
> 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.

Smart! Thanks! (I have that with other important folders, but it didn't
occur to me to put nndraft:queue there.)

> 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.

Thanks again for "J S"!

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.

				Cheers,
				  /Liman

Re: Inhibiting gnus-get-new-news at startup

[Eric S Fraga]

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

[Lars-Johan Liman]

e.fraga@ucl.ac.uk 2024-01-06 15:56 [+0000]:
> My bad!  It's a customization I have in my .gnus.el file:

>   (defun esf/gnus-agent-plugged ()
>     (gnus-group-send-queue))
>   (add-hook 'gnus-agent-plugged-hook 'esf/gnus-agent-plugged)

> You could probably simply add 'gnus-group-send-queue to the hook without
> defining an extra function.

Tada! Many thanks ... again!

				Cheers,
				  /Liman

Re: Inhibiting gnus-get-new-news at startup

[Eric Abrahamsen]

Husain Alshehhi <husain@alshehhi.io> 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: Inhibiting gnus-get-new-news at startup

[Emanuel Berg]

Husain Alshehhi wrote:

> 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.

Do it like you do with Emacs, don't kill it.

(defun gnus-switch-to-group-buffer ()
  (interactive)
  (if (gnus-alive-p)
      (switch-to-buffer gnus-group-buffer)
    (gnus) ))

-- 
underground experts united
https://dataswamp.org/~incal

Re: Inhibiting gnus-get-new-news at startup

[Husain Alshehhi]

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%     - #<compiled 0xffd5eb68ee5dbf1>
        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%                        #<compiled 0xa4190491901ef>
          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.

Re: Inhibiting gnus-get-new-news at startup

[Eric S Fraga]

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

[Eric Abrahamsen]

Eric S Fraga <e.fraga@ucl.ac.uk> 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

[Eric S Fraga]

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