[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ELPA] Package proposal: gnus-mock

From: Eric Abrahamsen
Subject: Re: [ELPA] Package proposal: gnus-mock
Date: Wed, 10 Oct 2018 13:12:55 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> I've just pushed the branch scratch/gnus-mock to ELPA, containing a
>> package I'd like to add there.
> Looks great!  Feel free to move it to a non-scratch branch (e.g. using
> "Version: 0" if you still don't want to release it as a GNU ELPA package).

Cool. If I'm going to work on this in ELPA, shouldn't I just move it
into master?

>> It's called "Gnus Mock", and provides a dummy test installation for
>> Gnus, which you can use for working on Gnus features and testing Gnus
>> bugs without endangering your own Gnus setup. I'm hoping this makes it
>> easier to do work on Gnus -- it's often hard to hack on without a full
>> working installation, and no one wants to risk their own mail on that.
> And here I was, thinking it was mostly designed for use by automated tests.

I actually hadn't thought of that. There's no reason you couldn't use it
that way, though currently there's no hook for automatically running
code after the child Emacs process boots up. I'll add an option for
appending code to the init file that's loaded by default.

Of course, Gnus doesn't have much separation between server logic and
user interaction. You'd end up with one of those test routines that
simulates user mouse clicks, ugh.

>> (defconst gnus-mock-data-dir
>>           (file-name-as-directory (expand-file-name
>>                                    "data"
>>                                    (file-name-directory load-file-name)))
>>    "Source directory for Gnus mock data.")
>>    That seems to work fine, but I wanted to check there wasn't a
>>    better/safer way to do it.
> I think that's about as good as it gets currently.
> It's pretty reliable/safe in this use case (it gets more tricky if you
> need to find such files during byte-compilation of your file).

Okay. I'm hoping Eli's comment was based on a misunderstanding, we'll


reply via email to

[Prev in Thread] Current Thread [Next in Thread]