Re: using gpg with notmuch

[David Bremner]

Austin Guest  writes:

> Thanks for being so welcoming and helpful David! Just pushed an update to
> the docs.
>
> (Note: I pushed to a separate branch first
> [aguestuser-fix-emacstips-crypto-section], before realizing the project
> suggests just pushing to master and doing that, so apologies if I cluttered
> up the remote repo!)
>
> /a/

No worries, I deleted the extra branch.

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Message-ID's vs. Resent-Message-ID

[Tomi Ollila]

On Sun, Jan 10 2016, Erik Quaeghebeur  wrote:

> Thanks, Tomi, for your quick response.
>
>> > * If yes, for resent messages
>> > (https://tools.ietf.org/html/rfc2822#section-3.6.6), does notmuch use
>> > (the chronologically last) Resent-Message-ID, or the Message-ID?
>> 
>> the Message-ID
>
> Hmm. Is this a conscious decision, or is the resending case just not
> taken into account?

(most probably just) not taken into account

> What happens if I have both a message and my own copy of it after
> resending it to somebody else? I would like to have a record of whom I
> resent it to, as with forwarded messages (where the forwarded message
> does have a different message id).

Both of the copies are "files" of the same message; i.e.

notmuch search --output=files id: will list both (all)
filenames

> Are the Resent-* headers of the resent message merged into the database
> entry? I guess this last question is more general: with multiple messages
> with the same Message-ID but differences (for whatever reason), how will
> these messages be merged in the database?

Database has fixed set of headers stored per message and (afaik) none
of the Resent-* headers are there (merged or separate).

(One thing to remember (for anyone perhaps planning to do something about
this) is that if we'd use Resent-Message-ID: as message identification 
if it exists, then Message-ID: of the message should act as In-Reply-To:
or References: -header...)

Tomi

> Best,
>
> Erik
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH/RFC 0/3] Maildir custom flags and notmuch tags

[David Bremner]

Igor Almeida  writes:

> Building on Bremner's patch at
> <1411805835-3563-1-git-send-email-da...@tethera.net>, this updates
> 'notmuch new' to tag messages based on lower-case letters in the file
> name.
> I'm testing this with an IMAP server, offlineimap and notmuch,
> and seems to work well enough for my unidirectional use case.
> Eventually I'd like to implement the reverse path, i.e. tagging in
> notmuch and seeing IMAP keywords show up in the server, but that's for
> later.
>
> Comments are very welcome.
>

Sorry about the long silence. I _have_ been thinking about and working
on this. This message summarizes my current thinking/plan.

I'm not very enthusiastic about the about the several places this can
get out of sync

1) config info in .notmuch-config can be out of sync with the "real
config" in the database.  This part is only until the next run of
notmuch new, so it's not so bad.

2) When the interpretation of maildir flags changes, there doesn't seem
to be a sensible way of retagging messages.

Some others have objected to supporting a nonstandard extension used (I
think) only by dovecot. For me this is not so bad, as long as the code
required specifically for this is not too large / intrusive.

So here are the pieces I think we need. 

a) some code in notmuch-new to sync flags a-z to a fixed set of tags
  [1]. This soundspretty much the functionality you have now, although I
  haven't really reviewed that part of the series.

b) some code to update metadata directly from the CLI (notmuch
   config/notmuch tag), probably using something like [2] as a back
   end. This metadata maps the fixed tags like $maildir_flag_k to and
   from some friendly format.

c) The use of xapian field processors to translate e.g. a query
   "tag:my-sensible-thing" into "tag:$maildir_flag_k". Optionally do the
   reverse when returning lists of tags. FieldProcessors are only
   available in Xapian 1.3.x, but apparently 1.3 series is nearing a
   stable release, so it's a sane time to optionally depend on it.
   I guess as a short term hack, this could be done by shell wrappers
   (not something we'd ship, but it might make it usable for you).  

d) code to dump and restore the metadata as part of the normal dump
   files. This is at least in progress [2].

In terms of how these changes relate to other goals

b,d) have strong connects with allowing database level config. Among
 other reasons this will help make bindings users less second class
 citizens
  

  c) has overlap with allowing date fields that are not ranges (among
 other things). At least all the machinery to configure xapian 1.2
 versus 1.3, and the understanding how to use field processors, is
 reusable.

I'd understand perfectly if you prefer to rebase your simpler solution
on top of master, but if you want to keep working on this, then I guess
(a), (b), and (c) are all things you would work on.

Probably (b) needs the library api from [2], which now that I start
typing this epic long message, I could split off from the dump/restore
stuff. In particular managing the config metadata only needs about half
of the LOC; the iterator is only needed for dump, I think.

David

[1]: eventually it might make sense to split the tags that are somehow
automatic from those that represent user choice. We already have this
issue with tag:encrypted and friends.

[2]: id:1452394301-29499-1-git-send-email-da...@tethera.net
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Message-ID's vs. Resent-Message-ID

[Tomi Ollila]

On Sun, Jan 10 2016, Erik Quaeghebeur  wrote:

> Hi,
>
>
> I've become interested in notmuch. After looking at the documentation of
> the Python bindings, I have the following questions:

> * Is it correct that a message's Message-ID used as its unique key in the
> notmuch database?

yes

> * If yes, is it correct that two messages with the same Message-ID, but
> with different contents/other headers, will have only one entry in the
> database?

yes

> * If yes, for resent messages
> (https://tools.ietf.org/html/rfc2822#section-3.6.6), does notmuch use
> (the chronologically last) Resent-Message-ID, or the Message-ID?

the Message-ID

>
>
> Best,

likewise :)

>
> Erik


Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: WIP: add metadata to dump output

[Tomi Ollila]

On Sun, Jan 10 2016, David Bremner  wrote:

> It seems (at least to me) that xapian metadata is the right way store
> certain configuration data, including tag aliases [1] and perhaps some
> non-CLI specific configuration. On the other hand we don't want to
> have things lost if we dump and restore a database. Hence this series,
> which is a start at dumping and restore such config.
>
> The main idea here is that various classes of metadata can be defined
> by using prefixes, in exactly the same way as tags are defined for
> documents. This will hopefully help prevent e.g. config from stomping
> on tag aliases.
>
> The first 6 patches impliment iterators for simple "queries" on
> metadata. They are probably split a bit fine, but that's the way I
> developed them.
>
> The last 3 impliment the printing of metadata in dump output. In order
> to be upwardly compatible, it uses the old dodge of hiding things in
> comments. In fact the comment syntax (# in first column) was never
> well documented; this does mean that the notmuch dump output can be
> tested without breaking the current restore tests. I threw an @ in to
> help autodetection of formats; obviously this is not foolproof. On the
> other hand, I don't know how much people currently rely on comments in
> dump files, since notmuch doesn't generate them.
>
> There's lots of bikes to shed here. Probably the most important bits
> are the library API, the dump output format, and of course the ever
> tricky command line argument names.

Generally this series looks pretty good. IMO this could have gone with
way less separate patches -- It would have made the review easier,
now I had to go back to previous mails just to look context. But,
anyone who disagrees w/ this make David know (in any appropriate 
channel so my opinion does not get too emphasized ;D)

The first thing that came into my mind was this naming of
*_FIRST_CLASS and *_LAST_CLASS in enum values. the naming
is inconsistent in sense that first is first, but last is last + 1.
Unfortunately there is nothing we can do with that as these *_LAST_*
are used in other enums too so we just have to live with it. 

In last in this series there is
+typedef enum dump_includes {
+DUMP_INCLUDE_TAGS=1,
+DUMP_INCLUDE_METADATA=2,
+} dump_include_t;

-- spacing around ' = ' missing -- I did not see other whitespace errors
(not that there might not be those, though, as we know David ;)

One bug I found:

+for (mclass = NOTMUCH_METADATA_FIRST_CLASS; mclass < 
NOTMUCH_METADATA_LAST_CLASS; mclass++) {
+   status = notmuch_database_get_all_metadata (notmuch, 
NOTMUCH_METADATA_CONFIG, );

(mclass should be there). Currently as there is only that one in the enum
there is no problem -- also for the same reason current test can not 
notice this. If this were not fixed, this would be noticed in the future
by that particular test - unless it is changed erronelously ;)


Anyway, good stuff in general...


Tomi

> Getting the memory ownership semantics is tricky, especially with the
> mix of C++ objects and talloc. So I'd appreciate a critical eye on
> those bits of metadata.cc.

uh puh -- maybe I look that again (hmm, have to apply the patch series as
all of the metadata.cc is not in one patch ;/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: using gpg with notmuch

[David Bremner]

Austin Guest  writes:

> Hi there. Bit of a n00b to notmuch and having some problems using it
> alongside gnupg to decrypt emails in Emacs.
>
> I'm running Emacs 24.5.1 on Ubuntu 15.10 (x86_64) with notmuch v 0.20.2 and
> the emacs notmuch package 20160108.432 from melpa (but have had identical
> results with v 0.21 from melpa-stable).

The emacs frontend for notmuch ships with the C source. You should use
matching versions. Other versions _might_ work, but are not guaranteed
to. MELPA is kindof unuseful for things like notmuch that need C
libraries; it's easy to get badly out of sync.

On the other hand, the problem you mention sounds unrelated...

> Following the instructions on the emacstips page
> , I'm inserting
> `(notmuch-crypto-process-mime t)` into my `init.el` file -- after
> successfully running `(require `notmuch)`. I get the error
>
> Symbol's function definition is void: notmuch-crypto-process-mime

I think you want (setq notmuch-crypto-process-mime t); it's a variable,
not a function.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: using gpg with notmuch

[Austin Guest]

Thank you David!

Using `setq` cleared things up. Should have caught that. Is there any way
to contribute a patch to the docs (which omit `setq`) to help other n00bs
along the way avoid the same pitfall?

Also: I'd like to get version parity between my version of notmuch and my
version of notmuch-emacs, but am not quite sure how to build form source as
you suggest. (Tried poking around the docs and couldn't turn anything up.)
Any pointers?

When you say the frontend "ships with the C source" what does that mean? Or
perhaps more to the point: how can I find and use the C source to build the
binary? Once built, how can I make sure the new version is what I run from
Emacs since I'm currently running the version from Melpa, etc...?

Thank you in advance for your patience. I really appreciate the help! Not
to mention the fantastic program! :)

/a/


On Sun, Jan 10, 2016 at 4:31 PM, David Bremner  wrote:

> Austin Guest  writes:
>
> > Hi there. Bit of a n00b to notmuch and having some problems using it
> > alongside gnupg to decrypt emails in Emacs.
> >
> > I'm running Emacs 24.5.1 on Ubuntu 15.10 (x86_64) with notmuch v 0.20.2
> and
> > the emacs notmuch package 20160108.432 from melpa (but have had identical
> > results with v 0.21 from melpa-stable).
>
> The emacs frontend for notmuch ships with the C source. You should use
> matching versions. Other versions _might_ work, but are not guaranteed
> to. MELPA is kindof unuseful for things like notmuch that need C
> libraries; it's easy to get badly out of sync.
>
>
Will try building from source. Any pointers

Is there a way to contribute a patch to the docs?


> On the other hand, the problem you mention sounds unrelated...
>
> > Following the instructions on the emacstips page
> > , I'm inserting
> > `(notmuch-crypto-process-mime t)` into my `init.el` file -- after
> > successfully running `(require `notmuch)`. I get the error
> >
> > Symbol's function definition is void: notmuch-crypto-process-mime
>
> I think you want (setq notmuch-crypto-process-mime t); it's a variable,
> not a function.
>



-- 
Austin Guest
guest.aus...@gmail.com
@aguestuser 
831-917-6400
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Message-ID's vs. Resent-Message-ID

[Erik Quaeghebeur]

Thanks, Tomi, for your quick response.

> > * If yes, for resent messages
> > (https://tools.ietf.org/html/rfc2822#section-3.6.6), does notmuch use
> > (the chronologically last) Resent-Message-ID, or the Message-ID?
> 
> the Message-ID

Hmm. Is this a conscious decision, or is the resending case just not taken into 
account?

What happens if I have both a message and my own copy of it after resending it 
to somebody else? I would like to have a record of whom I resent it to, as with 
forwarded messages (where the forwarded message does have a different message 
id). 

Are the Resent-* headers of the resent message merged into the database entry? 
I guess this last question is more general: with multiple messages with the 
same Message-ID but differences (for whatever reason), how will these messages 
be merged in the database?


Best,

Erik
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

using gpg with notmuch

[Austin Guest]

Hi there. Bit of a n00b to notmuch and having some problems using it
alongside gnupg to decrypt emails in Emacs.

I'm running Emacs 24.5.1 on Ubuntu 15.10 (x86_64) with notmuch v 0.20.2 and
the emacs notmuch package 20160108.432 from melpa (but have had identical
results with v 0.21 from melpa-stable).

Following the instructions on the emacstips page
, I'm inserting
`(notmuch-crypto-process-mime t)` into my `init.el` file -- after
successfully running `(require `notmuch)`. I get the error

Symbol's function definition is void: notmuch-crypto-process-mime

Have searched around a bit and not been able to turn up any fixes. Does
anyone have any pointers as to how I could troubleshoot and/or links to any
step-by-step tutorials for getting this setup?

Thanks in advance,

Austin
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: using gpg with notmuch

[David Bremner]

Austin Guest  writes:

> Thank you David!
>
> Using `setq` cleared things up. Should have caught that. Is there any way
> to contribute a patch to the docs (which omit `setq`) to help other n00bs
> along the way avoid the same pitfall?

Ah, I see there is a typo on that page. It would be great if you could
fix it.

You can find instructions for editing the wiki here:

https://notmuchmail.org/wikiwriteaccess/


> When you say the frontend "ships with the C source" what does that mean? Or
> perhaps more to the point: how can I find and use the C source to build the
> binary? Once built, how can I make sure the new version is what I run from
> Emacs since I'm currently running the version from Melpa, etc...?

download the source from

https://notmuchmail.org/releases/LATEST-notmuch-0.21.tar.gz

unpack that, and there is a file called INSTALL with instructions on how
to build and install.

You can find the versions by typing 'v' in the notmuch-hello buffer.

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: using gpg with notmuch

[Austin Guest]

Thanks for being so welcoming and helpful David! Just pushed an update to
the docs.

(Note: I pushed to a separate branch first
[aguestuser-fix-emacstips-crypto-section], before realizing the project
suggests just pushing to master and doing that, so apologies if I cluttered
up the remote repo!)

/a/

On Sun, Jan 10, 2016 at 5:48 PM David Bremner  wrote:

> Austin Guest  writes:
>
> > Thank you David!
> >
> > Using `setq` cleared things up. Should have caught that. Is there any way
> > to contribute a patch to the docs (which omit `setq`) to help other n00bs
> > along the way avoid the same pitfall?
>
> Ah, I see there is a typo on that page. It would be great if you could
> fix it.
>
> You can find instructions for editing the wiki here:
>
> https://notmuchmail.org/wikiwriteaccess/
>
>
> > When you say the frontend "ships with the C source" what does that mean?
> Or
> > perhaps more to the point: how can I find and use the C source to build
> the
> > binary? Once built, how can I make sure the new version is what I run
> from
> > Emacs since I'm currently running the version from Melpa, etc...?
>
> download the source from
>
> https://notmuchmail.org/releases/LATEST-notmuch-0.21.tar.gz
>
> unpack that, and there is a file called INSTALL with instructions on how
> to build and install.
>
> You can find the versions by typing 'v' in the notmuch-hello buffer.
>
> d
>
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch