"The history of #Emacs completion frameworks is a progression from monolithic solutions toward composable ones."
-
"The history of #Emacs completion frameworks is a progression from monolithic solutions toward composable ones."
This is a comprehensive summary, with a thorough and fair history. A long read, but worth it.
I plateaued at #Vertico #Orderless #Marginalia #Consult years ago. Maybe time to learn the others, one at a time.
VOMPECCC: A Modular Completion Framework for Emacs
Completion is not a feature or UI, but instead it is a system composed of at least half a dozen orthogonal concerns that most users never think about separately...
Charlie Holland's Blog (www.chiply.dev)
@jameshowell I'm currently listening to the previous post in the series¹ and agreeing with pretty much everything.
-
@tchauhan Another example is `cape-history` vs `consult-history`, which you can use in Comint, Shell or Eshell buffers. `cape-history` displays the candidates via in-buffer completion (e.g. Corfu) while `consult-history` displays the candidates via `completing-read` (e.g. Vertico).
@jameshowell @oantolin@minad Now that I've gotten used to corfu instead of consult-completion-in-region, I should probably switch to cape-history in REPLs and shells. For minibuffer history, I might stick with consult-history. Which do you use for minibuffer history, Daniel? @tchauhan @jameshowell
-
@minad Now that I've gotten used to corfu instead of consult-completion-in-region, I should probably switch to cape-history in REPLs and shells. For minibuffer history, I might stick with consult-history. Which do you use for minibuffer history, Daniel? @tchauhan @jameshowell
@oantolin I use consult-history for both (repl and minibuffer), but mainly because I've bound it to the more convenient key (M-r).
@tchauhan @jameshowell -
@oantolin I use consult-history for both (repl and minibuffer), but mainly because I've bound it to the more convenient key (M-r).
@tchauhan @jameshowell@minad Same here, except I use M-h (not a lot paragraphs to mark in that type of buffer). @tchauhan @jameshowell
-
@jameshowell I'm currently listening to the previous post in the series¹ and agreeing with pretty much everything.
@oantolin @jameshowell @minad While I largely agree with the points made in the completion post, I wonder if there’s a need to introduce more jargon. Isn’t a completion framework just another name for an IME (input method editor)? https://en.wikipedia.org/wiki/Input_method
-
@oantolin @jameshowell @minad While I largely agree with the points made in the completion post, I wonder if there’s a need to introduce more jargon. Isn’t a completion framework just another name for an IME (input method editor)? https://en.wikipedia.org/wiki/Input_method
@kickingvegas I thought IMEs were mechanisms to type single characters and that most of them do not involve incremental completion and filtering!
EDIT: Your Wikipedia link agrees with my recollection. @jameshowell @minad
-
@kickingvegas I thought IMEs were mechanisms to type single characters and that most of them do not involve incremental completion and filtering!
EDIT: Your Wikipedia link agrees with my recollection. @jameshowell @minad
@oantolin
This text on Chinese IMEs and seeing what contemporary implementations of it can do has shown me how much incremental completion and filtering has changed the game for computer input. -
@tchauhan What do you find difficult about Cape?
Cape basically provides a bunch of completion backends, so called Capfs. You can either add the Capfs to the `completion-at-point-functions` list, or invoke them directly, for instance `M-x cape-emoji` or `M-x cape-file`.
Another way to think of it - Cape is to Corfu what Consult is to Vertico.
@minad @jameshowell @oantolin Wow, hello Daniel and Omar, so wonderful to run into you on here. Much respect for your contributions to making emacs usable for forever-noobs like me!
I think last time I used cape I couldn't understand how cape-dabbrev is different from dabbrev (I understand now...). I will give it a go too!
I am especially struggling with my python vterm REPL though. I see a wall-of-text dump of all the candidates from the code as well as the REPL buffer! Any pointers?
-
@minad @jameshowell @oantolin Wow, hello Daniel and Omar, so wonderful to run into you on here. Much respect for your contributions to making emacs usable for forever-noobs like me!
I think last time I used cape I couldn't understand how cape-dabbrev is different from dabbrev (I understand now...). I will give it a go too!
I am especially struggling with my python vterm REPL though. I see a wall-of-text dump of all the candidates from the code as well as the REPL buffer! Any pointers?
@tchauhan cape-dabbrev is similar to dabbrev-capf, but a little more polished. dabbrev-capf had bugs in the past, but I think they are fixed at least in Emacs 31. Regarding Python REPL completion I cannot help. All I know is that the Capf is broken. @jameshowell @oantolin
-
@tchauhan cape-dabbrev is similar to dabbrev-capf, but a little more polished. dabbrev-capf had bugs in the past, but I think they are fixed at least in Emacs 31. Regarding Python REPL completion I cannot help. All I know is that the Capf is broken. @jameshowell @oantolin
@tchauhan @jameshowell @oantolin You could try Drepl for a Python REPL with better completion. I have not used it so far, so I don't know how well it works in practice.
GitHub - astoff/drepl: REPL protocol for the dumb terminal
REPL protocol for the dumb terminal. Contribute to astoff/drepl development by creating an account on GitHub.
GitHub (github.com)
-
@minad @jameshowell @oantolin Wow, hello Daniel and Omar, so wonderful to run into you on here. Much respect for your contributions to making emacs usable for forever-noobs like me!
I think last time I used cape I couldn't understand how cape-dabbrev is different from dabbrev (I understand now...). I will give it a go too!
I am especially struggling with my python vterm REPL though. I see a wall-of-text dump of all the candidates from the code as well as the REPL buffer! Any pointers?
-
@kickingvegas I thought IMEs were mechanisms to type single characters and that most of them do not involve incremental completion and filtering!
EDIT: Your Wikipedia link agrees with my recollection. @jameshowell @minad
@oantolin @kickingvegas @jameshowell @minad Nah, not just character by character. Japanese IME for example you typically type in a whole sentence phonetically (and see the kana and first choice kanji appear as you go - sometimes that charges as you type in more giving it more context), then manually fix up any wrong inferences (eg left/right cursors to jump to position in sentence, then up/down or space/shift-space to cycle suggestions for that fragment). Then enter to finalise that sentence.
-
"The history of #Emacs completion frameworks is a progression from monolithic solutions toward composable ones."
This is a comprehensive summary, with a thorough and fair history. A long read, but worth it.
I plateaued at #Vertico #Orderless #Marginalia #Consult years ago. Maybe time to learn the others, one at a time.
VOMPECCC: A Modular Completion Framework for Emacs
Completion is not a feature or UI, but instead it is a system composed of at least half a dozen orthogonal concerns that most users never think about separately...
Charlie Holland's Blog (www.chiply.dev)
@jameshowell Composability, where each module does one thing well and has a clean interface to the others, is a worthy goal. But from the user perspective, completion _is_ one thing, so why should we need to coordinate and configure seven or eight packages to get it working?
Yes, as the article says, there are many _potentially_ orthogonal concerns in completion, but when you separate them into different user packages, you've pushed too much of the complexity of their interaction onto the user.
The solution, apparently, is to add another layer of abstraction: emacs configuration kits. It all seems a bit much.
-
R relay@relay.infosec.exchange shared this topic
