Re: [PATCH] Add --message-headers flag to notmuch-show
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, 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). > So, of the three options you list, i far prefer (a) because it doesn't > introduce any of the configurability maintenance or API complexity > costs. > If the main objection to (a) is performance regression, i'd like to see > some profiling of that performance cost, so we can better understand it. > Perhaps there's a different way to mitigate a performance regression. I'd guess it depends how frontends spend time parsing json/sexp output. I would not expect raw C code to be bottleneck, don't know how gmime spends time fetching header data on user request... 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. > > --dkg Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add --message-headers flag to notmuch-show
On Tue 2019-11-12 20:24:12 +0100, Johan Parin wrote: > I think this is quite basic functionality. All "nerdy" muas have it ;) > Gnus has it, mu4e has it etc. mutt seems to have some reasonable default > of at least displaying User-Agent. I think Thunderbird has it too. etc Yes, and of course i accept that notmuch is a "nerdy" MUA. > I really don't think the configurability is expensive. To be clear, i'm suggesting that the code maintenance for the configurability (and the API surface it creates) is what's expensive, not that the code is particularly costly to run. > b) notmuch-show.c exports a limited set of "interesting" headers. This >patch should be modified to set the headers in the config file. I >think this is a really good solution if you are concerned with >performance in a) Are you sure you want the configuration in the config file and not in the database itself? we've had a bunch of discussion on-list about the fact that the config data is split between the config file and the database, and some of the config must live in the database (because the config affects library operations, which do not read the config file). Eventually, i hope we will consolidate on config-in-the-database, so each additional piece of config we add to the configfile makes me sad. furthermore, if we ever decide to remove these configuration options (e.g. by switching to (a)), we'll end up making some users sad. so it's ongoing code maintenance even if most people don't use it :( 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. So, of the three options you list, i far prefer (a) because it doesn't introduce any of the configurability maintenance or API complexity costs. If the main objection to (a) is performance regression, i'd like to see some profiling of that performance cost, so we can better understand it. Perhaps there's a different way to mitigate a performance regression. --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
unifying and automating draft ("postpone/resume") behavior [was: Re: notmuch "lost" email during power failure]
Hi Antoine-- [epic story and funny rnat trimmed down to the salient bug reports and feature requests because i'm a boring person] On Tue 2019-11-12 17:19:05 -0500, Antoine Beaupré wrote: > I would argue that notmuch should at least allow me to recover from a > power failure like this, as a MUA. It should "know" that message-mode > stores those messages there, and, why not, also store its tempfiles > there. This seems like a very specific ask. I think what we want more generally is a sensible unification of the notmuch-emacs drafting behaviors such that message-mode autosaves are discoverable and recoverable in the same way that deliberately-saved drafts are. If that means that notmuch learns about message-mode drafts, that's one solution. But it could also mean that notmuch-emacs overrides message-mode's autosave drafting approach, and fixes things there too. or, we somehow fix message-mode? > And indeed, if I hit [control-x control-s] on this message, it *does* > get saved as a "draft" in that it gets written in: > > ~/Maildir/drafts/cur/1573596264.M156307P32312.curie:2,DF > > That's a great improvement already. I don't remember exactly when or how > this happened, but that's great and I thank whoever did that for us > here. That was Mark Walters (in Cc), see the series from 2016 starting at: id:1479046130-2716-1-git-send-email-markwalters1...@gmail.com Thank you, Mark! > To make a long story short, I think the following should happen: > > 1. message-mode should automatically cleanup after itself a little > better (not notmuch's job? yay double-negative, that means it's much > job!) > > 2. encrypted emails should *never* be written in cleartext on the > filesystem (not notmuch job, which also means it's much job!) > > 3. notmuch's draft subsystem should know about Emacs' autosave files > and somehow show them in the UI Much of the above sounds like message-mode cleanup work to me. It might be worth asking the message-mode folks to weigh on in this strategy. Alternately, it might help to characterize the differences between message-mode autosaving and notmuch explicit drafting. - message-mode autosaves happen without your knowledge. notmuch draft saving only happens when you explicitly C-x C-s - message-mode autosaves are automatically cleaned up from the filesystem after you send. notmuch saved drafts persist in your mailstore until you remove them (though they are tagged with "delete") - message-mode autosaves appear to save in cleartext even when the message will be encrypted(‽). if you try to C-x C-s on a notmuch draft, notmuch-emacs gives you a big ol' warning and won't let you save it in plaintext unless you agree (see notmuch-draft-save-plaintext). (Maybe there's a third behavior which would be better than all of these, which is to explicitly save the draft of encrypted messages encrypted-to-self-only, but that's not implemented, afaict) Does this all sound right? There's a lot to unpack here. --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
notmuch "lost" email during power failure
Hi! Today, in Canadaland(show.com), it's winter! There's snow everywhere, it's beautiful but cold, which means we power up those heating system and blow up breakers. Which means computers go down because those little stupid things need power to keep going, especially when they don't have UPS systems built in. Those backwards machines were previously known as "desktops" but are now known as "what, you still have one of those? yes I do leave me alone." Anyways. Today my desktop lost power while I was writing a too long email to dkg about internet standards. Then power went out halfway through the email. When I rebooted, notmuch couldn't find the email and I assumed it was dead and gone, wrongly, as it turns out. I draw many conclusions from this: 1. i shouldn't write long emails to dkg 2. i shouldn't write long emails to replies of dkg to my long emails 3. notmuch should never lose email drafts of long emails i write to dkg 4. i should learn not to worry and love the bomb Obviously, I come to you with conclusion #3. Being the resourceful and friendly human being that he is, dkg pointed out the `~/.emacs.d/auto-save-list/` directory. It contains a list of files that have a list of file names in them (!?) pointing to various auto-save files. I couldn't figure out where that thing comes from, but it did lead me to a saved copy of the message. Naturally, I only found dkg's message *after* I spent another hour rewriting the damn message after the power failure, but it was accurate: one of those files had a filename that pointed at: ~/Mail/drafts/#*message*-20191112-165309# which contained the auto-save of the message! Hurray! As it turns out, that location (~/Mail/drafts) is the default `message-auto-save-directory`. That's great, but the problem is there's no visibility in that directory from notmuch's perspective. Even worse, message-mode leaves stray messages in there. While cleaning it up, I even found an old message from 2018 that had a *password* (*gasp*!) in it that I carelessly sent to other people. Interestingly, that message was sent encrypted (with OpenPGP) but was still stored as a tempfile in cleartext there. Obviously, none of that so far is directly notmuch's fault: those are all problems with message-mode. *But* I would argue that notmuch should at least allow me to recover from a power failure like this, as a MUA. It should "know" that message-mode stores those messages there, and, why not, also store its tempfiles there. And indeed, if I hit [control-x control-s] on this message, it *does* get saved as a "draft" in that it gets written in: ~/Maildir/drafts/cur/1573596264.M156307P32312.curie:2,DF That's a great improvement already. I don't remember exactly when or how this happened, but that's great and I thank whoever did that for us here. I do remember hacking something like this together before that happened however. I made message-mode write temporary messages directly in that folder (by setting the auto-save-directory to ~/Maildir/draft/new), which notmuch would somewhat pickup at the next automated `notmuch new` run. But that made notmuch unhappy for various reasons: 1. the autosave files don't have message IDs which would confuse notmuch 2. the files wouldn't automatically be removed from notmuch's database even when (or if!) message-mode would actually clean them up I had to write hacks like this to cleanup those files: https://gitlab.com/anarcat/scripts/blob/master/notmuch-clear It was a mess, so I reverted message-auto-save-directory back to its default and totally forgot about it. Which led me to writing a second long email to dkg. Which made me kind of obstinately sad. Which is very weird. But that's probably standard IETF behavior by this point. Not sure which draft, RFC or BCP that is, but that's probably irrelevant. ;) To make a long story short, I think the following should happen: 1. message-mode should automatically cleanup after itself a little better (not notmuch's job? yay double-negative, that means it's much job!) 2. encrypted emails should *never* be written in cleartext on the filesystem (not notmuch job, which also means it's much job!) 3. notmuch's draft subsystem should know about Emacs' autosave files and somehow show them in the UI Sorry for the long email. My attempts at comedy in this one are probably far from the previous one, but the topic was less happy and I was less motivated. I promise to try again next time though, and thank you for flying nutty anarcat. Cheers, A. -- The problem is not a lack of highly educated workers, the problem is a lack of highly educated workers willing to work for the minimum wage or lower in the U.S. Costs are driving outsourcing, not the quality of American schools. - Scott Kirwin, IT Professionals Association ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Segfault when tagging results of to: query
That's most probably xapians fault. Xapian 1.4.13 has a bug in it, there's a patch available but no new version has been released yet. You can find the issue here: https://trac.xapian.org/ticket/796#no1 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add --message-headers flag to notmuch-show
Daniel Kahn Gillmor writes: > On Mon 2019-11-11 10:26:18 -0500, Daniel Kahn Gillmor wrote: >> - What is the specific use case for this? For example, can you identify >>situations where different headers need to be emitted by different >>users? Even one motivating example would help others on this list >>understand why they might want to care :) > > ah, sorry, i've just read > id:20191109221358.4349-1-johan.pa...@gmail.com and its associated > messages, so i can see that some of the questions i'm asking are > already under discussion. > > I see that you just want user-agent and x-mailer for your own > purposes. > Well that is just my current minimum requirements. I'm a mail nerd and I always want to see what mua people are using, if present. And no, it is not OK to have to hit 'V' and see all headers. There are way too many garbage headers. You want to have the headers you are interested in to be displayed automatically for every message in a nice readable fashion. Someone else in this thread wanted Arhive-At; the bug reporter wanted X-Github-Sender. Now that I think about it I definitely want X-Face. Maybe List-Id. etc. It's really hard to predict what people think is interesting, which is why configurability is needed. I think this is quite basic functionality. All "nerdy" muas have it ;) Gnus has it, mu4e has it etc. mutt seems to have some reasonable default of at least displaying User-Agent. I think Thunderbird has it too. etc > Maybe it would be worthwhile to propose that narrow, limited change as > a simple patch, without configurability and see what it looks like? I > would personally be more likely to advocate for merging a patch that > meets the specific needs of a notmuch user, and increase the > configurability surface of notmuch. > I really don't think the configurability is expensive. The elisp code base is already prepared for it with the notmuch-message-headers variable. It's just that it's not working because notmuch-show.c only exports a fixed set of headers. So it's a bug fix, really. > If processing a couple of extra headers on a long thread is too > expensive for some consumer, i'd suggest that is an optimization for > the consumer to tackle. I have implemented three variants: a) notmuch-show.c exports all headers b) notmuch-show.c exports a limited set of "interesting" headers. This patch should be modified to set the headers in the config file. I think this is a really good solution if you are concerned with performance in a) c) notmuch-show.c exports headers specified with a command line arg, which is passed from the elisp based on `notmuch-message-headers'. In all cases the actual headers displayed in the emacs mua is controlled by `notmuch-message-headers'. Personally I don't think there is any discernible performance impact with any of these, and that any performance impact is dwarfed by the GMime message parsing code and elisp display code. But if there is concern with a, then b) and c) can be chosen which should have basically zero performance impact. I also don't think there is maintenance cost with any of these once it is implemented so I don't see why we should not have configurability. All of the patches need some polishing (and I noticed a functional issue with "c). But if we can get consensus on an approach that is OK, then I would be happy to continue perfecting it. /Johan ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unread handling
Teemu Likonen writes:
>
> It seems to me that using search term tag:unread will help you. Try this
> in the *hello* buffer:
>
> z tag:unread
>
> You'll go directly to tree view and unread messages will show with
> normal colours and read messages with grey colour. Commands "n" and
> "p" will skip over read messages ("N" and "P" won't). You can
> configure saved searches to start with tree view.
Yes this is very good. Actually what I do now is
s tag:unread date:-2d..
which gives me almost what I want. Only downside is, completely unread
threads don't show up in the search view. Sometimes I want to go back
and read a read thread. But this can be solved by using flagged (or some
other tag). So now I have:
s ((tag:unread date:-2d..) or tag:flagged)
which works pretty well.
Thanks!
/Johan
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add --message-headers flag to notmuch-show
On 2019-11-12 12:19:01, Daniel Kahn Gillmor wrote: > On Tue 2019-11-12 10:48:54 -0500, Antoine Beaupré wrote: >> They need User-Agent:, I want Archive-At:, they will want >> X-Mailer... when is it going to stop? > > It's going to stop when users are satisfied. :) I highly doubt that we > will reach all possible headers. I wouldn't be surprised, actually. :p >> I would rather have configurability here than and endless stream of >> patches to grow a possibly boundless list... > > Configurability is at least as expensive to maintain as a (not actually > endless) short stream of patches, but i understand different people have > different tradeoffs they're willing to make. > > Can you suggest which kind of configurability you would prefer: complete > override, or differential modification? And if so, why do you prefer it > over the other choice? or should there be both? I have no idea, to be honest. But it's something I banged my head a few times against in notmuch and I would hate to have to recompile the entire thing to fix this on a local copy. a. -- The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place. - Douglas Adams (1952-2001) ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add --message-headers flag to notmuch-show
On Tue 2019-11-12 10:48:54 -0500, Antoine Beaupré wrote: > They need User-Agent:, I want Archive-At:, they will want > X-Mailer... when is it going to stop? It's going to stop when users are satisfied. :) I highly doubt that we will reach all possible headers. > I would rather have configurability here than and endless stream of > patches to grow a possibly boundless list... Configurability is at least as expensive to maintain as a (not actually endless) short stream of patches, but i understand different people have different tradeoffs they're willing to make. Can you suggest which kind of configurability you would prefer: complete override, or differential modification? And if so, why do you prefer it over the other choice? or should there be both? --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add --message-headers flag to notmuch-show
On 2019-11-11 10:39:11, Daniel Kahn Gillmor wrote: > On Mon 2019-11-11 10:26:18 -0500, Daniel Kahn Gillmor wrote: >> - What is the specific use case for this? For example, can you identify >>situations where different headers need to be emitted by different >>users? Even one motivating example would help others on this list >>understand why they might want to care :) > > ah, sorry, i've just read id:20191109221358.4349-1-johan.pa...@gmail.com > and its associated messages, so i can see that some of the questions i'm > asking are already under discussion. > > I see that you just want user-agent and x-mailer for your own purposes. > > Maybe it would be worthwhile to propose that narrow, limited change as a > simple patch, without configurability and see what it looks like? I > would personally be more likely to advocate for merging a patch that > meets the specific needs of a notmuch user, and increase the > configurability surface of notmuch. > > If processing a couple of extra headers on a long thread is too > expensive for some consumer, i'd suggest that is an optimization for the > consumer to tackle. They need User-Agent:, I want Archive-At:, they will want X-Mailer... when is it going to stop? I would rather have configurability here than and endless stream of patches to grow a possibly boundless list... a. -- Brief is this existence, as a fleeting visit in a strange house. The path to be pursued is poorly lit by a flickering consciousness. - Albert Einstein ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Debian packaging cleanup
On 2019-11-10 12:37:42, Daniel Kahn Gillmor wrote: > This series offers a set of simple and small changes to the debian > packaging for notmuch. they apply to the master branch. > > I've reviewed these changes, and tested a build with them with no > problems. > > A modern, canonicalized debian package is easier to work with. > > Please consider applying these changes! If you're uncomfortable with > any of them, I'm happy to hear feedback. Looks good to me. -- The history of any one part of the earth, like the life of a soldier, consists of long periods of boredom and short periods of terror. - British geologist Derek V. Ager ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unread handling
Teemu Likonen writes: > Teemu Likonen [2019-11-12T16:54:35+02] wrote: > >> But indeed, a command like "notmuch-search-show-thread-tree" (M-RET, >> C-u RET, C-RET...) would be useful: open current thread directly in >> tree view and with current search terms. > > But that is already there (without keybinding): > > (defun notmuch-tree-from-search-thread () > "Show the selected thread with notmuch-tree" > (interactive) > (notmuch-tree (notmuch-search-find-thread-id) > notmuch-search-query-string > nil > (notmuch-prettify-subject (notmuch-search-find-subject)) > t)) oh!! This is exactly what I was looking for. Just need to bind this. Thanks, Will ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unread handling
Teemu Likonen [2019-11-12T16:54:35+02] wrote: > But indeed, a command like "notmuch-search-show-thread-tree" (M-RET, > C-u RET, C-RET...) would be useful: open current thread directly in > tree view and with current search terms. But that is already there (without keybinding): (defun notmuch-tree-from-search-thread () "Show the selected thread with notmuch-tree" (interactive) (notmuch-tree (notmuch-search-find-thread-id) notmuch-search-query-string nil (notmuch-prettify-subject (notmuch-search-find-subject)) t)) -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tliko...@iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unread handling
William Casarin [2019-11-12T05:59:09-08] wrote: > Teemu Likonen writes: >> Seems like the same as pressing Enter to select a thread and then Z >> to see the thread it in tree view. No? > > Yes, but this has performance implications on large threads. Pressing > Enter will load all of the messages. Opening tree view with the thread > id is much faster, as it only loads the messages when you click them > from what I can tell. Ah, I see. I have "notmuch-show-only-matching-messages" variable non-nil and my daily searches have some limiting terms like "tag:unread" or "date:90days.." so RET (notmuch-search-show-thread) command won't show very large number of messages. But indeed, a command like "notmuch-search-show-thread-tree" (M-RET, C-u RET, C-RET...) would be useful: open current thread directly in tree view and with current search terms. -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tliko...@iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unread handling
David Edmondson writes: > On Tuesday, 2019-11-12 at 05:17:46 -08, William Casarin wrote: > >> David Edmondson writes: >>> On Monday, 2019-11-11 at 00:16:17 +01, Johan Parin wrote: I'm trying instead to use the tree view, this seems to me the more natural way to view threads. So I immediately do `Z' whenever I enter a thread. I would like to have the option to enter tree view automatically for a thread from the search buffer. Is it possible? >>> >>> “Z” in search mode should take you directly to tree mode. >> >> true, but it opens tree mode for the entire search result. I >> find myself doing `c i z Ctrl-v` to open the tree view for a >> specific thread, but perhaps it would make sense if there was a >> default keybind for this. > > Hmm, yes, that's a bit annoying. > > I'd suggest 'z' as a good binding, but obviously it's already > used. What would make sense? C-u Z perhaps? ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unread handling
Teemu Likonen writes: > William Casarin [2019-11-12T05:17:46-08] wrote: > >> I find myself doing `c i z Ctrl-v` to open the tree view for a >> specific thread, but perhaps it would make sense if there was a >> default keybind for this. > > Seems like the same as pressing Enter to select a thread and then Z to > see the thread it in tree view. No? Yes, but this has performance implications on large threads. Pressing Enter will load all of the messages. Opening tree view with the thread id is much faster, as it only loads the messages when you click them from what I can tell. Cheers, Will ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unread handling
William Casarin [2019-11-12T05:17:46-08] wrote: > I find myself doing `c i z Ctrl-v` to open the tree view for a > specific thread, but perhaps it would make sense if there was a > default keybind for this. Seems like the same as pressing Enter to select a thread and then Z to see the thread it in tree view. No? -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tliko...@iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unread handling
On Tuesday, 2019-11-12 at 05:17:46 -08, William Casarin wrote: David Edmondson writes: On Monday, 2019-11-11 at 00:16:17 +01, Johan Parin wrote: I'm trying instead to use the tree view, this seems to me the more natural way to view threads. So I immediately do `Z' whenever I enter a thread. I would like to have the option to enter tree view automatically for a thread from the search buffer. Is it possible? “Z” in search mode should take you directly to tree mode. true, but it opens tree mode for the entire search result. I find myself doing `c i z Ctrl-v` to open the tree view for a specific thread, but perhaps it would make sense if there was a default keybind for this. Hmm, yes, that's a bit annoying. I'd suggest 'z' as a good binding, but obviously it's already used. What would make sense? dme. -- So clap your hands together, make beats with cutlery. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unread handling
David Edmondson writes: > On Monday, 2019-11-11 at 00:16:17 +01, Johan Parin wrote: >> I'm trying instead to use the tree view, this seems to me the >> more natural way to view threads. So I immediately do `Z' >> whenever I enter a thread. I would like to have the option to >> enter tree view automatically for a thread from the search >> buffer. Is it possible? > > “Z” in search mode should take you directly to tree mode. true, but it opens tree mode for the entire search result. I find myself doing `c i z Ctrl-v` to open the tree view for a specific thread, but perhaps it would make sense if there was a default keybind for this. Cheers, Will ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
