Re: unifying and automating draft ("postpone/resume") behavior [was: Re: notmuch "lost" email during power failure]
On Wed 2019-11-13 10:19:05 -0500, Antoine Beaupré wrote: > Fundamentally, I think message-mode should treat emails the same way > epg.el treats encrypted files: the data in the buffer isn't the same as > the on-disk data, and there should be translation between the two. At > the very least, the on-disk data could be a properly formed email > message. If it's marked as needing encryption, then it should be > encrypted. i think it might be easier for notmuch-emacs to override message-mode entirely, than to try to convince message-mode to do something so radically different. but i agree with you that it would be nice for the whole emacs MUA ecosystem if they were more sensible there. > Arguably, I haven't looked in details at how epg.el works: maybe it > suffers from the same flaw. But from what I can tell, it simply bypasses > the autosave functionality. If you have edit an ecrypted file called > `foo.gpg` (note the non-standard extension), the `#foo.gpg` file is just > a symlink, a lockfile instead of the normal autosave. > > This is probably because it would be prohibitively expensive to > constantly call gpg every time a buffer changes to do the autosave. I > think that is actually a fairly reasonable tradeoff. if it's prohibitively expensive to encrypt-when-saving on a modern machine, then we should be using a different encryption tool. --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: python CFFI bindings integration into notmuch build/test
On Thu 14 Nov 2019 at 23:24 +0100, Floris Bruynooghe wrote:
> On Thu 14 Nov 2019 at 22:20 +0200, Tomi Ollila wrote:
>> In git://notmuchmail.org/git/notmuch David has ref origin/wip/cffi
>> which contains related changes -- You can fetch the code while waiting
>> for more collaboration instructions from David.
>
> Aha, thanks!
So I can run the tests using `make` and `cd tests;
./T-391-pytest-cffi.sh`. I can also run the tests still individually
using something like:
make
set PATH (pwd) $PATH # I use fish
pushd bindings/python-cffi
pew workon notmuch # how I manage python virtualenvs
pip install -e .
pip install pytest pytest-cov
pytest test/test_base.py
And all works. I added a little function to the conftest.py to show
which notmuch it's testing with:
def pytest_report_header():
vers = subprocess.run(['notmuch', '--version'],
capture_output=True, text=True)
which = subprocess.run(['which', 'notmuch'],
capture_output=True, text=True)
return ['{} ({})'.format(vers.stdout.strip(), which.stdout.strip())]
Maybe you find that useful too.
Anyway, this looks good. Would you like some changes, e.g. the rename
to notmuch2 or so as patches? What's the next step.
Kind of unrelated, but in my attempt to run the full notmuch test suite
(cd tests; make test) I somehow ended up with lots of weird tags in my
notmuch database and made the emacs UI pretty horrible - though it seems
I haven't lost any email. I'm sure that was my fault somehow even
though I was just trying to follow the readme. But if anyone has any
hints how to recover from this that could save me some time :)
Cheers,
Floris
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: python CFFI bindings integration into notmuch build/test
On Thu 14 Nov 2019 at 22:20 +0200, Tomi Ollila wrote: > In git://notmuchmail.org/git/notmuch David has ref origin/wip/cffi > which contains related changes -- You can fetch the code while waiting > for more collaboration instructions from David. Aha, thanks! Floris ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add --message-headers flag to notmuch-show
On Thu, Nov 14 2019, Daniel Kahn Gillmor wrote:
> On Wed 2019-11-13 01:30:50 +0200, Tomi Ollila wrote:
>> On Tue, Nov 12 2019, Daniel Kahn Gillmor wrote:
>>
>>> And, I still haven't heard any clear arguments for choosing between
>>> configurability as an absolute thing or a differential thing. They have
>>> significantly different impact on adopters over time, as the default
>>> configuration changes.
>>
>> I don't understand your question,
>
> configurability as an absolute thing:
>
> --message-headers=foo,bar,baz
>
> configurability as a differential thing:
>
> --add-message-header=foo --suppress-message-header=qux
Ahh...
Osmo A. Wiio was a smart man when he stated: "Communication usually fails,
except by accident" ( http://jkorpela.fi/wiio.html - read it now, I'll wait ).
I understand 'configurability' a bit different way -- store something
somewhere which is fetched in the future and alters behaviuor in that
way.
In above options, --message-headers and so on, I'd just "state" or "demand"
the program in question to give me this information, and don't think there
was any configurability in question ('configuration', in "broader" sense,
is there, just hiding somewhere in background =D)
>
>> but I think that configuration option
>> for choosing what message headers to return is far worst of the options,
>> mostly because configuration and what frontend may desire goes easily
>> out if sync (and when managed manually that is what inevitably will
>> happen).
>
> totally agreed, but this is very different from what you said next:
>
>> The option (b) is kinda my favorite, code could be pretty simple, ordering
>> (sprinted in order listed), duplicates (rescan request list so far and drop
>> if header found) might be the harders questions (and seemed not ;/).
>>
>> If option (b) were taken, status quo -- no change in returned headers
>> should be maintained -- separate patch series w/ devel/schemata and test
>> changes can be sent is there desire for changing that.
>
> afaict, option (b) seems to contemplate configurability, which you say
> above you don't want. Maybe we need a clearer list of options, because
> this is getting confusing :P
Perhaps my explanation above cleared at least a bit of confusion.
W/ all this information, somewhat exhaustive (not by options, but by
resources I put making it) list of thougts.
1a by default behave as it is behaving now
1b alternative, in json and sexp, include *all* headers for the use of
frontends (in many other email systems frontends parse full email
messages and see all headers, in notmuch case frontends don't have
to do so since notmuch did the parsing and provides structured data
of (currently subset) that information
2a have option --message-headers= -- when used just those headers requested
is returned (I'd personally prefer this over the "differential" options,
frontends get exactly what it wants and does not need to consider any
default where to add of suppress from)
2b have --add-message-header=foo --suppress-message-header=qux -- to modify
the defult list...
2c have named stored configurations, which can be retrieved with yet another
command line option, since naming is hard, quick potenttially dumb
example could be like: --custom-message-headers=my-cli-headers-set-3
I personally would first go with 1a and 2a. 2c sounds interesting but
requires more work (and I could personally use wrapper instead =D)
Anyway, if someone(tm) implements any of these, speed is not a problem, and
code is reasonably maintainable happy to see notmuch improved this way...
>
> --dkg
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: python CFFI bindings integration into notmuch build/test
On Thu, Nov 14 2019, Floris Bruynooghe wrote:
> Hi,
>
> Thanks for carrying on with this!
>
> I'm a little confused with how to follow this, is the current state of
> the code somewhere in a repo/branch where I can try things out and make
> changes from?
In git://notmuchmail.org/git/notmuch David has ref origin/wip/cffi
which contains related changes -- You can fetch the code while waiting
for more collaboration instructions from David.
> On Tue 05 Nov 2019 at 22:22 -0400, David Bremner wrote:
>
>> Tomi Ollila writes:
>>
>>
>>> alternative:
>>>
>>>...
>>>print('Invoking: {}'.format(' '.join(cmd)))
>>>
>>>def preexec_fn(): os.environ['NOTMUCH_CONFIG'] = str(cfg_fname)
>>>
>>>proc = subprocess.run(cmd, timeout=5, preexec_fn=preexec_fn)
>>>...
>>>
>>> The unix fork ... (here preexec_fn called in child) ... exec model is
>>> superior to any other alternative ! =D
>>
>> I don't consider myself a good judge of python style, so I'll defer to
>> Floris on that one.
>
> I'd have gone with what David wrote to be fair, mostly because it's
> pretty simple to see what's going on where for the preexec_fn I'd have
> to look at the docs. Not sure if this has much to do with Python style
> though, more with how much you like Unix tricks.
Yes, the simple approach taken (by env copy) is fine. It is also good to
know these powerful alternatives that may be useful elsewhere =D
>
>
> Cheers,
> Floris
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: python CFFI bindings integration into notmuch build/test
Hi,
Thanks for carrying on with this!
I'm a little confused with how to follow this, is the current state of
the code somewhere in a repo/branch where I can try things out and make
changes from?
On Tue 05 Nov 2019 at 22:22 -0400, David Bremner wrote:
> Tomi Ollila writes:
>
>
>> alternative:
>>
>>...
>>print('Invoking: {}'.format(' '.join(cmd)))
>>
>>def preexec_fn(): os.environ['NOTMUCH_CONFIG'] = str(cfg_fname)
>>
>>proc = subprocess.run(cmd, timeout=5, preexec_fn=preexec_fn)
>>...
>>
>> The unix fork ... (here preexec_fn called in child) ... exec model is
>> superior to any other alternative ! =D
>
> I don't consider myself a good judge of python style, so I'll defer to
> Floris on that one.
I'd have gone with what David wrote to be fair, mostly because it's
pretty simple to see what's going on where for the preexec_fn I'd have
to look at the docs. Not sure if this has much to do with Python style
though, more with how much you like Unix tricks.
Cheers,
Floris
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
