-- Leo's gemini proxy

-- Connecting to tilde.team:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini; lang=en

Emacs Configuration Refactoring

Back


I'm going through a refactoring stage where I wanted to try the new wave of completion packages that are available; namely Vertico, consult, embark, corfu, cape, orderless and marginalia.


Overall the experience is very nice; every package is an improvement of some aspects of the packages it replaces. We are talking about helm and company, mainly.


Instead of helm, vertico is the UI of the completion; running in the minibuffer, but it doesn't make a difference. Consult is a collections of functions that are similar to what helm can do, see


helm presentation.


Embark represents new functionality: based on what's on point, it offers collection of functions to deal with it: whether it's a function, symbol, file, link, etc. It combines nicely with consult. You actually need embark to make the completion items an input to the consult functions. Next is corfu, a pop up completion UI, similar to company, but nicer, simpler and faster. Cape is a collection of sources for corfu. Company comes with its own sources, or backends; now you need corfu with cape to get the same functionality but it works better, for example for Hebrew. Marginalia presents metadata related to the completion data in vertico. It's very nice, for example it shows emojis as you insert them using `C-x 8 RET'. Finally, orderless is a fuzzy completion style; similar to the built in helm completion style helm used.


I also decided to try citar, which is a citation framework, using org-cite. I previously played with it; its completions didn't render correctly in helm, they required vertico + marginalia to look good, so that was a good opportunity. One nice addition is the ability to open the zotero item and open the pdf with a single click, using embark-dwim.


I had some minor bugs. Mini buffer completions needed some small code snippet to work. Elpy uses company (hard coded) so I still need it in my system. Corfu needs to be disabled in python buffers. I created a small embark keymap so two functions I use a lot (fd and rg searches) are easily available.


Some packages that depend on helm: org-ql, but it can work without helm. Org-ref, replaced with citar. Helm-org-rifle, there's some similar functionality in consult. Helm-eww but I don't really use it.


Overall, very little friction, I was surprised by that. I didn't try/move earlier because I thought I'm so invested in helm, I have so many customize pieces of code, I don't want many package to replace 1 package, I won't have all the functionality I was used to with the new packages. Turns out, it was quite easy. It's true, there are multiple packages, but each one of them is very small, usually a single file, with a few hundred lines of code. The config for each is very short and simple. I had to config stuff and even write custom code in order to achieve what I had with helm but it doesn't mean it's a general thing; I used specific features in helm and I developed a few myself. Of course I need to configure these new packages to adapt to how I'm use to doing things; it's not a bad thing.


A few things that need to be adjusted:

The corfu autocomplete still annoys me.

Flyspell wrapper needs to be adjusted.

Embark act doesn't work in `orgmode' because of key conflict.


I'm working on a consult/embark version of the helm-mu plugin. I've worked on it for a couple of days. It's still in an early stage. In order to get it to work I need to learn about helm, consult, marginalia and maybe even vertico. So, a lot of background knowledge in order to get it to work. What would happen if a just install `helm-mu'? Well, I installed it and it works. It installs helm, obviously, but helm doesn't get in my face; everything is still vertico et al. I just get to use helm-mu when I need to, while enjoying the new stack. Then I realized that it's a new way of thinking; I thought that I either use helm or I use vertico el al. I can't use both, I can't even have them both installed at the same time. Obviously, I was wrong. There is not any technical reason preventing installing both of them, or using both of them, maybe not at the same time. It was just in my head, this dichotomy, that I could either use helm or the new stack, but not both, never both. I realized that I can even run `helm-find-files' if I want to. I can do *whatever I want*. There are no rules; if it's possible in terms of code, I can do it. And even code can be changed and modified to do what I really want.


What led me to this dichotomy? First of all I think we all tend to think in terms of "either or" for some specific topics in our lives, details may vary. For one, it could be a brand of shampoo, for another it could be the nature of some relationship. For me, it's how I used some of my tools, for which I do spend a lot of time thinking about. Secondly, there are a lot of blogs about people switching from "old" completion frameworks like helm and ivy to the new stack. Going over some of them, the main narrative is "out with the old, in with the new", old/new dichotomy.


Either way, I'm testing the new stack, adding features I like and need using the new code conventions, or just use `helm' when I can't seem to adapt the new tools to my needs. Eventually, either I'll learn how to create them, someone else will create them for me to use, or my way of doing things will change. And that's fine with me.

-- Response ended

-- Page fetched on Wed May 1 14:20:08 2024