search

minad / cape

🦸cape.el - Completion At Point Extensions
GNU General Public License v3.0
584 stars 20 forks source link

Supporting Hippie Expand #42

Closed DamienCassou closed 2 years ago

DamienCassou commented 2 years ago

There has been some noise around Hippie Expand recently and I thought this could be a nice addition to cape.

minad commented 2 years ago

Yes, I've seen the recent noise. Hippie is obsolete and I recommend to migrate away from it. It has been mostly obsoleted by dabbrev and the capf mechanism. Now it would be nice if we could reuse the hippie backends and turn them into completion-at-point-functions, completion-in-region or completing-read commands. Unfortunately it turns out that the hippie backends are written in a way which disallows such usage. The hippie backends are impure and manipulate the buffer directly instead of returning a list of possible abbreviation candidates. It is still possible to obtain the candidates by manipulating the buffer and reverting, but this is slow and error prone. See https://github.com/minad/consult/pull/175 for some previous discussion for a consult-hippie command, which I rejected in the end due to poor performance and the fragility of the approach.

minad commented 2 years ago

I should add that for all the Hippie backends we essentially have cape-* or *-at-point functions, which act as a substitute. See https://github.com/emacs-mirror/emacs/blob/fb752561eab92343683552a5780dd80406936d09/lisp/hippie-exp.el#L204-L218. If some backends are missing we could add them directly in the form of Capfs to Cape. Please let me know if you have ideas for further backends or if you miss something from Hippe. In any case, the Capfs could also go directly into Emacs itself as the Cape README mentions. For example Emacs 29 got a dabbrev-capf with functionality which is probably mostly equivalent to cape-dabbrev.