What's your gnus-demon-scan-news idle time?

What's your gnus-demon-scan-news idle time?

[dick.r.chiang]

I am close to threading gnus-group-get-new-news and am looking for datapoints
on the following:

1. Do you run gnus in a separate emacs instance?

2. If you use gnus-demon to refresh messages, what are your TIME and IDLE
values?  If you don't use gnus-demon, are you manually refreshing via "g" or
some other method?

For this user, I do run gnus separately from my dev work, and my
TIME is nil and IDLE is 7 minutes.  After threading, I hope to swap those
settings (TIME 7, IDLE nil).

Re: What's your gnus-demon-scan-news idle time?

[Eric S Fraga]

On Thursday, 24 Oct 2019 at 00:34, dick.r.chiang@gmail.com wrote:
> I am close to threading gnus-group-get-new-news and am looking for datapoints
> on the following:
>
> 1. Do you run gnus in a separate emacs instance?

I used to run separate instances when I had to access an imap server
that took 10s of seconds or more to respond.  As I no longer have that
constraint, I use a single emacs instance now.

> 2. If you use gnus-demon to refresh messages, what are your TIME and IDLE
> values?  If you don't use gnus-demon, are you manually refreshing via "g" or
> some other method?

I don't use the dæmon but would do so it gnus-group-get-new-news were
threaded so I look forward to the developments!

Thanks,
-- 
Eric S Fraga via Emacs 27.0.50 & org 9.2.6 on Debian bullseye/sid

Re: What's your gnus-demon-scan-news idle time?

[Jorge A. Alfaro-Murillo]

dick.r.chiang@gmail.com writes:

> I am close to threading gnus-group-get-new-news 

That's great news!

> and am looking for datapoints on the following: 
> 
> 1. Do you run gnus in a separate emacs instance?

No.

> 2. If you use gnus-demon to refresh messages, what are your TIME 
> and IDLE values?  If you don't use gnus-demon, are you manually 
> refreshing via "g" or some other method?

2 min and t.

Best,
-- 
Jorge.

Re: What's your gnus-demon-scan-news idle time?

[Gijs Hillenius]

On 24 October 2019 00:34 dick.r.chiang@gmail.com, wrote:

> I am close to threading gnus-group-get-new-news and am looking for datapoints
> on the following:
>
> 1. Do you run gnus in a separate emacs instance?

Gnus is the core of my workflow, so no. It _is_ the Emacs instance.

> 2. If you use gnus-demon to refresh messages, what are your TIME and IDLE
> values?  If you don't use gnus-demon, are you manually refreshing via "g" or
> some other method?

I use "g" and this will lock Emacs for a few seconds.

Re: What's your gnus-demon-scan-news idle time?

[Adam Sjøgren]

dick.r.chiang@gmail.com writes:

> 1. Do you run gnus in a separate emacs instance?

Yes.

> 2. If you use gnus-demon to refresh messages, what are your TIME and IDLE
> values?  If you don't use gnus-demon, are you manually refreshing via "g" or
> some other method?

I have this set up:

  ; Demon to fetch email every 5 minutes when Emacs has been idle for 5 minutes:
  (gnus-demon-add-handler 'gnus-demon-scan-news 5 5)

and I use 'g' manually to fetch as well.

Come to think of it, I have wrapped 'g' like this:

  (defun asjo-group-get-new-news ()
    "Do the equivalent of g M-< n :*)"
    (interactive)
    (save-excursion
      (setq asjo-fetch-was-manual t)
      (gnus-group-get-new-news)
      (goto-char (point-min)))
      (gnus-group-next-unread-group 1)
      (setq asjo-fetch-was-manual nil))

Mainly so point jumps to the first unread group after news are fetched.

(I use the asjo-fetch-was-manual variable to determine whether new
emails gets forwarded to my phone or not - the idea being that if the
fetch is done manually, it means that I am sitting at the Emacs, so I
don't need the emails to go to the the phone¹.)


  Best regards,

    Adam


¹ I don't use IMAP to share email between Gnus and phone, instead I use
nnml to store email locally, and automatically forward a subset (using
splitting) of the emails to the phone.

-- 
 "Where the world is going?                                   Adam Sjøgren
  Back to where it once was"                             asjo@koldfront.dk

Re: What's your gnus-demon-scan-news idle time?

[Eric S Fraga]

On Thursday, 24 Oct 2019 at 23:08, Adam Sjøgren wrote:
> (I use the asjo-fetch-was-manual variable to determine whether new
> emails gets forwarded to my phone or not - the idea being that if the
> fetch is done manually, it means that I am sitting at the Emacs, so I
> don't need the emails to go to the the phone¹.)

Interesting.  Do you therefore forward to a different email account for
your phone?  I'm still trying to find a good workflow for email on my
phone...
-- 
Eric S Fraga via Emacs 27.0.50 & org 9.2.6 on Debian 9.9

Re: What's your gnus-demon-scan-news idle time?

[Adam Sjøgren]

Eric writes:

> On Thursday, 24 Oct 2019 at 23:08, Adam Sjøgren wrote:
>> (I use the asjo-fetch-was-manual variable to determine whether new
>> emails gets forwarded to my phone or not - the idea being that if the
>> fetch is done manually, it means that I am sitting at the Emacs, so I
>> don't need the emails to go to the the phone¹.)
>
> Interesting.  Do you therefore forward to a different email account for
> your phone?

Yes, and that account is only used for transfering email to the phone.

It also is easy to transfer an email to the phone when I'm using emails,
just resend it (S D r) to the phone's email-address.

> I'm still trying to find a good workflow for email on my phone...

I wanted to continue to use nnml, and I didn't want to read all emails
twice, so I found this hybrid setup which works pretty well for me.

In addition to the "only forward when email was fetched automatically",
I have my splits set up, so I have the split that sends to the mobile
below the things I never want to see on my phone, like cron emails and
stuff:

          ; I don't want cron on my mobile:
          ("From" "\\(root\\|news\\)@koldfront.dk" "cron")
            ...
          ("Subject" ".*\\[tullinup\\].*" "cron")
          ("List-Id" ".*<\\([^.]+\\)\.[^.]+\.github\.com>.*" "github.\\1")
          ; Resend to mobile:
          ;   Must not match, otherwise the splitting ends here maybe it
          ;   would be nicer to (& (resend-to-mobile-split) (| (the rest))) ?
          (: resend-to-mobile-split "NAMEOFPHONE@koldfront.dk")
          ("Delivered-To" "asjo\\+.*@" "unknown-user")
             ...

which makes for a very simple way to configure what goes to the phone
and what doesn't.


  Best regards,

    Adam

-- 
 "HALLELUJAH!                                                 Adam Sjøgren
  Så att säga."                                          asjo@koldfront.dk

Re: What's your gnus-demon-scan-news idle time?

[Eric S Fraga]

On Friday, 25 Oct 2019 at 15:27, Adam Sjøgren wrote:
> I wanted to continue to use nnml, and I didn't want to read all emails
> twice, so I found this hybrid setup which works pretty well for me.

Yes, I have the same desire.  I'm comfortable with splitting so I think
I will give this a go.  May therefore need to start using the demon...

Thank you.
-- 
Eric S Fraga via Emacs 27.0.50 & org 9.2.6 on Debian 9.9

Re: What's your gnus-demon-scan-news idle time?

[Adam Sjøgren]

Eric writes:

> On Friday, 25 Oct 2019 at 15:27, Adam Sjøgren wrote:
>> I wanted to continue to use nnml, and I didn't want to read all emails
>> twice, so I found this hybrid setup which works pretty well for me.
>
> Yes, I have the same desire.  I'm comfortable with splitting so I think
> I will give this a go.  May therefore need to start using the demon...

Here's the code for the split I use:

  (defun resend-to-mobile-split (resend-to)
    "Call this as a fancy split to resend the message and continue (the split doesn't match anything, so splitting continues.)"
    (save-excursion
      (save-restriction
        (if asjo-fetch-was-manual
            (message "Not sending to mobile; user fetch")
          (resend-to-mobile resend-to))
          nil)))

  (defun resend-to-mobile (resend-to)
    "Actually resend the message."
    (message "Resending to mobile; automatic fetch")
    (widen)
    (message-resend resend-to))

In case you want compare what you come up with with my crude implementation.


  :-),

   Adam

-- 
 "Is my microphone on? Can you hear me?"                      Adam Sjøgren
                                                         asjo@koldfront.dk

Re: What's your gnus-demon-scan-news idle time?

[Eric S Fraga]

Thanks.  Simple code and would do all I would need.
-- 
Eric S Fraga via Emacs 27.0.50 & org 9.2.6 on Debian bullseye/sid

Re: What's your gnus-demon-scan-news idle time?

[Bob Newell]

Aloha,

I run a single instance of emacs, and I refresh gnus only with 'g' on
a purely manual basis. But that isn't the full story.

I use IMAP exclusively as I run gnus and emacs across something like 8
devices. Since checking/fetching IMAP is slow and blocking, I only
want to do that when (a) I know there is something to fetch and (b) I
want to fetch it.

When emacs starts, I have it launch a bash script that loops and
periodically checks for new mail in my IMAP boxes (primarily gmail).
If there is new mail (not just unread mail, but something newly
arrived since last check) it writes a small drop file and barks (plays
a sound).

A small function driven off the mode-line checks the drop file. This
is very fast with no perceptible overhead. The modeline shows the
number of new emails. (A few other functions deal with updating the
mode line when I actually read the new mail.)

So when I either hear the bark or notice new mail in the modeline, and
I feel okay with stopping my work for a bit, I make a manual check. At
this point I don't mind the blocking operation.

Now, at least for me, NOT checking email often is a good thing. I used
to check it a lot. Maybe it's a positive feature that IMAP email
reading with gnus is both blocking and slow, because my
constant/frequent checking/reading email was an enormous time waster
and productivity drain.

Bob Newell
Honolulu, Hawai`i

Re: What's your gnus-demon-scan-news idle time?

[Eric Abrahamsen]

dick.r.chiang@gmail.com writes:

> I am close to threading gnus-group-get-new-news and am looking for datapoints
> on the following:

I'm very curious to hear how you're handling threading! My observation
has been that you can't (currently) run individual servers in their own
threads, because they all fight over the nntp-server-buffer, and that
threading the entire new-news update process basically still blocks all
of emacs. How are you doing it?

> 1. Do you run gnus in a separate emacs instance?
>
> 2. If you use gnus-demon to refresh messages, what are your TIME and IDLE
> values?  If you don't use gnus-demon, are you manually refreshing via "g" or
> some other method?

I don't do either of these. My IMAP servers are local, so there's very
little lag. My NNTP server connection seems to fail by itself every
eight or nine minutes, so there's exactly no lag there :) Not until I
make an effort to reconnect.

> For this user, I do run gnus separately from my dev work, and my
> TIME is nil and IDLE is 7 minutes.  After threading, I hope to swap those
> settings (TIME 7, IDLE nil).

Bob Newell <bobnewell@bobnewell.net> writes:

> Aloha,
>
> I run a single instance of emacs, and I refresh gnus only with 'g' on
> a purely manual basis. But that isn't the full story.
>
> I use IMAP exclusively as I run gnus and emacs across something like 8
> devices. Since checking/fetching IMAP is slow and blocking, I only
> want to do that when (a) I know there is something to fetch and (b) I
> want to fetch it.
>
> When emacs starts, I have it launch a bash script that loops and
> periodically checks for new mail in my IMAP boxes (primarily gmail).
> If there is new mail (not just unread mail, but something newly
> arrived since last check) it writes a small drop file and barks (plays
> a sound).
>
> A small function driven off the mode-line checks the drop file. This
> is very fast with no perceptible overhead. The modeline shows the
> number of new emails. (A few other functions deal with updating the
> mode line when I actually read the new mail.)
>
> So when I either hear the bark or notice new mail in the modeline, and
> I feel okay with stopping my work for a bit, I make a manual check. At
> this point I don't mind the blocking operation.
>
> Now, at least for me, NOT checking email often is a good thing. I used
> to check it a lot. Maybe it's a positive feature that IMAP email
> reading with gnus is both blocking and slow, because my
> constant/frequent checking/reading email was an enormous time waster
> and productivity drain.

Now we know what your 1,000 lines of config are doing! That is a nice
solution. Running a local IMAP server does a bit of the same work, in
that you end up having to make a conscious decision to check your mail,
but the automatic (but fairly subtle) notification is a nice touch.

Eric

Re: What's your gnus-demon-scan-news idle time?

[dick]

EA> because they all fight over the nntp-server-buffer

That's exactly right.  I dynamic-let a dedicated nntp-server-buffer per
thread-backend instance.

Re: What's your gnus-demon-scan-news idle time?

[Eric Abrahamsen]

dick <dick.r.chiang@gmail.com> writes:

> EA> because they all fight over the nntp-server-buffer
>
> That's exactly right.  I dynamic-let a dedicated nntp-server-buffer per
> thread-backend instance.

Interesting! I look forward to seeing it.

Re: What's your gnus-demon-scan-news idle time?

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> dick <dick.r.chiang@gmail.com> writes:
>
>> EA> because they all fight over the nntp-server-buffer
>>
>> That's exactly right.  I dynamic-let a dedicated nntp-server-buffer per
>> thread-backend instance.
>
> Interesting! I look forward to seeing it.

Yes, sounds great.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Wrong default NNIR search method.

[Spenser Truex]

In the manual:
>8.1.3.9 Customizations
>nnir-method-default-engines
>     Alist of pairs of server backends and search engines.  The default
>     associations are
>          (nnimap . imap)
>          (nntp . gmane)
>
but in the file nnir.el
(defcustom nnir-method-default-engines  '((nnimap . imap)) ...)
So I suggest this diff to the file:

581c581,582
< (defcustom nnir-method-default-engines  '((nnimap . imap))
> (defcustom nnir-method-default-engines  '((nnimap . imap)
>                                           (nntp . gmane))

-- 
Spenser Truex
usenet@spensertruex.com
https://spensertruex.com/
San Francisco, USA

Re: Wrong default NNIR search method.

[Eric Abrahamsen]

Spenser Truex <usenet@spensertruex.com> writes:

> In the manual:
>>8.1.3.9 Customizations
>>nnir-method-default-engines
>>     Alist of pairs of server backends and search engines.  The default
>>     associations are
>>          (nnimap . imap)
>>          (nntp . gmane)
>>
> but in the file nnir.el
> (defcustom nnir-method-default-engines  '((nnimap . imap)) ...)
> So I suggest this diff to the file:
>
> 581c581,582
> < (defcustom nnir-method-default-engines  '((nnimap . imap))
>> (defcustom nnir-method-default-engines  '((nnimap . imap)
>>                                           (nntp . gmane))

Unfortunately it is the manual that should be updated to reflect the
file, not the other way around -- gmane no longer has search
functionality :(