Re: Notmuch Emacs: tab completion for tags in Fcc:

2017-12-21 Thread Tomas Nordin
Alex Abdo  writes:

> dkg explained my thinking accurately. I don’t personally use the Fcc header 
> routinely to change where sent mail is stored, but I do frequently use it to 
> tag outgoing mail. And yes, you can add “+sent -inbox” to the header. I set 
> my Fcc header by default to include “-inbox -unread”, but when adding other 
> tags, it would be nice to be able to take advantage of tab completion.

Ok, I understand now. I never knew about that feature, now I might start
using it, the tagging that is. And yes, then tab completion could be
nice.

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


Re: Notmuch Emacs: tab completion for tags in Fcc:

2017-12-21 Thread Alex Abdo
On 21 Dec 2017, at 16:20, Tomas Nordin wrote:

> I think that was also my understanding and took the risk of not
> answering the right question. I just didn't think it is common to store
> copies of sent mails in different places, but why not?
>
> The tagging feature here is news for me, I have that done by running a
> postsynchook script from offlineimap, (adding a sent tag I mean). So it
> means I could have "kth/Sent +sent -inbox" as string for example?

dkg explained my thinking accurately. I don’t personally use the Fcc header 
routinely to change where sent mail is stored, but I do frequently use it to 
tag outgoing mail. And yes, you can add “+sent -inbox” to the header. I set my 
Fcc header by default to include “-inbox -unread”, but when adding other tags, 
it would be nice to be able to take advantage of tab completion.



signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Notmuch Emacs: tab completion for tags in Fcc:

2017-12-21 Thread Tomas Nordin
Daniel Kahn Gillmor  writes:

> On Thu 2017-12-21 15:07:32 +0100, Tomas Nordin wrote:
>> Alex Abdo  writes:
>>> One small suggestion for Notmuch Emacs: it would be nice if there were 
>>> tab completion for tags (and, if possible, folders) in the Fcc header 
>>> when composing messages in Emacs.
>>>
>>> There is already tab completion for tags in a number of other places, 
>>> but for some reason, there isn’t tab completion in the Fcc header.
>>
>> The reason is maybe that this place don't often vary much. But there is
>> a configuration variable for this, notmuch-fcc-dirs, which see. Put
>> point in the beginning of the variable name here and say C-h v.
>>
>> I have it set like this:
>>
>> (setq notmuch-fcc-dirs
>>   '(("tomasn@kth\\.se" . "kth/Sent")
>> ("tom\\(asn\\|nor\\)@posteo\\.\\(net\\|de\\)" . "posteo/Sent")))
>>
>> A list of (regex . folder), and depending on the address I am sending
>> from I get a copy in the specified folder. I would probably find it
>> annoying if I had to write it each time, even with tab completion.
>
> I don't think Alex is asking about tab completion of nomtuch-fcc-dirs
> itself -- he's talking about tab completion during message composition
> of the Fcc: header line.
>
> So that would be the equivalent of tab-completing "kth/Sent" or
> "posteo/Sent" in your examples above, and including in that tab
> completion values from the set of known tags if the user is tabbing
> after having entered a "+" or "-" symbol.

I think that was also my understanding and took the risk of not
answering the right question. I just didn't think it is common to store
copies of sent mails in different places, but why not?

The tagging feature here is news for me, I have that done by running a
postsynchook script from offlineimap, (adding a sent tag I mean). So it
means I could have "kth/Sent +sent -inbox" as string for example?
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Notmuch Emacs: tab completion for tags in Fcc:

2017-12-21 Thread Daniel Kahn Gillmor
On Thu 2017-12-21 15:07:32 +0100, Tomas Nordin wrote:
> Alex Abdo  writes:
>> One small suggestion for Notmuch Emacs: it would be nice if there were 
>> tab completion for tags (and, if possible, folders) in the Fcc header 
>> when composing messages in Emacs.
>>
>> There is already tab completion for tags in a number of other places, 
>> but for some reason, there isn’t tab completion in the Fcc header.
>
> The reason is maybe that this place don't often vary much. But there is
> a configuration variable for this, notmuch-fcc-dirs, which see. Put
> point in the beginning of the variable name here and say C-h v.
>
> I have it set like this:
>
> (setq notmuch-fcc-dirs
>   '(("tomasn@kth\\.se" . "kth/Sent")
> ("tom\\(asn\\|nor\\)@posteo\\.\\(net\\|de\\)" . "posteo/Sent")))
>
> A list of (regex . folder), and depending on the address I am sending
> from I get a copy in the specified folder. I would probably find it
> annoying if I had to write it each time, even with tab completion.

I don't think Alex is asking about tab completion of nomtuch-fcc-dirs
itself -- he's talking about tab completion during message composition
of the Fcc: header line.

So that would be the equivalent of tab-completing "kth/Sent" or
"posteo/Sent" in your examples above, and including in that tab
completion values from the set of known tags if the user is tabbing
after having entered a "+" or "-" symbol.

Alex, please correct me if i've confused anything about your feature
request.

   --dkg


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Update on python-cffi bindings

2017-12-21 Thread Daniel Kahn Gillmor
On Thu 2017-12-21 12:30:39 +0100, Floris Bruynooghe wrote:
> The API changes a lot and there is no easy migration.  And history has
> shown that's a terrible way to get something new adopted.  Last time I
> suggested a possible multi-tiered approach (maybe not as explicit):
>
> 1 I think it's possible to move the memory management technique to the
>   existing API without API breakage.  It would still allow users to call
>   functions in the wrong order etc, but that's not any regression.
>
> 2 It's probably possible to either switch the existing API to use CFFI
>   or create a drop-in replacement for it based on CFFI.  The benefit
>   here is two-fold: users get better PyPy performance and I believe it
>   becomes easier to maintain the bindings, e.g. all you need to do to
>   call notmuch_database_get_path is
>   capi.ffi.string(capi.lib.notmuch_database_get_path(dbptr)) (see
>   
> https://github.com/flub/notmuch/blob/cffi/bindings/python-cffi/notdb/_database.py#L263)
>   for an actual example).  But this really depends on what everyone else
>   here that maintains the Python bindings here thinks.  I'd encourage to
>   have a look at the CFFI implementation to get an idea of this.

these two steps on their own seem like they give us:

  * better and safer memory management

  * better performance on PyPy

  * arguably, easier maintenance of the bindings.

These seem like unambiguous wins, and there is no downside -- people
using the notmuch module can just upgrade to the new version and it's
done.  I'd love to see these changes happen.

The only thing it doesn't do is provide more idiomatic bindings for new
users, which you describe as:

> 3 As last step I still think providing the more idiomatic bindings is
>   useful, especially for new users.  It does take the burden of
>   correctly calling the C functions somewhat more.  This could then
>   either treat a notmuch_cffi as a lower level API which more directly
>   maps the C API or it could call C directly as it does now.  I'm not
>   currently sure on which is more feasible or better here.
>
>   An additional thing that could be done here to ease migration is to
>   allow creating the new objects from the old ones allowing a codebase
>   to gradually adopt the newer API where appropriate.  E.g.:
>
>  db = notmuch.Database(...)
>  msg = db.find_message(...)
>  new_db = notdb.Database.from_notmuch(db)
>  new_msg = notdb.Message.from_notmuch(msg)
>  print('Tags not on msg: {}'.format(new_db.tags - new_msg.tags))
>
>   This would rely on the existing API to migrate to CFFI, otherwise it
>   could still be possible but would be very hairy.

I'm not sure i understand this last sentence.  Are you saying that step
3 depends on step 2 happening?

I'm not sure about the name "notdb" but i don't mind the idea of there
being some other "more-pythonic" notmuch bindings.  New users would
likely prefer it, and that'd be fine.

> - For exposing completely new APIs, sure building the
>   notdb.ImmutableTagSet and MutableTagSet was not straight forward,
>   likewise for the PropertiesMap.  Many other things are much easier
>   though.  One possible nice way to alleviate this with the idea of the
>   existing notmuch API being the lower-level layer nearly mimicking the
>   C-API directly.  That way adding new APIs there is more or less
>   straight forward and there is less time pressure to add them to the
>   higher level API.  Especially if mixing the APIs is supported.

I think this is in line with the approach described above.  I like it.

> I must admit I didn't look too much at the existing tests untill just
> now.  If I understand correctly the existing tests are in
> T390-python.sh.  In this case I'd say the tests I added are a lot more
> thorough.  The reason I added tox.ini is to easily test against multiple
> python versions, i.e. CPython 3.5, 3.6 & PyPy 3.5.  If I had to guess at
> the best way to integrate I'd say it's probably best to create a
> TXXX-python-pytest-pyXY.sh for each supported python version and lose
> tox.ini.  I'd suggest for those tests to be a simplified version of what
> tox does: create a virtualenv and run pytest inside of it.

I personally would rather not deal with virtualenvs during development
if we don't need them.

Take a look at test_python() in test/test-lib.sh to see how the python
tests are currently handled -- it's pretty simple, relies on the
configured version of notmuch for testing, and it would be great to keep
the simplicity.

I think the approach you've outlined above sounds really good, and i
would be happy to see it happen for notmuch.  It strikes me as much more
useful and less scary than a hard cutover or overhaul that requires
adoption of a new API from the ground up.

Thanks for continuing to push on this, Floris!

 --dkg


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org

Re: Notmuch Emacs: tab completion for tags in Fcc:

2017-12-21 Thread Tomas Nordin
Alex Abdo  writes:

> All,
>
> One small suggestion for Notmuch Emacs: it would be nice if there were 
> tab completion for tags (and, if possible, folders) in the Fcc header 
> when composing messages in Emacs.
>
> There is already tab completion for tags in a number of other places, 
> but for some reason, there isn’t tab completion in the Fcc header.

The reason is maybe that this place don't often vary much. But there is
a configuration variable for this, notmuch-fcc-dirs, which see. Put
point in the beginning of the variable name here and say C-h v.

I have it set like this:

(setq notmuch-fcc-dirs
  '(("tomasn@kth\\.se" . "kth/Sent")
("tom\\(asn\\|nor\\)@posteo\\.\\(net\\|de\\)" . "posteo/Sent")))

A list of (regex . folder), and depending on the address I am sending
from I get a copy in the specified folder. I would probably find it
annoying if I had to write it each time, even with tab completion.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] lib: return "" rather than NULL from notmuch_thread_get_authors

2017-12-21 Thread David Bremner
Tomi Ollila  writes:

> On Thu, Dec 14 2017, David Bremner wrote:
>
>> The current beheviour is at best underdocumented. The modified test in
>
> Typo in commit message ;), otherwise looks reasonable to me
>

spill chucked and pished,

d

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


Re: [PATCH] test: final named query test works regardless of Xapian FieldProcessor

2017-12-21 Thread David Bremner
Daniel Kahn Gillmor  writes:

> This test passes with older versions of Xapian as well, because
> neither query returns any results.
>
> This should resolve the travis build failure at
> https://travis-ci.org/notmuch/notmuch/builds/318571658
>
> Signed-off-by: Daniel Kahn Gillmor 

pushed to master.

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


Re: Update on python-cffi bindings

2017-12-21 Thread Floris Bruynooghe
Daniel Kahn Gillmor  writes:

> Hi Floris--
>
> On Sun 2017-12-17 19:08:18 +0100, Floris Bruynooghe wrote:
>
> i've heard reported, and i also appreciate your attention to performance
> concerns on different python platforms (e.g. making sure things are
> performant on both CPython and PyPy).

Oh btw, I can happily report this has paid off.  These bindings perform
much better on PyPy while performing slightly worse on CPython.  I
haven't proven this but my guess is most of the performance loss on
CPython is due to the memory management which unfortunately involves a
lot of calls on each object destruction, also each object needs to be
destroyed individually so when destroying a parent all children will get
destroyed first which is a waste from libnotmuch's point of view.  This
can be improved on by using a weakref.finalizer-modeled approach, but
is some more work.

> I confess that i haven't read the series in full, but i have two main
> concerns that i'd generally use to evaluate proposals like this:
>
>  0) how much does the API change?  that is, if we're expecting existing
> users of the notmuch python bindings to adopt this new approach, how
> much pain are we putting them through?  How much of an effort has
> been made to reduce that pain, and do we have a clear and
> comprehensive porting guide?

The API changes a lot and there is no easy migration.  And history has
shown that's a terrible way to get something new adopted.  Last time I
suggested a possible multi-tiered approach (maybe not as explicit):

1 I think it's possible to move the memory management technique to the
  existing API without API breakage.  It would still allow users to call
  functions in the wrong order etc, but that's not any regression.

2 It's probably possible to either switch the existing API to use CFFI
  or create a drop-in replacement for it based on CFFI.  The benefit
  here is two-fold: users get better PyPy performance and I believe it
  becomes easier to maintain the bindings, e.g. all you need to do to
  call notmuch_database_get_path is
  capi.ffi.string(capi.lib.notmuch_database_get_path(dbptr)) (see
  
https://github.com/flub/notmuch/blob/cffi/bindings/python-cffi/notdb/_database.py#L263)
  for an actual example).  But this really depends on what everyone else
  here that maintains the Python bindings here thinks.  I'd encourage to
  have a look at the CFFI implementation to get an idea of this.

3 As last step I still think providing the more idiomatic bindings is
  useful, especially for new users.  It does take the burden of
  correctly calling the C functions somewhat more.  This could then
  either treat a notmuch_cffi as a lower level API which more directly
  maps the C API or it could call C directly as it does now.  I'm not
  currently sure on which is more feasible or better here.

  An additional thing that could be done here to ease migration is to
  allow creating the new objects from the old ones allowing a codebase
  to gradually adopt the newer API where appropriate.  E.g.:

 db = notmuch.Database(...)
 msg = db.find_message(...)
 new_db = notdb.Database.from_notmuch(db)
 new_msg = notdb.Message.from_notmuch(msg)
 print('Tags not on msg: {}'.format(new_db.tags - new_msg.tags))

  This would rely on the existing API to migrate to CFFI, otherwise it
  could still be possible but would be very hairy.

So do people reckon following this path would be more desirable and
worth the extra effort?  Would there be a willingness to change the
exising notmuch API to a CFFI implementation?  I didn't go down this
path yet as last time there was no feedback on this suggestion while
there was some moderate curiosity for a more idiomatic API.

>  1) how accessible is the new implementation for contributions from
> other developers?  For example, a transition to a highly idiomatic
> style of python that no other developers would be able to improve
> would put a large maintenance burden on you.

- For the CFFI-part I believe this is easier then the existing ctypes as
  I tried to say above.

- For exposing completely new APIs, sure building the
  notdb.ImmutableTagSet and MutableTagSet was not straight forward,
  likewise for the PropertiesMap.  Many other things are much easier
  though.  One possible nice way to alleviate this with the idea of the
  existing notmuch API being the lower-level layer nearly mimicking the
  C-API directly.  That way adding new APIs there is more or less
  straight forward and there is less time pressure to add them to the
  higher level API.  Especially if mixing the APIs is supported.


> Do you have any thoughts about these questions?
>
> For example, for point 0, have you tried to run alot or some other
> python-based notmuch MUA against this newer python binding?  what
> changes were necessary?
>
> For example, for point 1, can you show me how i would (as a fellow notmuch
> contributor) create a patch to add