add support for ivy-mode etc completion system? about helm-dash

[areina]

Hey @nathankot,

this is so great. Yes, I agree that de-coupling it from helm could be very useful, we will work on that next days. Probably, the most difficult part will be choosing a name for it, because dash.el already exists and could be a bit confusing :)

[kidd]

We've been thinking about it for some time, but haven't dug into finding out whether it's a feasible thing to do. If it's easy, as in a 'drop in' replacement, I'm all for it. I doubt it's a drop-in replacement though.

Is there any major thing you want to do in ivy you can't do in helm?

[stardiviner]

No feature I want to in ivy which not exist in helm.
Just because helm is heavy comparing with ivy. So I switched to ivy. And I like the ivy style. (vertical display candidates in minibuffer).

[stardiviner]

I checked out helm-dash source code.
Search code with helm-[^dash].
I found only a few functions are used:

• with-helm-current-buffer
• helm-pattern

That's all.

[kidd]

that, and the call to helm itself. I'm taking a look at ivy-read function, and the signature is much more similar to ido than to helm.

Difficulties I see (after a not-very-deep read at the code):

• Dynamic-collection can be set to make new searches occur at every input. But no way to 'delay' or to set a 'minimum length'(although the later could be hacked into the callback).
• ivy doesn not deal with tuples (text . data) , but only selects text. it would be our job to keep a list of all text and data (docset/url/anchor) externally and match it afterwards.
• ivy does not provide a way to have multiple possible actions.
• I don't know how helm matchers work exactly, but I'm not sure I can replicate the same functionality in ivy.

All that doesn't mean it makes it impossible to do, but I don't think it pays off. We'd be replicating helm functionality on top of ivy. maybe a different option (much more ambitious) would be to change helm's input method to ivy. But it would defeat the purpose of lighter helm, as it'd be helm (minus input parts) + ivy.

It seems ivy is much more simple than helm, and more similar to ido, so I'd say they are 2 different animals. The use cases they overlap are the simple ones

[stardiviner]

I see. Thanks still.

[abo-abo]

Hi, I saw a link here from reddit. The mentioned functionality seems very easy to implement, since it's similar to e.g. counsel-locate. I don't have OSX so the code isn't tested, but it should be close to complete.

(defun counsel-dash-collection (s &rest _)
  (if (< (length s) 3)
      (counsel-more-chars 3)
    (list "aaa1"
          "aaa2"
          "aaa3"
          "aaa4")
    ;; (let ((helm-pattern s))
    ;;   (helm-dash-search))
    ))

(defun counsel-dash ()
  (interactive)
  (helm-dash-initialize-debugging-buffer)
  (helm-dash-create-common-connections)
  (helm-dash-create-buffer-connections)
  (ivy-read "Dash: "
            #'counsel-dash-collection
            :dynamic-collection t
            :history 'helm-dash-history-input
            :action
            '(1
              ("o" helm-dash-browse-url "Go to doc")
              ("k" helm-dash-add-to-kill-ring "Copy to clipboard"))))

set a 'minimum length'(although the later could be hacked into the callback)

This is done in the collection function itself via counsel-more-chars (a very short function).

ivy doesn not deal with tuples (text . data) , but only selects text

This should work fine, as long as the collection returned is (("text1" . data1) ...); the data part can be as complex as you wish. The action will be called with data1 right away, not '("text1" . data1), which makes it compatible with helm. See counsel-rhythmbox reusing all helm-rhythmbox functions verbatim.

ivy does not provide a way to have multiple possible actions.

It's possible, see the code above.

I don't know how helm matchers work exactly, but I'm not sure I can replicate the same functionality in ivy.

In ivy, you allow the user to customize ivy-re-builders-alist per command. Or you can pass :matcher to ivy-read if you want to handle everything yourself.

It seems ivy is much more simple than helm, and more similar to ido, so I'd say they are 2 different animals. The use cases they overlap are the simple ones

I try to make Ivy as simple as possible, while still doing all the cool stuff. For instance, ivy-call/multiple actions/ivy-resume are similar to what Helm can do. And features like ivy-hydra and ivy-occur aren't in Helm by default.

[kidd]

Thanks @abo-abo.

As I see it, wouldn't it make sense to have some kind of helm-to-ivy decorator (or advice, or whatever) that would avoid duplicating the modules that use each one of the functions that use helm? something like ivy-everywhere? I guess it's not easy to cover all the cases.

But anyway point taken, with some work, but not much we could add compatibility for both systems.

Thanks again

[abo-abo]

I guess it's not easy to cover all the cases

I couldn't manage to learn Helm's full API, there's too much stuff getting passed around, and Helm gets updated a lot. Even ivy-read, which should ideally be the only entry point into Ivy already takes 15 arguments, up from completing-read's 8.

If there's any compatibility to be had, it has to come through extending completing-read's API, and having all completion systems conform to that API. We have that now, but it's too narrow, you can't do everything through completing-read. Maybe after Emacs25 some work could be done on this.

[stardiviner]

@abo-abo Thanks, I will create my custom port. put file locally.

[nathankot]

Here's my implementation:

(defvar counsel-dash--results nil)

(defun counsel-dash-collection (s &rest _)
  (if (< (length s) 3)
    (counsel-more-chars 3)
    (let* ( (helm-pattern s)
            (results (helm-dash-search)) )
      (setq counsel-dash--results results)
      (mapcar 'car results))))

(defun counsel-dash ()
  (interactive)
  (helm-dash-initialize-debugging-buffer)
  (helm-dash-create-buffer-connections)
  (helm-dash-create-common-connections)
  (ivy-read "Documentation for: "
    'counsel-dash-collection
    :dynamic-collection t
    :history 'helm-dash-history-input
    :action (lambda (s)
              (-when-let (result (-drop 1 (-first (-compose (-partial 'string= s) 'car) counsel-dash--results)))
                (helm-dash-browse-url result)))))

Note that:

• (require 'dash)
• helm-dash-search is deprecated (replaced with helm sources in helm-dash)

[stardiviner]

@nathankot this implement works find.

Yeah, it does work. Awesome. Seems the result list face need some improvements.
Helm seems grouped the result:

Here is the counsel-dash

Does someone already working on this? Or should I try?

More functions need to be switched to ivy, I think.

[kidd]

I'd recommend to open a PR with this code, and make it the most compatible we can with the other options (no magic numbers, etc) Then we can think on merging it when the functionality surpasses some completeness level (I'd say we're kinda there already)

[nathankot]

@kidd I'm happy for someone with copyright assignment for swiper to take the code and make a PR with it :) I haven't gone through the process and a month seems like a long wait tbh

[abo-abo]

@nathankot I think your code belongs in either helm-dash or a stand-alone package depending on helm-dash. It's not always the best idea to put everything in counsel. See for instance, counsel-projectile - a nice stand-alone package that depends on projectile and ivy. No CA required in that case, obviously.

[nathankot]

@abo-abo true :) I'll find some time and release this as a separate package, not sure if it belongs in helm-dash given its strong ties to helm.

I've also written a counsel-flycheck, will do the same for that.

[kidd]

We could start by adding it in contrib in the beginning (to have the code somewhere else appart from in this issue).

After that, maybe have a variable in helm-dash to be able to decide which frontend do we want to activate.

However, I'm not sure if this is a real solution or just buys us a bit of time in exchange for added complexity and compatibility enforcing in the future.

[stardiviner]

I prefer this way.

[nathankot]

Hey guys,

I've released counsel-dash which is pretty much the code above wrapped up.

I'm hoping that helm-dash can de-couple itself from helm, and offer a separate dash-only library so that users of counsel-dash don't have to install helm. Then I can update counsel-dash to depend only on the dash specific library :)

[nathankot]

@areina awesome :) Give me a ping when it's been de-coupled.
Agreed with the naming haha - perhaps dash-docsets.el or docsets.el?

Ha, this is happening. 👍

[areina]

Closing this issue after 3 years and 1 day 😄

• https://github.com/dash-docs-el/counsel-dash
• https://github.com/dash-docs-el/dash-docs