Re: completion for MUAs

[Oliver Kiddle <opk@xxxxxxxxxxxxx>]

Bart Schaefer wrote:

> There are quite a variety of addressbook formats, ranging from nothing
> more than a batch of commands or assignments in the MUA's init files
> through Pine's tab-delimited records to networked LDAP lookup.  Rather
> than try to provide a function that parses any significant subset of
> these, I suggest working out some kind of a plugin model -- paste up a
> function name using $service or the like, and call it if it exists.

That's certainly a possibility but I want to allow, for example the
standard UNIX mail command to complete addresses from the user's
normal MUA's addressbook. A style could override the function called.
Most people probably stick to one MUA (unlike me at the moment) so it
isn't much of a problem if only one addressbook is parsed.

What do you think this separate function achieves mainly - simplicity,
speed?

> Then there's also completion of user names @ the local machine, and
> maybe even /etc{/mail,}/aliases names or the equivalent for other MTAs.

Yes. So we need handling for different MTAs too. I also suspect that in
some contexts (URLs maybe) these might need @localhost appended.

> Some MUAs also are happy with comma-separated lists of addresses in one
> or more command-line arguments while others make each argument an address
> and don't attempt to parse it further (which can lead to strange problems
> later when calling the MTA or having an SMTP conversation).

Yes, that can probably be handled in the MUA's completion with
suitable options such as -S ','. Is the situation that some MUA's
aren't fussed and rely on the MTA to complain if it wants to with MTAs
varying on whether they accept comma separated lists?

> I'd advise completing only the user@host part, unless it's too difficult
> to pick it out of the addressbook entry (but that'd be up to the plugin
> in any case, if you take my advice above).

Yes, okay. It would be better to only complete the other stuff if
we can separate the constituent parts and do it all intelligently.

> By "distribution lists" do you mean `@groupname:addr,addr,addr;' syntax,
> or are you talking about e.g. completing individual addresses that appear
> in the definition of a group or alias in the addressbook, or ...?

I was using the pine terminology and meant aliases/nicknames which map
to more than one e-mail address. I've not seen syntax you mention. How
does that work - is it some specific MTA's shorthand or something
understood by MTAs and defined in an rfc? I also seem to remember some
syntax, possibly using exclamation marks where you can specify the
route through specific mail servers the e-mail takes (actually I
wonder if I can use that to specify addresses in my MTA at work which
go direct to the host's MX such as a.mx.sunsite.dk and bypass the smtp
server here which adds an annoying advert to the bottom of every mail
about the virus checker it uses). It'd be nice to properly complete
these sort of things, partly because it would provide an easy reminder
of the syntax for them.

I had some vague ideas of displaying names next to aliases/nicknames
with the verbose style which would be complicated for distribution
lists. Pine certainly allows a description of the group. Also, I
thought of doing some sort of expansion (like _pids does for process
names) so where nicknames are not going to be understood, they could
be expanded to the address(es).

The crux of it is that what I'm concerned about is how does one safely
parse e-mail addresses. I've read enough of the mail rfcs and sendmail
configs to know that e-mail addresses and correct parsing of them is
extremely complicated but I've not retained enough details in my head
on this to feel confident of doing something which is absolutely
correct. In particular, how do you separate one address from the next
one safely. Much of this parsing is going to be common to MUAs,
particularly mush/Mail/mutt where the format is something like alias
nickname=address so there is scope for using some common code which
makes me unsure about your plugin function idea.

I was also hoping that someone would happen to have some existing
script which parses their addressbook.

Maybe the best plan is if I just come up with something simple based on
what we currently have at the bottom of _mutt, _pine etc and then we
can evolve it to something better.

Oliver