Re: newbie questions about notmuch.el
Tom Hirschowitz writes:
> I think Julien meant the 'flagged' tag: just press the space bar to
> switch it on and off.
>
> Regarding the second question, you may filter your search (e.g., by the
> 'flagged' tag) and then tag all messages by pressing *. IIRC there is no
> shortcut for filtering by default. I have this
>
> (define-key notmuch-show-mode-map (kbd "l") 'notmuch-search-filter)
> (define-key notmuch-search-mode-map (kbd "l") 'notmuch-search-filter)
> (define-key notmuch-tree-mode-map (kbd "l") 'notmuch-search-filter)
notmuch-search-filter doesn't seem to work in tree mode: I get
--8<---cut here---start->8---
(void-variable notmuch-search-query-string)
notmuch-search-filter-by-tag("+unread")
--8<---cut here---end--->8---
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [Łukasz Stelmach] Bug#864493: notmuch: bash completion eats typed option
On Thu 2017-08-31 10:50:57 -0300, David Bremner wrote: > This eventually turned out to be a bug in the "npm" debian package, > since fixed upstream there. only if you actually purge npm itself :( on a system where npm is in the "config-files" state, it's entirely possible that the old/bad npm tab completion remains: ~$ dpkg -l npm Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= rc npm1.4.21+ds-2 all package manager for Node.js ~$ dpkg -L npm /etc /etc/bash_completion.d /etc/bash_completion.d/npm ~$ For those (like me) who had this problem, this is fixed with: apt purge npm thanks for tracking it down and mentioning the cause here! --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: newbie questions about notmuch.el
I think Julien meant the 'flagged' tag: just press the space bar to switch it on and off. Regarding the second question, you may filter your search (e.g., by the 'flagged' tag) and then tag all messages by pressing *. IIRC there is no shortcut for filtering by default. I have this (define-key notmuch-show-mode-map (kbd "l") 'notmuch-search-filter) (define-key notmuch-search-mode-map (kbd "l") 'notmuch-search-filter) (define-key notmuch-tree-mode-map (kbd "l") 'notmuch-search-filter) somewhere in my emacs files, but perhaps there is a cleaner way. > On Tue, Sep 5, 2017 at 1:03 PM, Julien Cubizolles > wrote: >> I'm using notmuch.el in emacs. In a notmuch search buffer, how can I: > > In general, hit '?' to get a help page for the Notmuch buffer you're in. > >> + set or remove the flag mark on a given message > > What is the flag mark? There is no "mark" feature. > > In the search buffer, you can only operate on threads, not messages. > Hit '+' or '-' to tag/untag the highlighted thread. > > In the tree view (try 'z') you can also operate on messages. '+' and > '-' work there too. > >> + select several messages to add, for instance, the same tag > > In the search buffer, select a region of threads to tag, and hit '+' or '-'. > > BR, > Jani. > ___ > notmuch mailing list > notmuch@notmuchmail.org > https://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/3] sorting: add the ability to sort by from and subject
David Bremner writes: > It seems worth mentioning that it's possible to preprocess values into > keys (see Xapian::Enquire::set_sort_by_key). So things like Re: > etc... could be stripped. Hmm looks like I need to create a KeyMaker class which appears to be a glorified (Xapian::Document -> String) callback. Shouldn't be too difficult other than the choice of algorithm. It would have to strip: Re: Fwd: ... etc? Sounds like the choice algorithm could be tricky and/or error prone? Would need lots of tests, and like Jani said, questionable worth in these scenarios, considering I was mainly dealing with scenarios like these: From: Top News - MIT Technology Review From: Newest questions tagged haskell - Stack Overflow So the current implementation would only be useful for RSS feeds, automated bots, etc. that are non-mailing-list-email use cases. I'm working on updates to notmuch-mode right now. I'll post a patch for that soon for people who are interested. - William ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] WIP: add thread subqueries.
Gaute Hope writes:
> David Bremner writes on august 21, 2017 3:35:
>> David Bremner writes:
>>
>>
>>> If you're interested in this feature, please test, let me know if it's
>>> workable for your use case. The syntax here is thread:{$query}. The
>>> usual caveats about whitespace apply. The running example is
>>>
>>> thread:{from:me} and thread:{from:jian} and not thread:{from:dave}
>>>
>>
>> I was playing around with this, and
>>
>> 'thread:"{from:bremner and date:2017}"' and thread:{from:sitaram}
>>
>> is about 10x faster than without the date restriction. This is roughly
>> proportional to the number of threads matching the first subquery.
>> Unfortunately the date restriction needs to be inside the subquery with
>> the current design.
>
> So just to clarify; to make true full thread searches there cannot be
> more than one term in each thread:{} query? Otherwise, all terms in
> each thread: query must be found in at least one message at the same
> time. So you could put the date: restriction in a separate thread:{},
> but it would be slower?
I think your interpretation is correct. I would further emphasise the
following:
- contrary to usual intuition with notmuch/xapian every extra
thread:{} term will slow things down
- having the date restriction in a seperate thread:{} term would ask
for threads with at least one message in that date range
- there might be many such threads; e.g. I have 34178 threads from
2016
d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] WIP: add thread subqueries.
David Bremner writes on august 21, 2017 3:35:
David Bremner writes:
If you're interested in this feature, please test, let me know if it's
workable for your use case. The syntax here is thread:{$query}. The
usual caveats about whitespace apply. The running example is
thread:{from:me} and thread:{from:jian} and not thread:{from:dave}
I was playing around with this, and
'thread:"{from:bremner and date:2017}"' and thread:{from:sitaram}
is about 10x faster than without the date restriction. This is roughly
proportional to the number of threads matching the first subquery.
Unfortunately the date restriction needs to be inside the subquery with
the current design.
So just to clarify; to make true full thread searches there cannot be more than
one term in each thread:{} query? Otherwise, all terms in each thread: query
must be found in at least one message at the same time. So you could put the
date: restriction in a separate thread:{}, but it would be slower?
-gaute
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: newbie questions about notmuch.el
Julien Cubizolles writes: > Thanks for these answers. > >>> I think Julien meant the 'flagged' tag: just press the space bar to >>> switch it on and off. I just noticed that k f also adds the 'flagged' tag. Julien. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: newbie questions about notmuch.el
Thanks for these answers. >> I think Julien meant the 'flagged' tag: just press the space bar to >> switch it on and off. > I don't know what you have configured, but the default is: > > c-h k SPC > "SPC runs the command notmuch-search-scroll-up" That's what I have too. But from your message, I realized that I only have to do +flagged :-) Tom, do you have a function defined for this ? >> Regarding the second question, you may filter your search (e.g., by the >> 'flagged' tag) and then tag all messages by pressing *. IIRC there is no >> shortcut for filtering by default. I have this > > 'l' to filter by query, 't' to filter by tag. Works for me. I was looking for something like the "process-mark" in Gnus but filtering is fine. Julien. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2] emacs: maildir fcc make insert more flexible
David Edmondson writes: > On Monday, 2017-08-28 at 12:27:03 +0100, Mark Walters wrote: > The fcc-header should be of the form \"folder +tag1 -tag2\" where >>> >>> I realise that this patch set didn't add this string, but it is mildly >>> ridiculous. There's no reason that we couldn't use a list, where a >>> leading “+” or “-” indicates a tag and anything else is a folder. >>> >>> Even two variables (one for folder and another for tags) would be an >>> improvement >> >> The reason for this choice is that, when writing the postpone code, I >> wanted to keep within the message mode compose world, which has the fcc >> header as a string. > > You could add whatever headers you like. > >> I think I would also only like to be queried once when inserting. Or are >> you suggesting that the user types in a lisp list? > > If we prompt for it then we could do multiple prompts - we already have > a completion-capable reader for tags. > There was in fact a request for this feature in id:87shgtgiux.fsf@len. OTOH, it seems like a lot of this discussion talks about enhancing or re-factoring the existing draft/fcc handling. Would it be possible to seperate that out, even if it means a list of pre-requisite changes before this feature is added? d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
