abo-abo / lispy

Short and sweet LISP editing
http://oremacs.com/lispy/
1.2k stars 130 forks source link

Allow replacing counsel with something else #610

Closed akirak closed 2 years ago

akirak commented 2 years ago

Hello, I have noticed that this package depends on counsel. It was a great package, and I have used it in many parts of my config and also wrote several ivy-based packages, but recently the situation has changed.

After the rise of modular completion packages such as vertico, orderless, marginalia, and embark, it is now possible for users to replace ivy/swiper/counsel with a different stack. I'm sorry, but there would be users who don't want to install ivy but still want to use lispy, this package. It would be better to make the dependency on counsel optional.

Counsel is only required inside lispy-goto-local to call counsel-imenu, so I think it is easy to replace it.

abo-abo commented 2 years ago

Fixed via #611. Thanks.

aaronjensen commented 2 years ago

Hi @abo-abo thanks, though now we have a dependency on swiper, which still brings ivy. The PR in #611 dropped it entirely, which would be preferred. Is there a path to that?

abo-abo commented 2 years ago

@aaronjensen There's no way to remove the dependency without losing functionality. lispy-occur depends on swiper. And many other code parts depend on ivy-read. Since completing-read doesn't support :action, there's no way to remove the dependency on ivy.

aaronjensen commented 2 years ago

Got it, thank you.

jdtsmith commented 2 years ago

I too would love to see ivy made an optional dependency. It seems to me that consult is the closest analog among the modern completing-read interfaces and add-ons that could offer the same functionality. Tagging @minad in case he has an idea of how to preserve functionality without hardcoding the swiper/ivy dependency.

minad commented 2 years ago

@jdtsmith I am not familiar with the Lispy code base but one could probably support other UIs by relying on plain completing-read and adding the actions afterwards via Embark. This would even work for Ivy since Embark also supports Ivy. However in order to preserve the existing UI exactly, one should use the Ivy native functionality if Ivy is installed. Therefore an abstraction over the frontends would be needed, which could be configured via a variable lispy-completion-ui = ivy, default, ... I am convinced it is possible to do this but it needs someone interested in implementing it. Of course this makes only sense if @abo-abo agrees and is interested in going that route. There is certainly a maintenance cost involved.

jdtsmith commented 2 years ago

Thanks for these thoughts. The ivy/swiper-dependent bit is lispy-occur — "Select a line within current top level sexp.". But the ivy-action it configures just goes to that line upon selection. So this looks basically like consult-line with region narrowed to the sexp. I suspect that's easy for a user to configure, ala:

(defun my/lispy-consult-line (arg)
  (interactive "p")
  (lispy-narrow arg)
  (consult-line)
  (lispy-widen))

So maybe the simple fix for consult users is not to require swiper at the top level, but arrange for it to be require'd if and only if lispy-occur is called.

aaronjensen commented 2 years ago

I opened #616 for discussion. It will at least ensure that swiper/ivy are not loaded unless you do something that requires them. There are still all of the calls to ivy-read, so that may be hard to avoid in practice.