Re: Gnus work

[Lars Ingebrigtsen]

Eric Abrahamsen <address@hidden> writes:

> 1. Replace Gnus' homemade mechanisms with equivalent mechanisms that
>    have since appeared in core (in many cases Gnus had them first).

Sounds good.  The backend interface is particularly grungy and could to
with a complete rewrite.  Since there are probably extremely few
out-of-tree backends these days, I think you can massacre the interface
with impunity without thinking about compatibility.

> 2. Add docstrings and comments to minimize bug-hunter bewilderment.

Sounds good.

> 3. Look at unpicking functions so that there's a clearer demarcation
>    between code that does server logic (marks and whatnot) and code that
>    does UX/presentation stuff.

There's a lot of long functions in Gnus, but there's also a reason for
many of them being that way.  The first is that when setting up modes
and stuff, there's a lot of things that just have to be, er, set up.
Replacing a long litany of stuff like

(setq truncate-lines t
      mode-line-format foo)

with

(gnus-set-truncate-lines-to-t)
(gnus-set-mode-line-format foo)

isn't that much clearer.  :-)

(I'm just kidding, but that's kinda the Unclean Bob style of
refactoring).

The other consideration is that Emacs Lisp is really slow.  Splitting
central functions into many component functions will make Gnus even
slower than it already is.  And Gnus is slow.

> 5. Reduce number of dynamic variables, to cut back on "spooky action at
>    a distance". To be honest I don't even know where to start here.

Good luck, but Gnus has a gazillion settings that modify its workings in
many, many ways, and they're all done by variables.  Trimming down that
overload of settings would be nice, but every time I've tried, there's
always somebody that relied on just that single thing you'd think that
nobody would be weird enough to actually use.

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