[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Extending the ecomplete.el data store.

From: Stefan Monnier
Subject: Re: Extending the ecomplete.el data store.
Date: Tue, 06 Feb 2018 16:12:42 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]