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

Previous Next

Full log

Message #31 received at 38136 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: dick.r.chiang <at> gmail.com
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 38136 <at> debbugs.gnu.org
Subject: Re: bug#38136: [PATCH] Make gnus-group-get-new-news a non blocking
 thread
Date: Mon, 18 Nov 2019 15:18:10 -0800

On 11/18/19 17:22 PM, dick.r.chiang <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.