Re: Extending the ecomplete.el data store.

[Lars Ingebrigtsen]

Karl Fogel <address@hidden> writes:

> * Mailaprop remembers all the real-name variations and case variations
> individually, including case variations in the email address portion
> as well as in the real name portion.  So each variation gets its own
> record, but they're all tied together under the same case-folded KEY
> so they can be scored together.  (Contrast with ecomplete, where I
> believe `ecomplete-add-item' just remembers the most recently-seen
> variant for a given key.)

Yes, I see the advantages of storing all the variations (it gives us a
larger search space).

However, I've found that in practice the simple "store the last
variation" thing works surprisingly well.  But the disadvantage is that
you basically lose the completion if the last variation is degenerate,
like if you'd written "From: HAHAHA <address@hidden>", then my
Message/icomplete wouldn't be able to complete on "Karl" (which is what
you'd get normally).

On the other hand, if you store all variations, then HAHAHA will forever
be an available completion, too, which also has disadvantages.

So: Either complete historical completion, or uncomplete, but pretty
up-to-date completion.

If you have too much to complete on, you just end up with noise.

> If we unify the format, we should probably unify on one default record
> file too.  Right now, `ecomplete-database-file' defaults to
> ~/.ecompleterc or ~/.emacs.d/ecompleterc, whereas
> `mailaprop-address-file' doesn't default to anything -- the user must
> set it manually: email addresses are pretty private, and I didn't want
> to guess about what locations would be confidential enough.  I'd be
> happy to just have mailaprop use ecomplete's defaults for the database
> file, though.  The privacy concern can be addressed with
> documentation.

If the user has said that they want completion, the user will surmise
that the data has to be stored somehow.

> I guess we would also switch to UTF-8 for the coding system for the
> database?  (Right now `ecomplete-database-file-coding-system' defaults
> to `iso-2022-7bit'.)

The latter can store more than the former, but UTF-8 is fine by me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no