Re: Gnus work

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> 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.

Great! This is definitely the most ambitious thing I've got in mind, it
will take a lot of work, but I think it would be a big gain.

[...]

> 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).

That's not what I was planning :) Mainly I'd like to try to separate out
concerns a bit: eg, instead of two functions that both do a little bit
of mark manipulation and a little bit of buffer setup, have one function
that only handles marks/headers/etc, and one function that only handles
the buffer creation. Probably no less code, but clearer and more easily
testable.

> 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.

I'll try not to make it worse. Speaking of which, do you have a general
sense of where the bottlenecks might be? I wasn't planning on attacking
the performance issue, but it would be good to have in mind.

>> 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.

Yeah, I'm not too optimistic about this. We'll see.

I do hope you could take a moment and scan the roadmap. It would be
valuable even just to get a quick reaction from you -- you know way more
about what's feasible than I do.

Eric