From: Tassilo Horn <tassilo@member.fsf.org>
To: Carl Worth <cworth@cworth.org>
In-Reply-To: <87k4xdq7ys.fsf@yoom.home.cworth.org> (Carl Worth's message of
	"Thu, 26 Nov 2009 13:42:03 -0800")
References: <87tywlji10.fsf@thinkpad.tsdh.de>
	<87k4xdq7ys.fsf@yoom.home.cworth.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)
Date: Fri, 27 Nov 2009 09:13:12 +0100
Message-ID: <87d4349yhz.fsf@thinkpad.tsdh.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: notmuch@notmuchmail.org
Subject: Re: [notmuch] [PATCH] Return unpropertized strings for filename and
	message-id
Precedence: list

Carl Worth <cworth@cworth.org> writes:

Hi Carl,

>> Here's my first patch.  It changes that notmuch-show-get-filename and
>> notmuch-show-get-message-id return simple strings and not propertited
>> strings.
>
> Thanks, Tassilo!
>
> It's great to have a contribution from you in notmuch. I've pushed
> this out now.

I guess it won't be the last one.  There are some byte-compiler warnings
with notmuch.el, that I'd like to remove.

> Two things with regards to your patch:
>
>   1. It's most convenient (for me) to apply emailed patches by sending
>      directly to "git am". And "git am" just happens to want to see the
>      complete commit message as the first thing in the mail message,
>      (continuing the summary of the commit which comes from the
>      subject).
>
>      So to satisfy "git am", introductory and explanatory portions of
>      the email, ("Hi!" and "Here's my first patch"), have to be
>      relegated to past the "---" divider).

So an email looking like this would be correct?

--8<---------------cut here---------------start------------->8---
From: Tassilo Horn <tassilo@member.fsf.org>
To: Carl Worth <cworth@cworth.org>
Cc: notmuch@notmuchmail.org
Date: Fri, 27 Nov 2009 08:54:41 +0100
Subject: [PATCH] Remove preprocessor code

Don't define RUNNING_ON_VALGRIND, so that notmuch is probably broken.
---
 debugger.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/debugger.c b/debugger.c
index e8b9378..f32cdc9 100644
--- a/debugger.c
+++ b/debugger.c
@@ -24,8 +24,6 @@
 
 #if HAVE_VALGRIND
 #include <valgrind.h>
-#else
-#define RUNNING_ON_VALGRIND 0
 #endif
 
 notmuch_bool_t
-- 
1.6.5.3

Hi Carl,

this patch is completely wrong.  Please don't apply it. :-)

And thanks again for the great work.

Bye,
Tassilo
--8<---------------cut here---------------end--------------->8---

>   2. Maybe I'll undermine my point above, but the commit here really
>      *does* need a commit message beyond the first line.
>
>      I've described this before as the one-line summary giving the
>      "what" and the rest of the commit message giving the "why".

Makes sense.

>      And this is a perfect case of that. I can see exactly what the
>      patch does, and it makes sense. But I tried to write the rest of
>      the commit message and found I couldn't. In what cases did the
>      presence of text properties cause a problem? I don't know, and
>      that's what the commit message should have said.

Normally it causes almost never any problems, but IMO it's just bad
style.  When a user wants to get the Message-id, he most probably only
wants to do some calculations on that (e.g. jump to that message in Gnus
or rmail), or insert it somewhere else.  In the first case, text
properties aren't needed, and in the second case, it's most unlikely
that he wants to have exactly the same properties there, especially if
there are properties different from faces.

> I'd said before that I would bounce patches with only a one-line
> summary. I guess I'm still too soft, but do expect me to be more
> strict on this in the future. :-)

Yes, that all makes perfect sense, and because there are so many people
and patches for notmuch (which is great!), there have to be some strict
guidelines.

But instead of mailing each first-time committer a mail, you might
consider putting those guidelines on the notmuch homepage. :-)

Bye,
Tassilo