Duplicate tags in completion for notmuch-search-tag-all

Duplicate tags in completion for notmuch-search-tag-all

[Sebastian Poeplau]

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Duplicate tags in completion for notmuch-search-tag-all

[David Bremner]

Sebastian Poeplau <sebastian.poeplau@eurecom.fr> writes:

> 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'?

I noticed that completing-read can take a hash-table, so maybe
collecting tags as a hash-table in the first place would be an efficient
way to deduplicate them.  That would require more changes though, since
it would move the deduplication into the callers of notmuch-read-tag-changes.

I worry a bit about the movement of deduplication from the (brute
force) C code in minibuf.c into notmuch elisp, but I could be convinced,
e.g. with some profiling.

d