Re: Gnus work

[Tim Landscheidt <tim@tim-landscheidt.de>]

Eric Abrahamsen <eric@ericabrahamsen.net> wrote:

> I've been very slowly reading the Gnus code base, and looking at how to
> go about doing some refactoring, cleanups, and a few new features. I
> wrote a roadmap which I'm attaching here -- it's not so much an actual
> roadmap as a collection of possible changes, as a starting point for
> argument. It's also not meant to be a mini bug tracker in Org -- my idea
> was that if any of the ideas looked like they were going to be
> acceptable, the todo items would turn into real bug reports on debbugs.

> […]

You, Sir, are my hero :-).  I'm always torn by Gnus: On the
one hand, it offers ample opportunity to do whatever you
want.  On the other hand, if what you want is not described
in the manual or there is not already a suitable code snip-
let out there, reading through the source is a nightmare.  I
do not even have a mental picture where what data is stored
at which point of time.

So I can only wholeheartedly support any effort to change
this :-).  One thing I would prefer, though, is documenting
(and refactoring) before any user-visible changes (and given
how users typically interact with Gnus's internals that can
be even small changes).  It's much easier to review and test
that a change does not break something if it does not
(should not) affect Gnus's outwards behaviour.  For example,
while I agree some parts of Gnus's configuration & Co. are
way too byzantine, changing it in an incompatible way would
effectively say to Gnus users: "We broke your setup, you're
welcome."  So any such changes should come at the end of the
"road".

Tim