From: Carl Worth <cworth@cworth.org>
To: Jameson Rollins <jrollins@finestructure.net>,
	Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: [PATCH] emacs: add some convenience functions to show mode
In-Reply-To: <87vd3x9f2x.fsf@servo.finestructure.net>
References: <87zktbeekd.fsf@servo.finestructure.net>
	<87k4kddpto.fsf@yoom.home.cworth.org>
	<87vd3x9f2x.fsf@servo.finestructure.net>
User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.2.1
	(i486-pc-linux-gnu)
Date: Tue, 07 Dec 2010 14:10:10 -0800
Message-ID: <87ei9t5j5p.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Tue, 16 Nov 2010 15:41:10 -0500, Jameson Rollins <jrollins@finestructure=
.net> wrote:
> Hey, Carl.  I could do this, but I think I would ultimately just be
> submitting patches for notmuch to behave in the specific way that I want
> it to behave.  I'm pretty sure that everyone has different ideas of what
> they want, and I worry that if I start submitting my preference we'll
> have to contend with lots of debate over behavior preference, leading to
> lots of requests for more configuration options.

I don't know about contention, but that debate is exactly what I want to
encourage.

I *know* that the current set of keybindings is not ideal. It was simply
something I came up with for my own personal use once. So I don't wwant
to set it in stone just because it happens to be present already.

> This has actually
> already happened, most recently with my patch to remove thread archiving
> From the show-advance function [0].

Yes, and I want that discussion to continue. I'd like to even contribute
to it myself.

> My thought instead is that if we have a nice library of useful atomic
> functions, for things like tagging and thread navigation, it would make
> it easy for people to construct the exact behavior they want by defining
> their own functions and key bindings.

Yes. We do need useful primitive operations. But we also need the "best"
default bindings (according to some ill-defined metric, perhaps
involving executive decisions), and I'd like to see discussion to help
us ensure that our defaults are as good as possible.

What I don't want is a state where some particular defaults are used by
almost nobody, and nobody can use notmuch effectively without
customization.

> I could definitely submit a series of patches that would define what I
> personally consider ideal behavior[...]

I'd encourage you to submit these and let's discuss them. If there's no
objection then your preferred defaults can win. If there is objection,
then we know that there's some need for configurability and we can
decide what the defaults should be.

>                                     but since I'm quite sure that others
> would disagree with my choices, I think the patches would ultimately not
> be accepted and the work would therefore not be worth the trouble.

I can't guarantee that effort won't be wasted. (Many of the authors of
the patches languishing in my patch queue might already consider their
effort wasted...). But perhaps I can encourage the discussion by
refusing to accept a configuration option without evidence on the
mailing list of differing opinions on what the default should be?

> I'm definitely not trying to sound cynical here.

No need to apologize. Our community is still young and we're still
learning how to work together and how to form group decisions.

I do appreciate all of your contributions,

=2DCarl

=2D-=20
carl.d.worth@intel.com

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFM/rDC6JDdNq8qSWgRAr9WAJ9E8U+JuBgIWwHDL03NmENpQpsjlgCeKQRt
n295YdAJ5np9W2LoarqS8lU=
=VHLZ
-----END PGP SIGNATURE-----
--=-=-=--