bug#38136: [PATCH] Make gnus-group-get-new-news a non blocking thread

[Eric Abrahamsen <eric@ericabrahamsen.net>]

On 11/18/19 17:22 PM, dick.r.chiang@gmail.com wrote:
> I am very grateful for your interest and testing!

My pleasure, of course -- I think this is an important direction to be
going in.

>> selecting a deleted buffer
>
> I get this quite a bit.  It occurs when `gnus-summary-buffer` in the main
> thread gets usurped by a background thread.  I am either allowing this
> important variable to get reassigned before the dynamic-let in `gnus-thread-body`
> or I am not understanding dynamic-let in the presence of threads.
> Incidentally, it's very difficult to point to lines of code I'm talking
> about without git{hub,lab}.

We could consider turning on `lexical-binding' in gnus-start.el, and
just see what happens :)

Regarding code line numbers, etc, I just do it manually -- I'm looking
at the code to begin with, and it's trivial to check what line I'm on.

>> line 1791, because it's expecting "(car gnus-group-list-mode)" to be a
>> number, but it hasn't been set yet.
>
> I'll look into this, and add a test for `nntp-open-server`.
>
> I am happy to let this marinate to get people thinking about Gnus's
> future. There are many historical artifacts (like blocking
> `gnus-group-get-new-news`
> and left-field variables like `gnus-secondary-select-methods`) that prevent
> Gnus from becoming a viable MUA for more people.

Well they definitely prevent bug-hunters and feature-implementers from
making much progress. Stuff like `gnus-group-list-mode' drives me nuts:
an undocumented variable that might totally change Gnus' behavior. But
unpicking this complexity is slow work.

> Some other fellow recently posted about an ephemeral group branch which he
> somehow got others to test for him in-parallel.  I don't know how he did that
> outside the debbugs system.

I make liberal use of git worktrees. I made a local branch to apply your
patch, then checked it out into a separate directory with "git worktree
add" and built Emacs there. Then I run that Emacs. For Gnus stuff I have
a package called gnus-mock that provides a working Gnus environment with
dummy data. I point gnus-mock at the worktree directory, and it starts
up a clean Emacs with the Gnus data in place. I do most of my testing
there.

On the Emacs side it's projectile and magit: projectile indexes the
worktree as a separate project. If you send me a line number from your
branch to look at, I do "C-c p p" -> helm-projectile-switch-project
which opens up magit for the project, then "C-c p f" ->
helm-projectile-find-file, then the usual "M-g g" -> goto-line. Not too
inconvenient.

If you have access to the Emacs repos and are collaborating with others
who do, too, then it can make sense to push a "feature/foo" branch to
the repos, and share it. I've done testing that way.

What I'd like is a Gnus summary minor mode I could enable in, say,
"emacs.bugs", which turns commit hashes into hyperlinks and provides
commands for "apply the attached patch to some worktree". I think other
people have done that, I've just never gotten around to it.

Eric