[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
utf-8-emacs-unix).
Stefan
- Re: Extending the ecomplete.el data store., (continued)
- Re: Extending the ecomplete.el data store., Stefan Monnier, 2018/02/04
- Re: Extending the ecomplete.el data store., Karl Fogel, 2018/02/05
- Re: Extending the ecomplete.el data store., Stefan Monnier, 2018/02/05
- Re: Extending the ecomplete.el data store., Karl Fogel, 2018/02/06
- Re: Extending the ecomplete.el data store., Stefan Monnier, 2018/02/06
Re: Extending the ecomplete.el data store., Lars Ingebrigtsen, 2018/02/05
Re: Extending the ecomplete.el data store., Lars Ingebrigtsen, 2018/02/05