So this is incredibly confusing to me, but git is supposedly doing
something clever that allows these patches to apply in my repo but not
in a clean one.
In any event, I'm resending the patches after being applied to my
master, which should resolve any conflict and allow them to apply.
jamie.
So this is incredibly confusing to me, but git is supposedly doing
something clever that allows these patches to apply in my repo but not
in a clean one.
In any event, I'm resending the patches after being applied to my
master, which should resolve any conflict and allow them to apply.
jamie.
I really hate the default behavior of the space bar in notmuch-show; I
don't want it to pop out of the thread that i'm currently view, and I
especially don't want it to archive threads. The space bar should
just be for viewing, not altering.
The following patch breaks out the food functionality
On Sun, 6 Nov 2011 12:17:36 -0500, Austin Clements amdra...@mit.edu wrote:
This is a rebase and cleanup of Istvan Marko's patch from
id:m3pqnj2j7a@zsu.kismala.com
Search retrieves these headers for every message in the search
results. Previously, this required opening and parsing every
On Fri, 11 Nov 2011 02:33:38 +0100, Pieter Praet wrote:
> On Sun, 6 Nov 2011 12:17:36 -0500, Austin Clements
> wrote:
> > This is a rebase and cleanup of Istvan Marko's patch from
> > id:m3pqnj2j7a.fsf at zsu.kismala.com
> >
>
> Fantastic performance improvement Austin! [...]
... and
100644
> --- a/lib/database.cc
> +++ b/lib/database.cc
> @@ -1725,7 +1725,7 @@ notmuch_database_add_message (notmuch_database_t
> *notmuch,
> goto DONE;
>
> date = notmuch_message_file_get_header (message_file, "date");
> - _notmuch_m
(notmuch_database_t
*notmuch,
goto DONE;
date = notmuch_message_file_get_header (message_file, date);
- _notmuch_message_set_date (message, date);
+ _notmuch_message_set_header_values (message, date, from, subject);
_notmuch_message_index_file
Quoth Pieter Praet on Nov 11 at 2:38 am:
On Fri, 11 Nov 2011 02:33:38 +0100, Pieter Praet pie...@praet.org wrote:
On Sun, 6 Nov 2011 12:17:36 -0500, Austin Clements amdra...@mit.edu
wrote:
This is a rebase and cleanup of Istvan Marko's patch from
id:m3pqnj2j7a@zsu.kismala.com
On Sun, 6 Nov 2011 17:01:14 -0500, Austin Clements wrote:
> On Sun, Nov 6, 2011 at 4:07 PM, Jani Nikula wrote:
> > On Sun, ?6 Nov 2011 12:17:36 -0500, Austin Clements
> > wrote:
> >> Taking full advantage of this requires a database rebuild, but it will
> >> fall back to the old behavior for
notmuch_message_set_date (message, date);
> + _notmuch_message_set_header_values (message, date, from, subject);
>
> _notmuch_message_index_file (message, filename);
> } else {
> diff --git a/lib/message.cc b/lib/message.cc
> index 8f22e02..ca7fbf2 100644
On Sun, 06 Nov 2011 23:07:51 +0200, Jani Nikula wrote:
> ...what's the most convenient way of rebuilding the database while
> preserving my tags etc.? If this was merged, would an older version of
> notmuch choke on the rebuilt database with these headers? (To me it
> looks like it would be
On Sun, 6 Nov 2011 12:17:36 -0500, Austin Clements wrote:
> Search retrieves these headers for every message in the search
> results. Previously, this required opening and parsing every message
> file. Storing them directly in the database significantly reduces IO
> and computation, speeding
On Sun, Nov 6, 2011 at 4:07 PM, Jani Nikula wrote:
> On Sun, ?6 Nov 2011 12:17:36 -0500, Austin Clements
> wrote:
>> Taking full advantage of this requires a database rebuild, but it will
>> fall back to the old behavior for messages that do not have headers
>> stored in the database.
>
>
(notmuch_database_t *notmuch,
goto DONE;
date = notmuch_message_file_get_header (message_file, "date");
- _notmuch_message_set_date (message, date);
+ _notmuch_message_set_header_values (message, date, from, subject);
_notmuch_message_index_fil
, from, subject);
_notmuch_message_index_file (message, filename);
} else {
diff --git a/lib/message.cc b/lib/message.cc
index 8f22e02..ca7fbf2 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -412,6 +412,21 @@ _notmuch_message_ensure_message_file (notmuch_message_t
On Sun, 6 Nov 2011 12:17:36 -0500, Austin Clements amdra...@mit.edu wrote:
Search retrieves these headers for every message in the search
results. Previously, this required opening and parsing every message
file. Storing them directly in the database significantly reduces IO
and
On Sun, 06 Nov 2011 23:07:51 +0200, Jani Nikula j...@nikula.org wrote:
...what's the most convenient way of rebuilding the database while
preserving my tags etc.? If this was merged, would an older version of
notmuch choke on the rebuilt database with these headers? (To me it
looks like it
On Sun, Nov 6, 2011 at 4:07 PM, Jani Nikula j...@nikula.org wrote:
On Sun, 6 Nov 2011 12:17:36 -0500, Austin Clements amdra...@mit.edu wrote:
Taking full advantage of this requires a database rebuild, but it will
fall back to the old behavior for messages that do not have headers
stored in
On Sun, 6 Nov 2011 17:01:14 -0500, Austin Clements amdra...@mit.edu wrote:
On Sun, Nov 6, 2011 at 4:07 PM, Jani Nikula j...@nikula.org wrote:
On Sun, 6 Nov 2011 12:17:36 -0500, Austin Clements amdra...@mit.edu
wrote:
Taking full advantage of this requires a database rebuild, but it will
These still need doc updates, but you can probably figure how to use them by
reviewing the patches ;).
These still need doc updates, but you can probably figure how to use them by
reviewing the patches ;).
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Hi!
On Mon, 10 Oct 2011 10:49:15 -0300, david at tethera.net wrote:
> OK, here is my proposal to add search terms to notmuch dump.
Having worked in the same area ;-), I felt competent to review this. And
I definitely do like David's approach. The patches look good, with the
following comments:
On Sun, 16 Oct 2011 22:34:29 +0200, Thomas Schwinge
wrote:
> Having worked in the same area ;-), I felt competent to review this. And
> I definitely do like David's approach. The patches look good, with the
> following comments:
Thanks for the review. I pushed a modified version of the
OK, here is my proposal to add search terms to notmuch dump.
Most of the work is in argument processing. It would be nice if we
could factor some of that out.
02be821 notmuch-dump: deprecate use of output file argument.
2b7781d test: all dump-restore tests should be working now
7a203d6
OK, here is my proposal to add search terms to notmuch dump.
Most of the work is in argument processing. It would be nice if we
could factor some of that out.
02be821 notmuch-dump: deprecate use of output file argument.
2b7781d test: all dump-restore tests should be working now
7a203d6
(it even hits one
existing test case---though an additional test case to show an actual
subject change appearing would be even better).
It's your call of course, and if the change doesn't go, then that's fine
too. In that case, I'll just not comment on this feature in NEWS until
our next releas
The feature to show subject changes in the collapsed thread view was
originally added (8ab433607) with an option
(notmuch-show-always-show-subject) to display the subject
for all messages, even when there was no change.
The subsequent commit (4f04d273) changed the sense of the test
The feature to show subject changes in the collapsed thread view was
originally added (8ab433607) with an option
(notmuch-show-always-show-subject) to display the subject
for all messages, even when there was no change.
The subsequent commit (4f04d273) changed the sense of the test
safe, (it even hits one
existing test case---though an additional test case to show an actual
subject change appearing would be even better).
It's your call of course, and if the change doesn't go, then that's fine
too. In that case, I'll just not comment on this feature in NEWS until
our next
Here is my proposal, based on Clint's suggestion on IRC, and on the
sed hack from librhash, to hide all symbols that are not explicitly
part of the notmuch API. In particular it hides the various symbols
related to Xapian exceptions.
hrm, sorry. Looks like those last two patches got a little messed up.
These two patches replace the previous two.
jamie.
hrm, sorry. Looks like those last two patches got a little messed up.
These two patches replace the previous two.
jamie.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Here is my proposal, based on Clint's suggestion on IRC, and on the
sed hack from librhash, to hide all symbols that are not explicitly
part of the notmuch API. In particular it hides the various symbols
related to Xapian exceptions.
___
notmuch mailing
Bah, my previous attempt didn't build cleanly in a chroot, so I had to
patch setup.py.
Bah, my previous attempt didn't build cleanly in a chroot, so I had to
patch setup.py.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
From: Andreas Amann <a.am...@ucc.ie>
When a Subject field contained encoded CRLF sequences, these sequences
would appear unfiltered in the output of notmuch search. This confused
the notmuch emacs interface leading to "Unexpected Output"
messages. This is now fixed by replacin
index 7c81856..0badb1d 100755
--- a/test/json
+++ b/test/json
@@ -18,11 +18,6 @@ test_expect_equal "$output" "[{\"thread\": \"XXX\",
\"subject\": \"json-search-subject\",
\"tags\": [\"inbox\", \"unread\"]}]"
-
index 7c81856..0badb1d 100755
--- a/test/json
+++ b/test/json
@@ -18,11 +18,6 @@ test_expect_equal $output [{\thread\: \XXX\,
\subject\: \json-search-subject\,
\tags\: [\inbox\, \unread\]}]
-test_begin_subtest Search by subject (utf-8):
-add_message [subject]=utf8-sübjéct [date]=\Sat, 01 Jan 2000
From: Andreas Amann a.am...@ucc.ie
When a Subject field contained encoded CRLF sequences, these sequences
would appear unfiltered in the output of notmuch search. This confused
the notmuch emacs interface leading to Unexpected Output
messages. This is now fixed by replacing all characters
On Sat, 14 May 2011 21:37:25 -0400, Austin Clements wrote:
> I wonder if a better approach would be to use
> notmuch_message_get_header everywhere, rather than introducing
> _notmuch_message_get_header_value, and have it simply recognize
> headers that can be retrieved directly from the database.
ave the Xapian API differentiate between
undefined and blank value fields so empty subject lines are encoded as a
single space.
Also, the address completion discussion made me think that maybe a value
field containing To/Cc/Bcc could be added too to avoid message file
parsing for the address search
On Sat, 14 May 2011 21:37:25 -0400, Austin Clements amdra...@mit.edu wrote:
I wonder if a better approach would be to use
notmuch_message_get_header everywhere, rather than introducing
_notmuch_message_get_header_value, and have it simply recognize
headers that can be retrieved directly from
On 12 May 2011 04:39, Istvan Marko wrote:
> Stewart Smith writes:
>
>> Would it be possible to progressively fill the DB with the new data?
>>
>> i.e.
>>
>> if Subject/From not in db for message
>> ? ?add Subject/From for this message to DB.
>
&g
ched message to get the From and Subject headers. I figured
> that this must be slowing things down, especially when the files are not
> in the filesystem cache.
>
> So I wanted to see how much difference would it make to have the From
> and Subject stored in xapian to avoid this pars
message to get the From and Subject headers. I figured
that this must be slowing things down, especially when the files are not
in the filesystem cache.
So I wanted to see how much difference would it make to have the From
and Subject stored in xapian to avoid this parsing.
With the attached
On 12 May 2011 04:39, Istvan Marko notm...@kismala.com wrote:
Stewart Smith stew...@flamingspork.com writes:
Would it be possible to progressively fill the DB with the new data?
i.e.
if Subject/From not in db for message
add Subject/From for this message to DB.
I started looking
Stewart Smith writes:
> Would it be possible to progressively fill the DB with the new data?
>
> i.e.
>
> if Subject/From not in db for message
>add Subject/From for this message to DB.
I started looking into this but then realized that notmuch search opens
the database in
Stewart Smith stew...@flamingspork.com writes:
Would it be possible to progressively fill the DB with the new data?
i.e.
if Subject/From not in db for message
add Subject/From for this message to DB.
I started looking into this but then realized that notmuch search opens
the database
gt; An important thing missing is fallback to the old method for messages
> where the Subject/From VALUE fields don't exist. Otherwise people will
> get blank results until they rebuild their database.
Would it be possible to progressively fill the DB with the new data?
i.e.
if Subje
at least.
An important thing missing is fallback to the old method for messages
where the Subject/From VALUE fields don't exist. Otherwise people will
get blank results until they rebuild their database.
Would it be possible to progressively fill the DB with the new data?
i.e.
if Subject/From
On Sun, 8 May 2011 17:40:54 -0400, Austin Clements wrote:
> Cool. This seems very reasonable.
>
> Just some style nits: The three places where you have
> "sanitize_string(", there should be a space between the function name
> and the paren.
fixed
> Relatedly, "for(;*loop;loop++){" should be
Jameson Graef Rollins writes:
> Unless I hear a strong positive response I'll hold off on considering it
> for 0.6, and suggest instead targeting it for 0.7.
I would say wait until 0.7 at least.
An important thing missing is fallback to the old method for messages
where the Subject/From
On Wed, 4 May 2011 21:48:39 -0400, Austin Clements wrote:
> This is awesome. What was your machine configuration?
Does anyone else have an opinions about this patch? It seems reasonable
to me (other than a couple errant comments that were left in and should
be removed). It seems worth the
On Sun, May 8, 2011 at 5:54 PM, Florian Friesdorf wrote:
> On Sun, 8 May 2011 17:40:54 -0400, Austin Clements
> wrote:
>> Also, existing code conventionally uses a variable named "local"
>> for function-level talloc contexts such as your ctx_quote.
>
> In notmuch-search.c there is no variable
x_quote.
On Sun, May 8, 2011 at 5:14 PM, Florian Friesdorf wrote:
> From: Andreas Amann
>
> When a Subject field contained encoded CRLF sequences, these sequences
> would appear unfiltered in the output of notmuch search. This confused
> the notmuch emacs interface leading to "Unexp
Hey, Florian. I applied this patch to release-candidate/0.6, manually
adding in the formatting fixes in the same patch.
I also applied the test patch, modified to use the add_message test
suite function, which makes the patch a bit simpler.
Thanks for the fixes.
jamie.
-- next part
From: Andreas Amann a.am...@ucc.ie
When a Subject field contained encoded CRLF sequences, these sequences
would appear unfiltered in the output of notmuch search. This confused
the notmuch emacs interface leading to Unexpected Output
messages. This is now fixed by replacing all characters
Friesdorf f...@chaoflow.net wrote:
From: Andreas Amann a.am...@ucc.ie
When a Subject field contained encoded CRLF sequences, these sequences
would appear unfiltered in the output of notmuch search. This confused
the notmuch emacs interface leading to Unexpected Output
messages. This is now fixed
On Sun, 8 May 2011 17:40:54 -0400, Austin Clements amdra...@mit.edu wrote:
Cool. This seems very reasonable.
Just some style nits: The three places where you have
sanitize_string(, there should be a space between the function name
and the paren.
fixed
Relatedly, for(;*loop;loop++){
Hey, Florian. I applied this patch to release-candidate/0.6, manually
adding in the formatting fixes in the same patch.
I also applied the test patch, modified to use the add_message test
suite function, which makes the patch a bit simpler.
Thanks for the fixes.
jamie.
pgpSo56tz6dHL.pgp
On Wed, 4 May 2011 21:48:39 -0400, Austin Clements amdra...@mit.edu wrote:
This is awesome. What was your machine configuration?
Does anyone else have an opinions about this patch? It seems reasonable
to me (other than a couple errant comments that were left in and should
be removed). It
ine.
My test search matches 8800 messages grouped into 5550 threads.
Wit the patch cached results go from 2.5 secs to 1.5, uncached goes from
40 secs to 6.
Thanks for the clue on the missing subject lines, your change does
indeed fix the problem!
--
Istvan
On Wed, May 4, 2011 at 9:48 PM, Austin Clements wrote:
> As another data point, with a probably very different configuration (8
> year old P4, new SSD), my test query was 1.9X faster uncached and 1.6X
> faster cached. ?It also produced 60% fewer disk reads. ?I saw the same
> 1% increase in
are probably the right place to store this information (though
I've never been completely clear on the difference between document
data and values). Terms would be indexed, which is both unnecessary
(unless there's a reason to do *exact* matches on from and subject?)
and would result in more database
are probably the right place to store this information (though
I've never been completely clear on the difference between document
data and values). Terms would be indexed, which is both unnecessary
(unless there's a reason to do *exact* matches on from and subject?)
and would result in more database
On Wed, May 4, 2011 at 9:48 PM, Austin Clements amdra...@mit.edu wrote:
As another data point, with a probably very different configuration (8
year old P4, new SSD), my test query was 1.9X faster uncached and 1.6X
faster cached. It also produced 60% fewer disk reads. I saw the same
1%
I have been looking at the I/O patterns of "notmuch search" with the
default output format and noticed that it has to parse the maildir file
of every matched message to get the From and Subject headers. I figured
that this must be slowing things down, especially when
y CRLF
> that is immediately followed by WSP.
Again, unfolded subjects should be one-liners.
An email was sent to me from pingg.com (I think it's a pretentious
version of evite) came with a subject of
"=?utf-8?Q?bring_small_items_for_a_pi=C3=B1ata=21=21=21=21=0A?=", which
"not
The function notmuch_message_tags_to_maildir_flags() unconditionally
returns NOTMUCH_STATUS_SUCCESS, but it looks like it should probably
return status.
Rob Browning (1):
Return error status from notmuch_message_tags_to_maildir_flags().
lib/message.cc |2 +-
1 files changed, 1
The function notmuch_message_tags_to_maildir_flags() unconditionally
returns NOTMUCH_STATUS_SUCCESS, but it looks like it should probably
return status.
Rob Browning (1):
Return error status from notmuch_message_tags_to_maildir_flags().
lib/message.cc |2 +-
1 files changed, 1
-show.el
@@ -576,6 +576,10 @@ function is used. "
;; Move straight to the first open message
(if (not (notmuch-show-message-visible-p))
(notmuch-show-next-open-message))
+
+;; Set the header line to the subject of the first open message.
+(setq header-line-format (notmuch
-show.el
@@ -576,6 +576,10 @@ function is used.
;; Move straight to the first open message
(if (not (notmuch-show-message-visible-p))
(notmuch-show-next-open-message))
+
+;; Set the header line to the subject of the first open message.
+(setq header-line-format (notmuch-show
On Fri, 05 Nov 2010 10:51:52 -0700, Carl Worth wrote:
> > +(defcustom notmuch-show-elide-same-subject nil
> > + "Do not show the subject of a collapsed message if it is the
> > +same as that of the previous message."
Just for the record. I really think this is an i
On Fri, 5 Nov 2010 09:50:15 +, David Edmondson wrote:
> If `notmuch-show-elide-same-subject' is set to `t' then collapsed
> messages do not show a "Subject:" line if the subject is the same as
> that of the previous message.
Sounds cool. Thanks! (Will test and merge lat
If `notmuch-show-elide-same-subject' is set to `t' then collapsed
messages do not show a "Subject:" line if the subject is the same as
that of the previous message.
---
emacs/notmuch-show.el | 38 --
1 files changed, 28 insertions(+), 10 deletion
If `notmuch-show-elide-same-subject' is set to `t' then collapsed
messages do not show a Subject: line if the subject is the same as
that of the previous message.
---
emacs/notmuch-show.el | 38 --
1 files changed, 28 insertions(+), 10 deletions(-)
diff
Describe new auto-tagging functionality in the NEWS.
---
NEWS | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/NEWS b/NEWS
index b5f3ee3..05ffaca 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,14 @@
+Auto-tagging replied messages
+
+ Add functionality for
On Wed, 14 Apr 2010 17:35:44 -0700, Carl Worth wrote:
> On Tue, 13 Apr 2010 18:37:57 +0200, Gregor Hoffleit
> wrote:
> > The test suite doesn't yet cover --format=json output nor UTF-8 in
> > subject or body.
> >
> > This patch starts with test cases for 'searc
On 2010-04-22, Sebastian Spaeth wrote:
> From: Jesse Rosenthal
This patch must have slipped in the patch series of the 6 other patches
(which are all correct). Please ignore it.
Note to myself, never do "git send-email 00*"
Sebastian
From: Jesse Rosenthal <jrosent...@jhu.edu>
(Embarassing -- this should be the last fix.)
Change the buffer name to a uniquified subject of the thread (i.e. the
subject of the first message in the thread) instead of the thread-id. This
is more meaningful to the user, and will make it
From: Jesse Rosenthal jrosent...@jhu.edu
(Embarassing -- this should be the last fix.)
Change the buffer name to a uniquified subject of the thread (i.e. the
subject of the first message in the thread) instead of the thread-id. This
is more meaningful to the user, and will make it easier
On 2010-04-22, Sebastian Spaeth wrote:
From: Jesse Rosenthal jrosent...@jhu.edu
This patch must have slipped in the patch series of the 6 other patches
(which are all correct). Please ignore it.
Note to myself, never do git send-email 00*
Sebastian
On Wed, 14 Apr 2010 17:35:44 -0700, Carl Worth cwo...@cworth.org wrote:
On Tue, 13 Apr 2010 18:37:57 +0200, Gregor Hoffleit gre...@hoffleit.de
wrote:
The test suite doesn't yet cover --format=json output nor UTF-8 in
subject or body.
This patch starts with test cases for 'search
On Wed, 14 Apr 2010 17:35:44 -0700, Carl Worth wrote:
> [*] I say "should" because I don't believe we have any actual
> specification of the data coming out of the JSON output yet. One other
> thing that seems odd is the name of "date_unix" in the show output and
> "timestamp" in the search
> But you might actually like that change since it's one you requested in
> your first version of the modular test suite. I'm dropping the annoying
> execute_expecting macro that both runs notmuch and tests the
> output. There's now a much cleaner separation such as:
>
> output=$($NOTMUCH
But you might actually like that change since it's one you requested in
your first version of the modular test suite. I'm dropping the annoying
execute_expecting macro that both runs notmuch and tests the
output. There's now a much cleaner separation such as:
output=$($NOTMUCH search
On Thu, 15 Apr 2010 10:33:46 +0200, Michal Sojka wrote:
> are you still interrested in modular test suite from git? If so, could
> you please look at id:87mxxg7bxo.fsf at steelpick.2x.cz and tell me your
> opinion. I'm still updating the modularized tests to match the state in
> master but every
On Thu, 15 Apr 2010, Carl Worth wrote:
> On Tue, 13 Apr 2010 18:37:57 +0200, Gregor Hoffleit
> wrote:
> > The test suite doesn't yet cover --format=json output nor UTF-8 in
> > subject or body.
> >
> > This patch starts with test cases for 'search --format=jso
On Thu, 15 Apr 2010 10:33:46 +0200, Michal Sojka sojk...@fel.cvut.cz wrote:
are you still interrested in modular test suite from git? If so, could
you please look at id:87mxxg7bxo@steelpick.2x.cz and tell me your
opinion. I'm still updating the modularized tests to match the state in
On Tue, 13 Apr 2010 18:37:57 +0200, Gregor Hoffleit
wrote:
> The test suite doesn't yet cover --format=json output nor UTF-8 in
> subject or body.
>
> This patch starts with test cases for 'search --format=json' and
> 'show --format=json'.
Thanks for the tests, Gregor!
I wa
On Tue, 13 Apr 2010 18:37:57 +0200, Gregor Hoffleit gre...@hoffleit.de wrote:
The test suite doesn't yet cover --format=json output nor UTF-8 in
subject or body.
This patch starts with test cases for 'search --format=json' and
'show --format=json'.
Thanks for the tests, Gregor!
I was about
The test suite doesn't yet cover --format=json output nor UTF-8 in
subject or body.
This patch starts with test cases for 'search --format=json' and
'show --format=json'.
Furthermore, it has test cases for a search for a UTF-8 string in a mail
body for a UTF-8 string in a mail subject.
Finally
The test suite doesn't yet cover --format=json output nor UTF-8 in
subject or body.
This patch starts with test cases for 'search --format=json' and
'show --format=json'.
Furthermore, it has test cases for a search for a UTF-8 string in a mail
body for a UTF-8 string in a mail subject.
Finally
On 2010-04-09, Jesse Rosenthal wrote:
> sporadic access. However, one question: it looks like it was V2 of the
> patch that you pushed -- was it? Unfortunately, there was a subtle bug
> that kept on popping up (when you call notmuch-show interactively, which
> rarely happens). Later in this same
On Fri, 09 Apr 2010 10:01:09 -0400, Jesse Rosenthal
wrote:
> Great to hear! Sorry I've been off of email, and still only have
> sporadic access. However, one question: it looks like it was V2 of the
> patch that you pushed -- was it? Unfortunately, there was a subtle bug
> that kept on popping
On Wed, 07 Apr 2010 10:46:01 -0700, Carl Worth wrote:
> A very lovely change, Jesse! Thanks for this (which is now pushed). And
> again, thanks to Sebastian for guiding the patch through the file
> renaming.
Great to hear! Sorry I've been off of email, and still only have
sporadic access.
On Fri, 12 Feb 2010 17:19:23 -0500, Jesse Rosenthal
wrote:
> Change the buffer name to a uniquified subject of the thread (i.e. the
> subject of the first message in the thread) instead of the thread-id. This
> is more meaningful to the user, and will make it easier to scroll through
&
From: Jesse Rosenthal <jrosent...@jhu.edu>
Change the buffer name to a uniquified subject of the thread (i.e. the
subject of the first message in the thread) instead of the thread-id. This
is more meaningful to the user, and will make it easier to scroll through
numerous open buffers.
On Sat, 06 Mar 2010 09:20:21 -0500, Jesse Rosenthal
wrote:
> Change the buffer name to a uniquified subject of the thread (i.e. the
> subject of the first message in the thread) instead of the thread-id. This
> is more meaningful to the user, and will make it easier to scroll through
&
On Sat, 06 Mar 2010 09:20:21 -0500, Jesse Rosenthal jrosent...@jhu.edu wrote:
Change the buffer name to a uniquified subject of the thread (i.e. the
subject of the first message in the thread) instead of the thread-id. This
is more meaningful to the user, and will make it easier to scroll
301 - 400 of 449 matches
Mail list logo
