unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: emacs-devel@gnu.org
Subject: Re: [ELPA] Package proposal: gnus-mock
Date: Wed, 10 Oct 2018 13:12:55 -0700	[thread overview]
Message-ID: <87pnwhmugo.fsf@ericabrahamsen.net> (raw)
In-Reply-To: jwvwoqpob7w.fsf-monnier+gmane.emacs.devel@gnu.org

Stefan Monnier <monnier@iro.umontreal.ca> 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
see.

Thanks,
Eric




  reply	other threads:[~2018-10-10 20:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-10 18:49 [ELPA] Package proposal: gnus-mock Eric Abrahamsen
2018-10-10 19:01 ` Eli Zaretskii
2018-10-10 19:53   ` Eric Abrahamsen
2018-10-12  8:16     ` Eli Zaretskii
2018-10-12 17:24       ` Eric Abrahamsen
2018-10-12 17:55         ` Eli Zaretskii
2018-10-12 19:02           ` Eric Abrahamsen
2018-10-12 19:24             ` Yuri Khan
2018-10-12 19:57               ` Eric Abrahamsen
2018-10-13 12:10                 ` Yuri Khan
2018-10-13 15:48                   ` Eric Abrahamsen
2018-10-12 19:52             ` Eli Zaretskii
2018-10-12 20:00               ` Eric Abrahamsen
2018-10-10 19:30 ` Stefan Monnier
2018-10-10 20:12   ` Eric Abrahamsen [this message]
2018-10-10 20:20     ` Stefan Monnier
2018-10-10 20:58       ` Eric Abrahamsen
2018-10-11  4:24         ` Yuri Khan
2018-10-11 16:41           ` Eric Abrahamsen
2018-10-17 17:47   ` Eric Abrahamsen
2018-10-18  0:34     ` Stefan Monnier
2018-10-18  2:17       ` Eric Abrahamsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pnwhmugo.fsf@ericabrahamsen.net \
    --to=eric@ericabrahamsen.net \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).