[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Extending the ecomplete.el data store.
From: |
Karl Fogel |
Subject: |
Re: Extending the ecomplete.el data store. |
Date: |
Tue, 06 Feb 2018 17:04:11 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
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
- Re: Extending the ecomplete.el data store., (continued)
Re: Extending the ecomplete.el data store., Lars Ingebrigtsen, 2018/02/05
Re: Extending the ecomplete.el data store., Lars Ingebrigtsen, 2018/02/05