Re: Search using email headers does not work
I think I mentioned this on irc sometime ago: would indexing all the headers as a separate free text entry (under headers: for example) satisfy most of this. So then you could search for things like headers:"List-Id: blah" or similar. It is not as nice as individually indexed headers, but it does mean that all notmuch instances would be the same and the same commands would work, the library interface would be consistent etc. Best wishes Mark On Tue, 12 Feb 2013, David Bremner wrote: > Carl Worth writes: >> >> It's embarrassing to me that I added this note to the notmuch TODO file >> in October 2009 (and it's still there): >> >> Add support for the user to specify custom headers to be indexed. > > One techicality is that we would presumeably want to support this both > for access via the CLI and via libnotmuch (e.g. for the python > bindings). So there is the question of where to store the list of > indexed headers; perhaps in Xapian metadata. Or is there some simpler > solution? > > d > ___ > notmuch mailing list > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/6] notmuch cli config changes
> Jameson Graef Rollins writes: > >> But don't get me wrong, the CLI is one of the things that makes notmuch >> so incredibly awesome. It's an email swiss army knife that's there when >> you need it. But given that even I often need to look at the man page >> during my occasional CLI usage, I just don't want to see it get to >> overcrowded. > > Well, maybe this should be a discussion about how to organize the CLI > documentation so that more commonly used options are easy to find. That > would indeed be a side effect of making less commonly used options > controlled by environment variables, and documenting the environment > variables at the bottom of the man pages as per tradition. But I don't > think this is the only way or even the best way to achieve good > documentation. I think one of the problems for documentation is that we have two classes of "user" of the cli: one is actually people and one is front ends (and yes scripting does blur the boundary). Would it be worth splitting based on that. For example, the --format-version is really only for front-end use. --format=text is for human use, whereas the other options are mostly front-end (text0 might be an exception) Best wishes Mark ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 0/6] notmuch cli config changes
On Tue, 12 Feb 2013, Jameson Graef Rollins wrote: > But don't get me wrong, the CLI is one of the things that makes notmuch > so incredibly awesome. It's an email swiss army knife that's there when > you need it. But given that even I often need to look at the man page > during my occasional CLI usage, I just don't want to see it get to > overcrowded. Retrospectively, I observe that my series (up to but not including the last patch) might help reduce the clutter in the future by facilitating the move of common options from subcommands to top level. For example, *all* the options to notmuch new would make (more) sense at the top level (--verbose, --debug, --no-hooks) and could be useful in other subcommands. > In any event, I've certainly said more than my peace on this issue. > Jani's series looks good to me (although, ironically, it's missing > documentation updates!). Heh, I just wanted to see what the response was first before putting in the effort to document it. The code comes easy. :) BR, Jani.
notmuch-mutt: Use of uninitialized value.
On Tue, Feb 12, 2013 at 05:55:31PM +0100, Profpatsch wrote: > > Do you still have the mail in question? Can you verify if it is the > > case or not? > > That?s my problem: It works with no mail. > I initialized notmuch and this one works: I'm sorry, but I still don't get it. What do you mean with "no mail"? I've tried using on an empty Maildir (i.e. one without any mail in it), but there doesn't work in the right sense, i.e. mutt complains with "There are no messages" and doesn't even try to run notmuch-mutt. So no bug there. If it does anything different for you, can you please compare the macros you're using with the one you can find at: http://git.notmuchmail.org/git/notmuch/blob/HEAD:/contrib/notmuch-mutt/notmuch-mutt.rc Many thanks in advance for your feedback, Cheers. -- Stefano Zacchiroli . . . . . . . zack at upsilon.cc . . . . o . . . o . o Ma?tre de conf?rences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . ? the first rule of tautology club is the first rule of tautology club ?
Search using email headers does not work
On Tue, Feb 12, 2013 at 09:03:01AM -0800, Jameson Graef Rollins wrote: > On Tue, Feb 12 2013, David Bremner wrote: > > Unfortunately currently headers other than those references in the > > notmuch-search-terms man page are not indexed. The only workaround I > > can think of without patching notmuch is to use some tool to tag the > > messages you care about. > > I think even more importantly headers other than those that are parsed > are actually thrown to /dev/null. They are not even indexed as plain > text, so you can search for terms in headers as you can for words in the > body. > > I asked this on irc but it got lost in the shuffle: would it make sense > to index the entire header block as plain text? If we did that then at > least the search that Michal was trying would return the expected > results. It would also be a fairly simple change to the indexer. I > don't have a good sense of how much it would pollute the index, though. [skipping CC line and sending to list] Hi, I like such idea - but how hard would be to add a config options to extend a list of default headers used for indexing? I am not sure there is a strong need to index every bit from headers, just add few tips to the default list. Regards Michal Vyskocil > > Given how frequently people are asking for alternate header indexing, it > might be something to consider. > > jamie. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20130212/3a736e1a/attachment.pgp>
notmuch-mutt: Use of uninitialized value.
[ many thanks to David Bremner for the forward ] On Tue, 12 Feb 2013 01:58:01 +0100, Profpatsch wrote: > # Construct a thread ouf of the marked mail (or something like that, > # doesn?t work atm (errors out)) > I hope this still works, best to put it on one line I guess. > > Error message: > Use of uninitialized value in pattern match (m//) at > /usr/bin/notmuch-mutt line 124, line 28. > Use of uninitialized value $mid in concatenation (.) or string at > /usr/bin/notmuch-mutt line 145, line 28. Heya, thanks for your report. The only reasonable explanation I can think of is that you hit while being on a mail that does not contain a Message-Id header, which is uncommon. Do you still have the mail in question? Can you verify if it is the case or not? If that's the case, I'd agree that the error message could be better, but without a message-id there won't be much that can be done to rebuild a thread in any reliable way. (One possibility might be falling back to subject-based thread reconstruction, but I'd rather not do that.) Cheers. -- Stefano Zacchiroli . . . . . . . zack at upsilon.cc . . . . o . . . o . o Ma?tre de conf?rences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . ? the first rule of tautology club is the first rule of tautology club ?
Search using email headers does not work
Carl Worth writes: > > It's embarrassing to me that I added this note to the notmuch TODO file > in October 2009 (and it's still there): > > Add support for the user to specify custom headers to be indexed. One techicality is that we would presumeably want to support this both for access via the CLI and via libnotmuch (e.g. for the python bindings). So there is the question of where to store the list of indexed headers; perhaps in Xapian metadata. Or is there some simpler solution? d
[PATCH 0/6] notmuch cli config changes
Jameson Graef Rollins writes: > But don't get me wrong, the CLI is one of the things that makes notmuch > so incredibly awesome. It's an email swiss army knife that's there when > you need it. But given that even I often need to look at the man page > during my occasional CLI usage, I just don't want to see it get to > overcrowded. Well, maybe this should be a discussion about how to organize the CLI documentation so that more commonly used options are easy to find. That would indeed be a side effect of making less commonly used options controlled by environment variables, and documenting the environment variables at the bottom of the man pages as per tradition. But I don't think this is the only way or even the best way to achieve good documentation. d
Re: notmuch-mutt: Use of uninitialized value.
On Tue, Feb 12, 2013 at 05:55:31PM +0100, Profpatsch wrote: > > Do you still have the mail in question? Can you verify if it is the > > case or not? > > That’s my problem: It works with no mail. > I initialized notmuch and this one works: I'm sorry, but I still don't get it. What do you mean with "no mail"? I've tried using on an empty Maildir (i.e. one without any mail in it), but there doesn't work in the right sense, i.e. mutt complains with "There are no messages" and doesn't even try to run notmuch-mutt. So no bug there. If it does anything different for you, can you please compare the macros you're using with the one you can find at: http://git.notmuchmail.org/git/notmuch/blob/HEAD:/contrib/notmuch-mutt/notmuch-mutt.rc Many thanks in advance for your feedback, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/6] notmuch cli config changes
On Tue, 12 Feb 2013, Jameson Graef Rollins wrote: > But don't get me wrong, the CLI is one of the things that makes notmuch > so incredibly awesome. It's an email swiss army knife that's there when > you need it. But given that even I often need to look at the man page > during my occasional CLI usage, I just don't want to see it get to > overcrowded. Retrospectively, I observe that my series (up to but not including the last patch) might help reduce the clutter in the future by facilitating the move of common options from subcommands to top level. For example, *all* the options to notmuch new would make (more) sense at the top level (--verbose, --debug, --no-hooks) and could be useful in other subcommands. > In any event, I've certainly said more than my peace on this issue. > Jani's series looks good to me (although, ironically, it's missing > documentation updates!). Heh, I just wanted to see what the response was first before putting in the effort to document it. The code comes easy. :) BR, Jani. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Search using email headers does not work
Carl Worth writes: > > It's embarrassing to me that I added this note to the notmuch TODO file > in October 2009 (and it's still there): > > Add support for the user to specify custom headers to be indexed. One techicality is that we would presumeably want to support this both for access via the CLI and via libnotmuch (e.g. for the python bindings). So there is the question of where to store the list of indexed headers; perhaps in Xapian metadata. Or is there some simpler solution? d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Search using email headers does not work
Michal Vyskocil writes: > I like such idea - but how hard would be to add a config options to > extend a list of default headers used for indexing? Not hard. Obviously, notmuch is already indexing some headers, (From, Date, To, Subject), and it wouldn't be hard to index more. [*] List-Id has been proposed often enough that it should probably be on by default. Then, there are other, slightly more special-case headers, (like headers added by spam filtering software), that probably would be best added on an opt-in basis based on a configuration option. -Carl [*] The existing set of indexed headers is really just historical accident based on two things: 1. I was originally writing index code to match sup's index building, so I focused on the headers sup indexed. 2. I wrote code to index enough headers to satisfy my use case. It's embarrassing to me that I added this note to the notmuch TODO file in October 2009 (and it's still there): Add support for the user to specify custom headers to be indexed. -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20130212/16b5e35d/attachment.pgp>
Re: Search using email headers does not work
Michal Vyskocil writes: > I like such idea - but how hard would be to add a config options to > extend a list of default headers used for indexing? Not hard. Obviously, notmuch is already indexing some headers, (From, Date, To, Subject), and it wouldn't be hard to index more. [*] List-Id has been proposed often enough that it should probably be on by default. Then, there are other, slightly more special-case headers, (like headers added by spam filtering software), that probably would be best added on an opt-in basis based on a configuration option. -Carl [*] The existing set of indexed headers is really just historical accident based on two things: 1. I was originally writing index code to match sup's index building, so I focused on the headers sup indexed. 2. I wrote code to index enough headers to satisfy my use case. It's embarrassing to me that I added this note to the notmuch TODO file in October 2009 (and it's still there): Add support for the user to specify custom headers to be indexed. -- carl.d.wo...@intel.com pgpXwJ8D_jpcw.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Reply all - issue
Jameson Graef Rollins writes: > Just a thought: what if messages with a given tag (e.g. "new-thread") > were always treated as the source of a new thread? It's a good start. And an approach like that would have the advantage that one could undo a thread-split by just removing the tag. (That's not an explicit thread-join feature, but I don't think anyone has ever asked for that.) > A message with the given tag could just be (re)indexed with any > In-Reply-To/References headers stripped before indexing. It would require a little more than that. Imagine this thread: A: Subject: An original thread ??B: Subject: Thread hijacking is fun (tag:new-thread) ??C: Subject: Re: Thread hijacking is fun In this case, message C is likely to have a References header that mentions both A and B. So the thread stitching logic in notmuch will want to merge threads A and B when indexing C. So special care will have to be taken here as well, (not just when indexing B). And that special care may not be cheap if it requires additional database lookups for each unique thread ID encountered among references of a message. Though, I don't mean to dissuade anyone from thinking this through and coding it up. The relevant code for the pieces I'm referring to starts in _notmuch_database_link_message in lib/database.cc. -Carl -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20130212/69909e58/attachment.pgp>
RE: Reply all - issue
Jameson Graef Rollins writes: > Just a thought: what if messages with a given tag (e.g. "new-thread") > were always treated as the source of a new thread? It's a good start. And an approach like that would have the advantage that one could undo a thread-split by just removing the tag. (That's not an explicit thread-join feature, but I don't think anyone has ever asked for that.) > A message with the given tag could just be (re)indexed with any > In-Reply-To/References headers stripped before indexing. It would require a little more than that. Imagine this thread: A: Subject: An original thread └─B: Subject: Thread hijacking is fun (tag:new-thread) └─C: Subject: Re: Thread hijacking is fun In this case, message C is likely to have a References header that mentions both A and B. So the thread stitching logic in notmuch will want to merge threads A and B when indexing C. So special care will have to be taken here as well, (not just when indexing B). And that special care may not be cheap if it requires additional database lookups for each unique thread ID encountered among references of a message. Though, I don't mean to dissuade anyone from thinking this through and coding it up. The relevant code for the pieces I'm referring to starts in _notmuch_database_link_message in lib/database.cc. -Carl -- carl.d.wo...@intel.com pgptx_atmDvLv.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/6] notmuch cli config changes
Jameson Graef Rollins writes: > But don't get me wrong, the CLI is one of the things that makes notmuch > so incredibly awesome. It's an email swiss army knife that's there when > you need it. But given that even I often need to look at the man page > during my occasional CLI usage, I just don't want to see it get to > overcrowded. Well, maybe this should be a discussion about how to organize the CLI documentation so that more commonly used options are easy to find. That would indeed be a side effect of making less commonly used options controlled by environment variables, and documenting the environment variables at the bottom of the man pages as per tradition. But I don't think this is the only way or even the best way to achieve good documentation. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
proposal, move nmbug from ./contrib to ./devel
On Sun, Feb 10 2013, David Bremner wrote: > I mentioned this again on IRC today, and nobody seemed too upset by the > idea. I propose to move nmbug from the contrib subdirectory to the > devel subdirectory. It seems relatively integral to the notmuch > development process at this point, and at least two of the regular > contributors are helping maintain it. > > I'm not posting this as a patch, because file renames are not very > interesting patches. +1 > > d Tomi
Re: Search using email headers does not work
On Tue, Feb 12, 2013 at 09:03:01AM -0800, Jameson Graef Rollins wrote: > On Tue, Feb 12 2013, David Bremner wrote: > > Unfortunately currently headers other than those references in the > > notmuch-search-terms man page are not indexed. The only workaround I > > can think of without patching notmuch is to use some tool to tag the > > messages you care about. > > I think even more importantly headers other than those that are parsed > are actually thrown to /dev/null. They are not even indexed as plain > text, so you can search for terms in headers as you can for words in the > body. > > I asked this on irc but it got lost in the shuffle: would it make sense > to index the entire header block as plain text? If we did that then at > least the search that Michal was trying would return the expected > results. It would also be a fairly simple change to the indexer. I > don't have a good sense of how much it would pollute the index, though. [skipping CC line and sending to list] Hi, I like such idea - but how hard would be to add a config options to extend a list of default headers used for indexing? I am not sure there is a strong need to index every bit from headers, just add few tips to the default list. Regards Michal Vyskocil > > Given how frequently people are asking for alternate header indexing, it > might be something to consider. > > jamie. signature.asc Description: Digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Search using email headers does not work
On Tue, Feb 12 2013, David Bremner wrote: > Unfortunately currently headers other than those references in the > notmuch-search-terms man page are not indexed. The only workaround I > can think of without patching notmuch is to use some tool to tag the > messages you care about. I think even more importantly headers other than those that are parsed are actually thrown to /dev/null. They are not even indexed as plain text, so you can search for terms in headers as you can for words in the body. I asked this on irc but it got lost in the shuffle: would it make sense to index the entire header block as plain text? If we did that then at least the search that Michal was trying would return the expected results. It would also be a fairly simple change to the indexer. I don't have a good sense of how much it would pollute the index, though. Given how frequently people are asking for alternate header indexing, it might be something to consider. jamie. pgpp3hll8sT9e.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Search using email headers does not work
On Tue, Feb 12 2013, David Bremner wrote: > Unfortunately currently headers other than those references in the > notmuch-search-terms man page are not indexed. The only workaround I > can think of without patching notmuch is to use some tool to tag the > messages you care about. I think even more importantly headers other than those that are parsed are actually thrown to /dev/null. They are not even indexed as plain text, so you can search for terms in headers as you can for words in the body. I asked this on irc but it got lost in the shuffle: would it make sense to index the entire header block as plain text? If we did that then at least the search that Michal was trying would return the expected results. It would also be a fairly simple change to the indexer. I don't have a good sense of how much it would pollute the index, though. Given how frequently people are asking for alternate header indexing, it might be something to consider. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20130212/945071b0/attachment.pgp>
Re: [PATCH 0/6] notmuch cli config changes
On Tue, Feb 12 2013, David Bremner wrote: > I don't know if this last is just an off the cuff remark, or it > highlights a difference of opinion. In my view "normal" users of notmuch > use the CLI frequently. Arguably that means we should take even more > care over the design of the UI, if we can do that doesn't descend too > far into bikeshedding territory. Probably a difference of opinion. Under my guise as "normal user" I hardly ever use the CLI (I'm not counting the emacs UI use of the CLI under the hood). In my developer hat I use it more frequently. But maybe (likely?) all of our users are also developers. Even as a developer, though, most of my CLI usage is scripted at this point. But don't get me wrong, the CLI is one of the things that makes notmuch so incredibly awesome. It's an email swiss army knife that's there when you need it. But given that even I often need to look at the man page during my occasional CLI usage, I just don't want to see it get to overcrowded. In any event, I've certainly said more than my peace on this issue. Jani's series looks good to me (although, ironically, it's missing documentation updates!). jamie. pgpko95PqwPvE.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 0/6] notmuch cli config changes
On Tue, Feb 12 2013, David Bremner wrote: > I don't know if this last is just an off the cuff remark, or it > highlights a difference of opinion. In my view "normal" users of notmuch > use the CLI frequently. Arguably that means we should take even more > care over the design of the UI, if we can do that doesn't descend too > far into bikeshedding territory. Probably a difference of opinion. Under my guise as "normal user" I hardly ever use the CLI (I'm not counting the emacs UI use of the CLI under the hood). In my developer hat I use it more frequently. But maybe (likely?) all of our users are also developers. Even as a developer, though, most of my CLI usage is scripted at this point. But don't get me wrong, the CLI is one of the things that makes notmuch so incredibly awesome. It's an email swiss army knife that's there when you need it. But given that even I often need to look at the man page during my occasional CLI usage, I just don't want to see it get to overcrowded. In any event, I've certainly said more than my peace on this issue. Jani's series looks good to me (although, ironically, it's missing documentation updates!). jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20130212/35375163/attachment.pgp>
Re: notmuch-mutt: Use of uninitialized value.
[ many thanks to David Bremner for the forward ] On Tue, 12 Feb 2013 01:58:01 +0100, Profpatsch wrote: > # Construct a thread ouf of the marked mail (or something like that, > # doesn’t work atm (errors out)) > I hope this still works, best to put it on one line I guess. > > Error message: > Use of uninitialized value in pattern match (m//) at > /usr/bin/notmuch-mutt line 124, line 28. > Use of uninitialized value $mid in concatenation (.) or string at > /usr/bin/notmuch-mutt line 145, line 28. Heya, thanks for your report. The only reasonable explanation I can think of is that you hit while being on a mail that does not contain a Message-Id header, which is uncommon. Do you still have the mail in question? Can you verify if it is the case or not? If that's the case, I'd agree that the error message could be better, but without a message-id there won't be much that can be done to rebuild a thread in any reliable way. (One possibility might be falling back to subject-based thread reconstruction, but I'd rather not do that.) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Search using email headers does not work
Michal Vyskocil writes: > Hi, > > I'd like to search for all emails with a defined email header. According > notmuch-search(1) [1] this should be a trivial. But I got a very limited > results > > $ notmuch count --exclude=false "X-Mailinglist" > 2 Hi Michal; Unfortunately currently headers other than those references in the notmuch-search-terms man page are not indexed. The only workaround I can think of without patching notmuch is to use some tool to tag the messages you care about. d
[PATCH 0/6] notmuch cli config changes
Jameson Graef Rollins writes: > But you're right that I'm making a pretty arbitrary distinction. The > notmuch CLI already includes options to handle output formatting, > etc. that normal users are probably never going to use in their > infrequent use of the CLI. I don't know if this last is just an off the cuff remark, or it highlights a difference of opinion. In my view "normal" users of notmuch use the CLI frequently. Arguably that means we should take even more care over the design of the UI, if we can do that doesn't descend too far into bikeshedding territory. > I just don't want to see notmuch fall into the same UI black hole that > e.g. gpg did. GPG is indeed a cautionary tale. FWIW my biggest gripe with GPG is that on top of the profusion of options, I almost always have to use "with-colons" mode to do what I actually want. I don't know what the lesson there is, other than maximum UI fail. d
Re: Search using email headers does not work
Michal Vyskocil writes: > Hi, > > I'd like to search for all emails with a defined email header. According > notmuch-search(1) [1] this should be a trivial. But I got a very limited > results > > $ notmuch count --exclude=false "X-Mailinglist" > 2 Hi Michal; Unfortunately currently headers other than those references in the notmuch-search-terms man page are not indexed. The only workaround I can think of without patching notmuch is to use some tool to tag the messages you care about. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/6] notmuch cli config changes
Jameson Graef Rollins writes: > But you're right that I'm making a pretty arbitrary distinction. The > notmuch CLI already includes options to handle output formatting, > etc. that normal users are probably never going to use in their > infrequent use of the CLI. I don't know if this last is just an off the cuff remark, or it highlights a difference of opinion. In my view "normal" users of notmuch use the CLI frequently. Arguably that means we should take even more care over the design of the UI, if we can do that doesn't descend too far into bikeshedding territory. > I just don't want to see notmuch fall into the same UI black hole that > e.g. gpg did. GPG is indeed a cautionary tale. FWIW my biggest gripe with GPG is that on top of the profusion of options, I almost always have to use "with-colons" mode to do what I actually want. I don't know what the lesson there is, other than maximum UI fail. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
notmuch-mutt: Use of uninitialized value.
Since I don?t get your bug tracking system (d?oh ;), here is a bug I encountered with notmuch-mutt using this macro I guess was from the ?official? tutorial: # Construct a thread ouf of the marked mail (or something like that, # doesn?t work atm (errors out)) macro index \ "unset wait_key \ /usr/bin/notmuch-mutt thread \ ~/.cache/notmuch/mutt/results/ \ set wait_key" \ "search and reconstruct owning thread (using notmuch)" I hope this still works, best to put it on one line I guess. Error message: Use of uninitialized value in pattern match (m//) at /usr/bin/notmuch-mutt line 124, line 28. Use of uninitialized value $mid in concatenation (.) or string at /usr/bin/notmuch-mutt line 145, line 28. ~Profpatsch -- Proudly written in Mutt with Vim on Archlinux. Q: Why is this email five sentences or less? A: http://five.sentenc.es
