Re: Extending the ecomplete.el data store.

[Stefan Monnier]

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

The downside is that it slows down operation at times.

> 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).

Another approach is to update more carefully: check that all words from
the old variation still appear in the new variation, and if not, check
if new words appeared (as above): if not it means replacing the old with
the new would reduce the amount of info so it's probably not a good
idea, and if yes then prompt the user.

>> 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.

I think it'd make sense to use `emacs-internal` coding system (aka
utf-8-emacs-unix).


        Stefan