Re: [PATCH 0/2] Updating tags when replying or forwarding via a buffer-local variable
On Tue, Apr 02 2019, Örjan Ekeberg wrote: > Tomi Ollila writes: >> two things >> >> - I wonder whether we could drop (defun notmuch-message-mark-replied ()...) >> - why is it needed for backward compatibility ? > > Yes, it would be cleaner to simply remove it. My thought was that there > is a slight risk that someone is explicitly using or manipulating this > function in some personal code. This is probably very unlikely, so I am > more than happy to drop it. I think dropping is safe. >> - A test of a few would be nice to see how this behaves -- and we can see >> that this still works e.g. on emacs 24... > > Indeed. I did consider this, but since I am not at all familiar with > how to write such tests, I did not proceed with this. No-one is, but with little investigation, and then (ab)using some of the current emacs tests as base for a new test should be doable. > > /Örjan Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] performance-tests: tests for renamed/copied files in notmuch new
On Tue, Apr 02 2019, David Bremner wrote:
> Several people have observed that this is surprisingly slow, and we
> have a proposal to add tagging into this code path, so we want to make
> sure it doesn't imply too much of a performance hit.
> ---
> performance-test/T00-new.sh | 30 ++
> 1 file changed, 30 insertions(+)
>
> I added these tests to help evaluate Michael's propesed patch. I'll send the
> results in a seperate email.
>
> diff --git a/performance-test/T00-new.sh b/performance-test/T00-new.sh
> index 68750129..cec28d58 100755
> --- a/performance-test/T00-new.sh
> +++ b/performance-test/T00-new.sh
> @@ -12,4 +12,34 @@ for i in $(seq 2 6); do
> time_run "notmuch new #$i" 'notmuch new'
> done
>
> +manifest=$(mktemp manifestXX)
> +
> +count=0
> +total=0
> +while read -r name ; do
> +if [ $((total % 4 )) -eq 0 ]; then
> +echo $name >> $manifest
> +count=$((count + 1))
> +fi
> +total=$((total + 1))
> +done < <(find mail -type f ! -path 'mail/.notmuch/*' )
// this comment was written last in this email, just for fun >;) //
find mail -type f ! -path 'mail/.notmuch/*' | sed -n '1~4 p' > $manifest
count=`wc $manifest`
(I'd be interested which one of the above were faster -- my suggestion
does quite a many more forks and execve's but abowe read loop 200 000
read(2)'s and [lf]seek(2)s (and then 50 000 opens).
well, probably no-one would notice difference...)
> +
> +while read -r name ; do
> +mv $name ${name}.renamed
> +done < $manifest
'12' -- 2 spaces above (and below...)
luckily bash read builtin does not read input byte at a time
(IIRC it read 128 bytes, then scanned for newline and then seeked
-- in this case it can, since file was redirected -- fd is seekable)
50 000 mv(1) executions definitely take time.
perl -nle 'rename $_, "$_.renamed"' $manifest would be significantly faster
> +
> +time_run "new ($count mv)" 'notmuch new'
> +
> +while read -r name ; do
> +mv ${name}.renamed $name
> +done < $manifest
> +
> +time_run "new ($count mv back)" 'notmuch new'
> +
> +while read -r name ; do
> +cp ${name} $name.copy
> +done < $manifest
perl -nle 'link $_, "$_.copy"' $manifest ?
> +
> +time_run "new ($count cp)" 'notmuch new'
> +
> time_done
> --
> 2.20.1
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/4] emacs: Implement notmuch-search-refine
Hello, David Bremner writes: > Is the whole story that you don't like pressing M-p after pressing l > to bring up the previous query? Pretty much. I wrote that patch not knowing that notmuch could predict the next potential search with M-n in the minibuffer (which, as it stands, does the same thing as M-p). Discovering that severely undermined the raison d’être of this patch. I tried to do something else with it by having it mimic a similar function in mu4e where the point was put at the end of the previous search, but I’ve found very little use for it. I think it’s safe to abandon this patch. Best, -- Leo Vivier ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Duplicate tags in completion for notmuch-search-tag-all
Hi again, I recently realized that `notmuch-search-tag-all' gives me duplicate completion candidates in ivy; in particular, it seems to show "-X" once for every thread (or message?) in the current view that has tag "X". So, for example, when pressing '*' on a search view with 20 unread threads, I get a completion list with "-unread" repeated a lot of times. The docstring of `notmuch-read-tag-changes', called internally by `notmuch-search-tag-all', explicitly says that "[the argument] CURRENT-TAGS may contain duplicates", but it does not elaborate on how they are supposed to be handled. I assume my problem arises from the combination of using `ivy-completing-read' as the `completing-read-function' and the list of candidates containing duplicates. Is there some sort of contract for `completing-read-function' requiring it to take care of duplicates? In that case, I guess it would be ivy's responsibility. Otherwise, do you see any problems with explicitly removing duplicates from the list of current tags in `notmuch-read-tag-changes'? Cheers, Sebastian signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/4] emacs: Implement notmuch-search-refine
Leo Vivier writes: > Discovering that severely undermined the raison d’être of this patch. I > tried to do something else with it by having it mimic a similar function > in mu4e where the point was put at the end of the previous search, but > I’ve found very little use for it. > > I think it’s safe to abandon this patch. > Thanks for the followup. I'll mark it as obsolete for now. All the best, David ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
notmuch-tag-jump for multiple threads
Hi all, I'm wondering which workflow people use for this situation that comes up frequently for me: I have a search that gives me a bunch of threads, say new messages from a mailing list, and then I go over them, possibly reading some threads in detail and skipping over others. Afterwards, I would like to apply some tag changes to all threads, like "-unread" or "+archived". So far, the two ways I've found to do so in the search view are '*' (`notmuch-search-tag-all') and typing the tag change in the completing read, or marking the entire buffer followed by 'k' (`notmuch-tag-jump') and the shortcut for my change. It feels as if something like 'K' would be nice, offering the same jump menu like 'k' but applying the change to all displayed messages. What is your take? Do you ever encounter the same situation? I would give the implementation a try but wanted to make sure first that I'm not missing anything. Cheers, Sebastian ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Cycle-expand all org-style in show-mode and search all
On Wednesday, 2019-04-03 at 13:24:28 +02, Pierre Neidhardt wrote: >>> Related: is it possible to search the entire conversation, even when >>> messages are folded? >> >> No. >> >>> If not, the workaround would be to temporarily expand-all (once the >>> above feature is implemented), and search from there. >> >> You might also be able to do something with isearch-open-invisible >> properties on the overlay used to fold messages. > > I found a bunch of variables, none of which is documented: > > Functions: > - isearch-open-overlay-temporary > - isearch-open-necessary-overlays > - outline-isearch-open-invisible > > Variables: > - outline-isearch-open-invisible-function There is some documentation here: https://www.gnu.org/software/emacs/manual/html_node/elisp/Invisible-Text.html dme. -- Please forgive me if I act a little strange, for I know not what I do. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/4] emacs: Implement notmuch-search-refine
zaep...@gmail.com writes: > From 6f73e9aa2031de33eb48a05807295fdb7c3bb566 Mon Sep 17 00:00:00 2001 > From: Leo Vivier > Date: Wed, 6 Feb 2019 16:44:59 +0100 > Subject: [PATCH 1/4] emacs: Implement notmuch-search-refine > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Refine the current query string. > --- > Filtering was already implemented with notmuch-search-filter, but > there wasn’t any way to refine the current query. > --- I don't really understand/remember the motivation for this proposed new feature. I know it was discussed on IRC, but I don't think I understood it completely then either. Is the whole story that you don't like pressing M-p after pressing l to bring up the previous query? d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Cycle-expand all org-style in show-mode and search all
On Wednesday, 2019-04-03 at 11:14:42 +02, Pierre Neidhardt wrote: > Is it possible to cycle-expand-all subtrees in show-mode, à-la Org? What do you mean by “subtrees”? M-RET should open all of the messages in the thread, but it doesn't do anything about regions that are hidden within messages due to washing. > Related: is it possible to search the entire conversation, even when > messages are folded? No. > If not, the workaround would be to temporarily expand-all (once the > above feature is implemented), and search from there. You might also be able to do something with isearch-open-invisible properties on the overlay used to fold messages. dme. -- Do I have to tell the story, of a thousand rainy days since we first met? ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Reply inline in notmuch-show buffer, "mu4e-conversation style"
On Wednesday, 2019-04-03 at 11:12:27 +02, Pierre Neidhardt wrote: > Anyone interested? Should I send a patch? I couldn't figure out when I'd want to use this, as yanking text from the existing notmuch-show buffer seems straightforward. Maybe something akin to gnus-dired-mode would be interesting - it would be used in notmuch-show mode and yank selected text into the current message-mode buffer (including quoting). dme. -- I got a girlfriend that's better than that. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[emacs] Auto-rotate pictures
Hi, Some pictures embed "exif" metadata with autorotate information. I know that mu4e can autorotate inlined pictures. I guess it wouldn't be too hard to implement this for Emacs Notmuch either. Anyone? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-tree-tag does not support regions
Should I send a patch? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Add notmuch-tree-toggle-order?
Hi, We have notmuch-search-toggle-order but surprisingly there is no notmuch-tree-toggle-order. Besides, I find the default tree order somewhat counter-intuitive: the threads are sorted newest at the top, but the messages within the thread are sorted oldest at the top (which quite expected from a tree display). Thoughts? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v1 1/1] emacs: Add `notmuch-wash-cut-here'
That'd be great! Would you like to implement this? Either way, the patch looks good to me and it'd be great to see it merged upstream. Thanks! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
