From: Jesse Rosenthal <jrosenthal@jhu.edu>
To: Carl Worth <cworth@cworth.org>, notmuch@notmuchmail.org
Subject: Re: [PATCH] Fix bug, and clean up code duplication,
	in adding or removing tag by region.
In-Reply-To: <87zl16ez21.fsf@yoom.home.cworth.org>
References: <m1636w7au5.fsf@watt.gilman.jhu.edu> <87sk90ragj.fsf@jhu.edu>
	<87aatfq88h.fsf@yoom.home.cworth.org> <877hogaf7v.fsf@jhu.edu>
	<878w8rkzis.fsf@yoom.home.cworth.org> <871vejxk94.fsf@jhu.edu>
	<87zl16ez21.fsf@yoom.home.cworth.org>
Date: Wed, 14 Apr 2010 13:50:50 -0400
Message-ID: <m1bpdlord1.fsf@watt.gilman.jhu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list

On Wed, 14 Apr 2010 10:14:46 -0700, Carl Worth <cworth@cworth.org> wrote:
> The only real problem I see with this approach is that it's fragile in
> depending on the buffer having exactly 2 lines of non-thread text at the
> end. I can easily see myself wanting to remove the "End of Search
> Results" line at the end of the buffer. And if I do that, this code will
> break, (tag manipulations will miss the last message).

I was a bit worried about that myself. I hard-coded the 2 based on the
hard-coding in `notmuch-search-last-thread' (">"), which currently goes
to the bottom and then goes up two lines. But it seems like if there
were a more robust approach, it could be used in both.

> A more robust fix would check for the ability to read a thread
> ID. So making a single function such as
> notmuch-search-find-last-line-with-thread-id or so would do the trick
> here.

It occurs to me that the best way to do this would probably be to go to
point-max, and then (forward-line -1) until we hit a thread-id. That way
we wouldn't have to work all the way down long search indexes. I'll try
to code that up for the next release, and then have
notmuch-search-last-thread use it, as well as the region functions.

Best,
Jesse