mutt has a command-line switch '-a' for attachments, and the Zsh
completer offers files and directories for its argument.

As of late, _email-notmuch also adds all addresses into the mix:

% mutt -a ^D
directory
[…]
file attachment
[…]
email address (notmuch)
[…]


In the context of '-a', no email addresses should be offered. Maybe
this is actually a problem with Zsh or Mutt, I can't figure it out.
But since I see mainly notmuch in the output, I am filing here…

martin f krafft <madduck@debian.org> writes:

As far as I can tell, the whole point of _email-notmuch is to provide
addresses, so maybe it shouldn't be called there? To me that suggests
the bug should be reassigned to mutt. I am CCing the mutt maintainers,
in case they want to weigh in.

d

David Bremner <david@tethera.net> writes:

My mistake, the mutt completion is actually shipped by zsh. I've
attached _email-notmuch (installed by package notmuch) for feedback. If
something looks wrong with it, please let me know. Otherwise I think I
should reassign this bug to zsh, where it can at least get some more
expert consideration.

David Bremner wrote on Sun, Dec 26, 2021 at 07:54:35 -0400:

By code inspection:

Email addresses are offered because the function _mutt (from the file of
the same name shipped by zsh-common) contains:
.
    _arguments -s -S \
      '::recipient:_email_addresses -n mutt' \
      '*-a[attach file using MIME]::file attachment:_files' \
.
which is as self-explanatory as it gets, of course ☺

The two consecutive colons on the -a line mean the -a option takes an
optional argument.  Therefore, «mutt -a <TAB>» completes both arguments
to -a, using _files, and email addresses, using «_email_addresses -n
mutt» (which presumably calls _email-notmuch along with other _email-*
functions).  Still by code inspection, if you remove one of the two
consecutive colons on the -a line, email addresses shouldn't be offered
any more.

If the above analysis is correct, this bug report belongs to zsh-common.

Furthermore, if invocations such as «mutt -a foo@example.com» and «mutt
-a» without further arguments are errors (they are in older mutts, but I
haven't tested in sid), then the report is valid and the fix would be to
drop the second consecutive colon from the -a line in _mutt.

Cheers,

Daniel

Regarding the following, written by "Daniel Shahaf" on 2021-12-31 at 02:16 Uhr +0000:

Herein lies the problem:

```
   -a <file> [...] --	attach file(s) to the message
		the list of files must be terminated with the "--" sequence
```

So it's neither optional, nor even a single word by necessity.

martin f krafft wrote on Fri, Dec 31, 2021 at 15:26:24 +1300:

Good catch.

I think it's possible to teach _mutt how to complete this in the general
case, but the details are better hashed out upstream (zsh-workers@zsh.org).

Cheers,

Daniel

Hey,

mutt allows attaching files from the command-line:

```
mutt -a /file/one /file/two /file/three -- …
```

Basically, the rules are: `-a` takes a list of files, terminated by
`--`.

Zsh's completion of mutt treats the argument to `-a` as optional:

```
   '*-a[attach file using MIME]::file attachment:_files' \
```

Therefore, after `-a`, mutt's completions include recipients, which
is not correct:

```
albatross:~% mutt -a toni^D
directory
toni/
recipient
toni@…
```

Could you please help me figure out how to fix this? Basically after
it sees `-a`, compsys should be offering `_files` until `--` is
encountered, and also: at least one file is mandatory.

Thanks,