Date: Wed, 23 Apr 2014 08:44:46 -0700
From: "W. Trevor King" <wking@tremily.us>
To: Carl Worth <cworth@cworth.org>
Subject: Re: Thanks for the nmbug-status program
Message-ID: <20140423154445.GN9243@odin.tremily.us>
References: <87eh0prrup.fsf@yoom.home.cworth.org>
	<20140422213442.GI9243@odin.tremily.us>
	<8761m1rmtp.fsf@yoom.home.cworth.org>
	<20140423001824.GM9243@odin.tremily.us>
	<87wqegr3dm.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="j1Wwy33+dU2Jf0xa"
Content-Disposition: inline
In-Reply-To: <87wqegr3dm.fsf@yoom.home.cworth.org>
OpenPGP: id=39A2F3FA2AB17E5D8764F388FC29BDCDF15F5BE8;
	url=http://tremily.us/pubkey.txt
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Notmuch List <notmuch@notmuchmail.org>
Precedence: list


--j1Wwy33+dU2Jf0xa
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 22, 2014 at 11:01:09PM -0700, Carl Worth wrote:
> W. Trevor King writes:
> >> > I think that making nmbug and nmbug-status generally applicable
> >> > for other projects is a good target.  I don't see any need to
> >> > pull them out into a stand-alone project to do that though.
> >>=20
> >> For what it's worth, I don't disagree.
> >
> > Does that mean your patches are aimed upstream at the notmuch
> > repository?
>=20
> I didn't really intend them that way. What I meant was that I'd be
> happy to switch to a script within the notmuch repository if it did
> what I wanted, (which is basically just "create an HTML file from a
> notmuch query").

So, =E2=80=9Chere's a goal to shoot for, and I'm happy with my fork.  If
someone else wants to land patches like these upstream, I'm also happy
dropping my fork.=E2=80=9D ;).  I think it would be easier to just mail your
patches to the list and see what sticks.

> > (or their shell's approriate environment variable syntax), and I'd
> > version the config file in the same repo as the associated tags.  I
> > don't see the point of keeping the config file somewhere else, when
> > you'll already need a repository to store the tags.
>
> Ah, then you've missed something different about my usage. I don't
> have any repository storing tags. My tags exist only in my notmuch
> database.

I had missed that, thanks for clarifying.  I still like the
config-from-repository-branch functionality because nmbug tag
repositories are part of the nmbug-status ecosystem, but I agree that
you shouldn't need a tag repository if you don't want to collaborate
on tag maintenance.

> > * d456390 Add a comment describing the program
> >
> > I like the idea, but I'd prefer a docstring just after the leading
> > comment.  Then we could reuse the docstring as the description for
> > the ArgumentParser.
>=20
> Sure. That's better.

Would you like to write that up?

> > * 336411f Add "notmuch search" to the advertised queries.
> >
> > Folks can already copy-paste the terms into Emacs etc.  You only
> > need the 'notmuch search' prefix if you're pasting into a shell,
> > in which case you'll also want to escape shell-sensitive
> > characters like parenthesis.  I'm fine without this one.
>=20
> This is more about advertising notmuch to people not familiar with
> it. It's more important for something like "mesa stable queue" than
> it is for the notmuch bug list, of course.

That makes sense, but I'd prefer something like:

  <p>This view is generated from the following
    <a href=3D"http://notmuchmail.org/searching/">Notmuch query</a>:
  </p>
  <p>
    <code>
  view['query-string']
    </code>
  </p>

That name-drops Notmuch without implying that the whole thing is
copy-pastable into a shell.  Neither your queries [1] nor our
nmbug-status queries [2] use parens at the moment, but the current
master's example config does [3].

> > * 396869c Add support for a --query option (along with a default config=
uration)
> >
> > I don't have an opinion about this one ;).  The default config doesn't
> > look very useful (especially with it's dummy metadata settings), but
> > I'd only be using the in-Git-config approach, and I don't mind if
> > others want something like this.
>=20
> This is about making this script self-documenting.
>=20
> When I first tried nmbug-status I got just a stack trace[*], not even a
> usage message.

Heh, that should probably be fixed ;).  There's a nice example config
at devel/nmbug/status-config.json, but something that's bound more
tightly to the script itself seems useful.

> Even after running "nmbug-status --help" I wasn't any closer to
> knowing how to run the thing. It wasn't obvious that --config was
> the option I needed to get things to work, (from the stack trace,
> clearly this script wants some git repository somewhere), and even
> if I had know that --config was what I wanted, I had no idea how to
> construct a config file.

I hadn't understood that your built-in config was more of a
teaser/seed for new users, it makes more sense in that light.  I'd
prefer a clearer error message when we can't find a config file (I'm
working up a patch now ;), and documentation for the config file
format in 'nmbug-status --help' (where it's clearly static assistence
for unfamiliar users).

Cheers,
Trevor

[1]: http://cworth.org/~cworth/mesa-stable-queue/
[2]: http://nmbug.tethera.net/status/
[3]: http://git.notmuchmail.org/git/notmuch/blob/40dc79d6ac828bc24ae1ec797a=
a50e53fc455621:/devel/nmbug/status-config.json#l65

--=20
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

--j1Wwy33+dU2Jf0xa
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTV9/rAAoJEKKfehoaNkbtASwP/jgLDvQxgP0MB+DDbM1DrdtD
yj0kzbuCZWUmXBeMFvEllfEXaySDhR5Q38N7ZL0rZhAQRYwif+a63MworaCFk6VB
u4u4DlyJR0nj1o2mNjGTugv5x/aOUm4T1RTklJ5+v214LfBFKBVAtWqxU+AUglz/
JFa23PZNiJ/CFmvxpPnxJ4GD8EHlaRUUikOPIrP1h9RFga5XYhPLagu9shYX5pOB
Udao6NOoLftiHxioyT9SBc9CYNTAb9F9jBtJ1uvLG3HBxVwqgaxE1rbqersOU26a
MPQU57yGvKzungJIgdkpydGDwmmO7Uc6tVNpBvwvAuHswFzn4X3NQtwmZ0DbW6Fu
p0lrEyEEeurXo1nFDbObIKmxyC0wWcF9CzRKsakBHTYHxkZjxKCV3kOwv+E50Pbf
AoRON3BaLIQzLfxQn+Rq/KyxMQG7+yQZfwaQC7mb759qUvxY/8CE66EAwxrzDBtY
QhXNs1YT4YGeXxRvZkXe2QWYBFC+9lQ1i4xp5vHi+4rDCM8VwqJLfE6Qi+9nlZr1
w+OsNs5u5+Dfe71/Avw/gMpbvi4Raw3fhMEP5OX6cMHs1ouhi8UxONe7Md/4IO5g
KU09R070phMhdUintd+q+zV4S8ubuOd5UOQaRXLWjHpz3Gdv/5/jblkwhhsUTrJP
4IdPXNXIWH1OuEJJReyG
=EZAK
-----END PGP SIGNATURE-----

--j1Wwy33+dU2Jf0xa--