Gaute Hope writes:
>> A better approach would be to add a new "modtime" xapian value that is
>> updated whenever the tags or any other terms (such as XFDIRENTRY) are
>> added to or deleted from a docid. If it's a Xapian value, rather than a
>> term, then modtime will be queriable just like date,
David Bremner writes:
>> Exactly. It could be a tick, or just the current time of day if your
>> clock does not go backwards. (I'd be willing to do a full scan if the
>> clock ever goes backwards.) The advantage of time is that you don't
>> have to synchronously update some counter.
>
> I thin
Tilmann Singer writes:
> David Mazieres writes:
>> What happens if you get a message that's been stuck in a queue for a few
>> days and has an old Date: header?
>
> It would be missed. I have set the timespan to look backwards for new
> mail to one month to be a bit safer against the stuck-in-q
Austin Clements writes:
>> A middle ground might be to use the maximum of two values: 1) the
>> time-of-day at which notmuch started executing, and 2) the highest ctime
>> in the database plus 100 microseconds (leaving plenty of slop to store
>> timestamps as IEEE doubles with 52 significant bits
Hey, I'm playing around with the head of the git repository
(bc64cdce289d84be2550c4fccb1f008d15eaeb0e) to try to figure out how the
new folder: prefixes work, as folders are a critical part of how I
organize my mail. (Since tags are not hierarchical, folders are the
best way for me to group mail t
Jani Nikula writes:
> On Fri, 02 May 2014, dm-list-email-notm...@scs.stanford.edu wrote:
>>
>> I'm using a pretty standard maildir++ layout. For example, underneath
>> my database.path I have a bunch of mail in directories such as:
>>
>> .INBOX.Main/{new,cur}
>> .mail.class/{new,cur}
>>
Mark Walters writes:
>> All the way back. Now you are saying there will be no convenient way to
>> match just the "mail.class" part without the year? How very
>> distressing. Ugh.
>
> Hi
>
> I am not quite sure what you are meaning by hierarchically group
> messages. Searching for path:dir/foo
Jani Nikula writes:
> It's not going to help you, but I'll mention a few of the issues the old
> folder: search had, which we also had complaints about, and which would
> have been quite hard to fix while preserving the behaviour you want. In
> short, we considered the old folder: search broken.
I've been running into this issue lately where I agree to meet people
and we say it's confirmed, but if don't send them a calendar invite of
mime type text/calendar, then it's as if we never agreed and they don't
show up. I get, "Oh, you never sent me a calendar invite so it wasn't
in my calendar.
Sorry if this question is answered somewhere, but I'm wondering: What
is the best way to enable and disable maildir.synchronize_flags?
It seems that disabling it should simply be safe. But re-enabling, one
risks losing tags, as the next notmuch new will cause old maildir flags
to override the xa
David Bremner writes:
> David Mazieres writes:
>> So my question remains, what's the easiest safe way to re-enable
[ 2 more citation lines. Click/Enter to show. ]
>> synchronize_flags after disabling it? (Safe meaning it won't change any
>> tags.) It could be that there's a very simple answer,
Amadeusz Żołnowski writes:
>> So... based on all the evidence so fare the culprit seems to be that
>> something is moving mail files into your Spam folder on the client.
>> If that rings any bells and solves the problem, great. If not, here
>> is what we need to do to track it down further.
>
>
Amadeusz =C5=BBo=C5=82nowski writes:
> What's more surprising is that there is a test case in notmuch test
> suite which test whether after modifing tag of a mail it is moved from
> new/ to cur/. Yes, it should be moved on any tag modification if I
> understand correctly. But it seems it does not
David Bremner writes:
> Amadeusz Żołnowski writes:
>
>> What's more surprising is that there is a test case in notmuch test
>> suite which test whether after modifing tag of a mail it is moved from
>> new/ to cur/. Yes, it should be moved on any tag modification if I
>> understand correctly. But
One of the features I would like to see from notmuch is an easier
ability to synchronize tags across machines. At the very least, I
would need either incremental dump and restore, or some way to
communicate arbitrary tags to a local imap server that shares
notmuch's maildir (much as notmuch curren
At Tue, 25 Jan 2011 10:08:12 +1030,
Tim Stoakes wrote:
>
> I do something like this by using some shell scripts with formail, to
> 'store' notmuch tags into the X-Label headers of the individual mails.
> Offlineimap then syncs these headers. If I need the tags to become
> notmuch-ified on the targ
David Edmondson writes:
> I haven't seen this. Threads with a lot of complex HTML content (lots of
> nested tables, for example) can take a long time to render for me, but
> that is generally interruptable.
>
> Could you share one of these messages, or a sufficiently similar test
> case?
Thanks
David Edmondson writes:
> This works fine for me, and I get an appropriate character (not just the
> hex box).
>
> According to `describe-char' it's rendered using the Symbola font. Do
> you have that installed? (It's the "font-symbola" package on Debian I
> believe.)
I just installed the ttf-sy
Tomi Ollila writes:
> Emacs versions involved ?
I'm using the latest version with arch linux, namely emacs 27.1-3.
Also, for what it's worth, "fc-list | wc -l" shows 4769 fonts installed
on my system. Could that be too many if emacs does some sort of linear
search for characters?
Thanks,
David
19 matches
Mail list logo
