It would be great to have the hard work put into this package to interact with Dash docsets available to other packages without requiring any dependencies on helm. I personally use counsel-dash in my configuration which depends on helm-dash and as a result requires that I load helm as well. This would additionally encourage other packages to be created that can leverage dash docs as well.

To this end I've got a work in progress implementation of this separate library along with what I think is a smooth transition path forward for both helm-dash and counsel-dash. I've created a separate project for an elisp package called dash-docs. I created the dash-docs repo using the helm-dash repo to retain full git history since most of the functionality remains unchanged apart from being renamed. I'll also mention, that if this proposal is accepted I will be happy to transfer ownsership of this repository.

This new package dash-docs.el contains most of the dash specific code and both helm-dash.el and counsel-dash.el will depend on this common package. I've also updated both packages to maintain their current user interface requiring no changes to downstream users and simply use this new package to drive all of the dash specific logic.

Updated Repositories:

• dash-docs: https://github.com/gilbertw1/dash-docs
• helm-dash: https://github.com/gilbertw1/helm-dash
• counsel-dash: https://github.com/gilbertw1/counsel-dash

Proposed Migration Strategy:

• Publish dash-docs package to MELPA
• Publish new version of helm-dash that depends on dash-docs
  • counsel-dash will still function properly as it depends on functions still exposed in helm-dash
• Submit PR / Publish new version of counsel-dash

Things Left to Do:

1. Create new README.md in dash-docs repo.
2. Verify tests, perform additional testing, minor cleanup.
3. Verify each step in "Proposed Migration Strategy" will not break anything for existing users.

Sorry for the long issue. Please let me know what you think about this proposal and if you'd like me to change anything about it or if you see any problems proceeding this way.

Thanks!

I hope dash.el can add support for other completion systems like ivy-mode. helm-dash should add a customizable variable helm-dash-completion-system so that user can set user own favourite item like ido, ivy etc.

I know, I know, boo Windows, but let's see if we can't figure this out.

tar and weird paths

Emacs seems to do a good job of handling weird paths: for instance, directory-files correctly lists the files for the string "C:\\Users\\Matt\\/.docsets". So that's great, but external programs will have trouble with that.

Sadly, there may need to be two special cases for Windows users here: one for people who use Cygwin, and one for more Windows-like versions of Unix programs (GnuWin32, UnixUtils, MsysGit, etc). I use Cygwin, so what follows works for me, but it should probably be the backup case if the default fails.

The first hangup is when using helm-dash-install-docset. Under Cygwin, the only way I could get tar to work was to use the cygpath program to convert the target file to an absolute path. helm-dash-docsets-path seems to work as-is though, strangely. Working example, with a pre-downloaded archive:

(let ((testing "C:\\Users\\Matt\\.docsets\\LaTeX.tar.bz2"))
    (shell-command-to-string (format "tar xvf %s -C %s"
        (s-trim (shell-command-to-string 
            (format "cygpath -a %s" testing))) helm-dash-docsets-path)))

With cygpath, -a generates absolute paths, and it looks like shell-command-to-string keeps the trailing newline, so I'm trimming that with s.el.

If I add a call to cygpath in helm-dash-install-docset, I can in fact get docsets installed. Yay! But I don't know the best way to conditionally activate the cygpath conversion. Maybe try tar without, then it if fails, check for a cygpath executable on $PATH, and use it if one is found?

That is, assuming other distributions of Unix utilities opt for a more Windows-like approach, and should handle normal Windows paths. That being said, I've tested a bit with the MsysGit version of tar, and it seems to suck just as much as the Cygwin version - I couldn't get it to work at all with any absolute path, only relative ones. Sigh.

Beyond tar

With the Emacs Lisp docset installed, and this line executed:

(setq helm-dash-common-docsets '("Emacs Lisp"))

I don't get any results from running helm-dash, no matter what I type. I've installed esqlite, and pcsv, and they seem to at least load correctly. I'm not getting any error messages or warnings. At this stage, I don't have an easy guess for what the error might be. I'd be happy to test any likely sources of errors, though :)

Since I am on Windows, I have to use Zeal as my document browser. Zeal creates a subfolder /Doc where all docsets live in. Like so: "../Zeal/Doc/Python_3.docset" I understand that these are the same as in dash? Is there a way to use these docsets with helm-dash? I already tried: (setq helm-dash-docsets-path "C:/Users/my.name/Apps/ZealPortable/Doc/")

Using helm-dash after installing Python_3 docset via helm-dash-install-docset on OS X gives the error (see below for full Backtrace):

esqlite: "Stream buffer has been deleted"

How can I debug this further? Is relevant information missing?

Used Versions: helm-dash from MELPA (20140114.1710) esqlite from MELPA (20140115.728) emacs 24.3.1 (x86_64-apple-darwin)

Backtrace:

Debugger entered--Lisp error: (esqlite-error "Stream buffer has been deleted")
  signal(esqlite-error ("Stream buffer has been deleted"))
  esqlite--error("Stream buffer has been deleted")
  esqlite-stream-read(#<process Esqlite> "SELECT name FROM sqlite_master WHERE type = 'table' LIMIT 1")
  helm-dash-docset-type(#<process Esqlite>)
  #[(x) "\303  \"?\205

Fixes #80.

stderr from sqlite3 is sent to a file, which is then displayed as a buffer if it contains any text after the command has finished. This is based on the shell-command function, which seems to be the only one which provides useful error handling (but shell-command is not general enough for us to use directly).

Additionally by using call-process instead of call-process-shell-command we get an error if the sqlite3 command cannot be found (my comment below was wrong, I didn't reset the connections properly when I tested it).

Finally I thought that helm-dash-sql was getting a bit too complicated and messy after these changes, so I moved the parsing out into a separate function.

Hello,

I can not get helm-dash to provide any candidate even though docsets seem to be installed correctly and variables set up just as well.

I am using Emacs 24.3.1 on MacOSX Mavericks, and have not yet tested on other platforms. helm-dash is master merged with #40.

Here is my configuration: https://github.com/jwintz/prelude/blob/master/personal/prelude-dash.el.

How can I debug docset queries ?

I'm using Emacs 24.3.1 on Macos. It seems that url browsing does not work. When I try:

(browse-url "file:///Users/asok/.docsets/Ruby on Rails.docset/Contents/Resources/Documents/api.rubyonrails.org/v3.2.16/classes/AbstractController/Callbacks/ClassMethods.html#method-i-append_before_filter")

In the *Messages* I see:

#<process open file:///Users/asok/.docsets/Ruby on Rails.docset/Contents/Resources/Documents/api.rubyonrails.org/v3.2.16/classes/AbstractController/Callbacks/ClassMethods.html#method-i-append_before_filter>

And no browser's window is opened. Though when I strip the #target part of the url:

(browse-url "file:///Users/asok/.docsets/Ruby on Rails.docset/Contents/Resources/Documents/api.rubyonrails.org/v3.2.16/classes/AbstractController/Callbacks/ClassMethods.html")

The browser window is opened with the html file.

It might be the bug mentioned here (under the section named: "Bug" in browse-url-default-windows-browser).

Maybe it's worth mentioning that in the README.

I install helm-dash through el-get. And configure it with:

(require 'helm-dash)

(setq helm-dash-docsets-path (expand-file-name "~/.docsets")
      helm-dash-min-length 3
      ;; helm-dash-completing-read-func 'completing-read ; 'completing-read, 'ido-completing-read
      helm-dash-browser-func 'browse-url ; 'browse-url, 'eww
      ;; helm-dash-connections
      helm-dash-common-docsets '("Ruby" "Ruby on Rails"
                                 "HTML" "CSS" "JavaScript" "CoffeeScript"
                                 "Common_Lisp" "Clojure"
                                 "C" "Go"
                                 "SQLite" "MySQL" "Redis" "MongoDB"
                                 "Qt"
                                 "Vagrant" "Nginx"
                                 )
      ;; helm-dash-docsets
      )
(define-key help-document-map (kbd "C-d") 'helm-dash-at-point)

After download docsets with helm-dash-install-docsets. And when I execute [M-x helm-dash]. It only show Ruby nil or Ruby on Rails nil. I also tried command helm-dash-active-docsets. None of them can work correctly.

I tried to install the Common Lisp and the CoffeeScript docs on Mac OS X 10.8. Both failed with this error message

gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly terminated.

Afterwards calling helm-dash will result in

esqlite--error: esqlite: "unable to open database \"~/.docsets/Common_Lisp.docset/Contents/Resources/docSet.dsidx\": unable to open database file
"

From @agpchil 's code, I did my take on the filtering. Not very clear which is the best approach. As it is now.

We don't have a way to deactivate a docset via elisp. The 'active' docsets are all the docsets installed in the machine. Then the filtering is ment to be done on a per-buffer basis.

If there's no modification of the per-buffer, we use the global one, which has everything.

Some metrics (as of Jun '22):

• Last project commit is 3y ago.
• 21 open issues (oldest from 2015), with support (non-feature) requests unanswered since 3y ago.
• 8 open PR (oldest from 2016), incl. 4 without any review dating 4y ago (even a trivial doc fix from mine at #200).

I'm experiencing some already reported, unresolved, issues. For those like me looking for alternatives, you might want to check these packages:

• https://github.com/blahgeek/emacs-devdocs-browser
• https://github.com/astoff/devdocs.el

@areina Minor readme fixes. Also pinging about maintenance status, since there are a handful PR and maybe nobody got ~noticed~ notified, as it's owned by an org, and notifications are going unnoticed.

This relates to the following issue in helm.

https://github.com/emacs-helm/helm/issues/2417

The issue is that helm-dash uses :candidates instead of :candidates-process. In terminal emacs, this will break because a C-g is generated by typing quickly as the terminal will hang while generating candidates with the external process.

(defun helm-dash--build-source (docset)
  "Build a Helm source for DOCSET."
  (lexical-let ((docset docset))
    (helm-build-sync-source (car docset)
      :action-transformer #'helm-dash-actions
      :candidates (lambda ()
                    (cl-loop for row in (helm-dash--run-query docset helm-pattern)
                             collect (helm-dash--candidate docset row)))
      :volatile t
      :persistent-help "View doc"
      :requires-pattern helm-dash-min-length)))

That would require some re-engineering. Alternatively, a inhibit-quit can be placed inside the lambda. This would fix it for terminal emacs.

Here is an example of the correct way to implement a source by using an emacs process.

https://github.com/emacs-helm/helm-notmuch/blob/97a01497e079a7b6505987e9feba6b603bbec288/helm-notmuch.el#L74

I have installed the plugin, downloaded the docs I needed, and (snippet from the FAQ) configured the plugin to open docs in firefox like so:

(setq browse-url-browser-function 'browse-url-generic
    browse-url-generic-program "/Applications/Firefox.app/Contents/MacOS/firefox")
(setq helm-dash-browser-func 'browse-url-generic)

Trying to open documentation for a particular symbol returns a 'file not found' in firefox however.

This was the url helm-dash produced: file:////{home directory}/Library/Application%20Support/Dash/DocSets/Python_3/Python%203.docset/Contents/Resources/Documents/doc/library/enum.html#//apple_ref/Module/enum

browsing this path in finder, I found that the file with the desired contents in fact had the location:

file:///{home directory}/Library/Application%20Support/Dash/DocSets/Python%203.docset/Contents/Resources/Documents/doc/library/enum.html

The difference in the paths (besides from the html anchor) is "Python_3" subdirectory in Dash/DocSets/.

The file .../Dash/DocSets/Python_3/Python%203.docset does exist though, but it doesn't actually contain the docset - the package with the right docs is in the parent directory.

(package with correct docs circled in green, package helm-dash generated a link for circled in red)

It looks like either the documentation package was installed in the wrong location, or helm-dash is generating the wrong path to browse to it.

As a workaround for now I have moved the docset with the correct contents into the Python_3 subdirectory, overwriting the other one, and now the plugin is working as expected.

The first lines of the comment header of dash-docs.el., is a paste of the one of helm-dash.el. So it gives as url http://github.com/areina/helm-dash instead of https://github.com/dash-docs-el/dash-docs. And the wrong url is also used in melpa, so when you want some info about the package you are redirected to helm-dash. Please correct this url. (I am to lazy to make a pull request for this tiny detail.)