Re: Extending the ecomplete.el data store.

[Karl Fogel]

Stefan Monnier <address@hidden> writes:
>> 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.

It could affect startup and shutdown time.  It should have no effect on 
operations during the session (because the on-disk format isn't the same as 
what is used for interactive completion, and needn't even be the same as what 
is used for on-the-fly retention of new addresses).

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

Yes; a ratchet that only moves in the "better" direction.  That's a good 
solution too.

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

*nod*

It sounds like the format unification would only happen if Lars or I feels 
strongly enough to make it happen, which I'm not sure either of us does right 
now.  This thread has at least recorded some of the thinking.  Maybe at some 
point writing a lossless converter from the mailaprop format to ecomplete's 
format might be useful.

In the meantime, if I'm planning to actually take any action toward format 
unification, I'll make a noise here.

Best regards,
-Karl