Date: Tue, 02 Apr 2013 13:46:25 -0600
From: Felipe Contreras <felipe.contreras@gmail.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>, 
	Felipe Contreras <felipe.contreras@gmail.com>
Message-ID: <515b359189b29_146e1045e1093948@nysa.mail>
In-Reply-To: <1359388340-27136-6-git-send-email-kirill@shutemov.name>
References: <1359388340-27136-1-git-send-email-kirill@shutemov.name>
	<1359388340-27136-6-git-send-email-kirill@shutemov.name>
Subject: RE: [PATCH 5/5] Drop harmful reply buffer preparation
Mime-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: notmuch@notmuchmail.org
Precedence: list

Kirill A. Shutemov wrote:
> From: "Kirill A. Shutemov" <kirill@shutemov.name>
> 
> Inserting empty lines at the end of reply buffer and switching to insert
> mode are not what user want on reply. It's only annoying if you try to
> comment on patch.
> 
> If a user really wants this kind of preparation it should be implemented
> as an user-specific hook.

Insert mode, maybe, but the empty lines don't hurt. See, with your patch I end up in:

>  			part = orig.find_first_text
>  			part.convert.each_line do |l|
>  				body_lines << "> %s" % l.chomp
> -- 
> 1.7.10.4		<- HERE
> 
> -- 

I cannot type there, and in any case I have to remove those lines, so I end
selecting the text upwards and remove them.

With the current code:

>  			part = orig.find_first_text
>  			part.convert.each_line do |l|
>  				body_lines << "> %s" % l.chomp
> -- 
> 1.7.10.4
> 
> 			<- HERE
> 
> -- 

Not much of a difference, I still have to select the lines upwards and remove them.

That is of course if you reply *inline*. You might want to reply to the whole
thing without modifications, in which case the original behavior is more
useful.

I'm not strongly opposed to this, but I don't see why those extra lines would hurt.

Cheers.

-- 
Felipe Contreras