Finding a way to support Windows

[MatthewDarling]

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 :)

[kidd]

Hi @MatthewDarling. Thanks for investigating a bit on that.

My advice is to take a look at system-type function and check if it works for you distinguishing windows from cygwin (not sure as it says 'compiled with cygwin').

If the only thing that has to change is the tar command, you can move the string to a defvar, and initialize it with a function that checks the OS type and acts accordingly.

For the second part, we're not using esqlite anymore as it had issues with mac. meanwhile we use plain shell commands. probably a path issue.

[areina]

Hi @MatthewDarling , did you try something else? any progress? we could try to help you to debug, if not, I'm going to close the issue.

[MatthewDarling]

Oops, I had a draft message in my e-mail that I never sent. Sorry about that!

Anyway, what I had written was:

System type won't work in all cases for Windows, because I think it's based on how Emacs is compiled, rather than actually checking the OS - I think Win32 Emacs vs Cygwin Emacs have different system types. But I run Win32 Emacs + Cygwin for shell utilities, so you can get a mix of both :(

Something I thought of that should work for all Windows users would be to require them to install 7zip, which is LGPL software and has a command line version. So then you'd have a consistent interface to rely on without dealing with different versions of tar.

I'm busy this weekend, but maybe after that I'll be able to submit a patch of some kind.

[areina]

Thanks for the info @MatthewDarling . I'm looking forward to seeing that patch 🤘

[szhongren]

Not sure if this is still a thing you are working on, but I came across a weird fix for Windows, in Cygwin. Basically just take away one of the '/' from the file:/// string in the helm-dash-result-url function and it will now work with w3, lynx, etc. Still not sure how to make it work with the default browser in Windows but this is better than nothing.

[otsaw]

Another Windows user here. I'm not using cygwin, but Vincent Goulet's latest package, Emacs 24.4. I also have some gnuwin32 tools (like tar) in %PATH%. I got helm-dash to work just fine after minor fiddling.

• The tar command fails for me as well. I tried a couple different ways to specify helm-dash-docsets-path, but none worked. I got by unpacking manually from the temp directory. I hope a fix can be found, but I have none to suggest.
• Emacs's default Windows browser strips the anchor from the link. This seems to be a known bug. A manually defined browser works fine. So, no bug in helm-dash, but an FAQ entry could be useful.

(when (eq system-type 'windows-nt)
  (setq browse-url-browser-function 'browse-url-firefox)
  (setq browse-url-new-window-flag t)
  (setq browse-url-firefox-new-window-is-tab t)
  (setq browse-url-firefox-program "C:/Program Files (x86)/Mozilla Firefox/firefox.exe"))

And, thanks, I'm finding helm-dash very useful.

[kidd]

Thanks for the heads up!

From the top of my head, I think we could try to reuse 'Z' functionality from dired. Can you check if pressing Z when on a tar.gz file works on windows? If so, we may be able to use this function to make it multiplatform. I'd hate to have to "if" :)

We'll add the note in the FAQ (which I don't know if we currently have, lol ) regarding the browser.

Bye!

[otsaw]

No, dired Z doesn't work. It just tries to call gunzip and fails. (And I actually have gunzip in %PATH% provided by gnuwin32, but for some reason dired doesn't find it.)

Compress or uncompress Bash-docset.tgz? (y or n) y
Uncompressing c:/Users/osa/AppData/Local/Temp/Bash-docset.tgz...
*beep*
apply: Searching for program: no such file or directory, gunzip

I also tried tar-mode and calling tar-untar-buffer. It does work, but it too seems to call binaries (at least gzip) that most users don't have installed.

[jeeger]

Thanks to the other people in this thread, I have gotten helm-dash to work on Windows.

The key requirement was having a new enough version of tar (1.23 works, 1.13 was too old), and adding the --force-local argument to tar (this should be added on all platforms, as it won't make a difference on Linux and Mac OS). I've installed all dependencies via scoop.
Additionally, I had to set helm-dash-browser-func to eww, because file paths seem to be unsupported by the Windows open program that's used to browse urls by default.

I've also replaced the url- functions used in helm-dash with calls to curl, as I am behind a forced proxy, and Emac's proxy handling leaves some things to be desired. My fork with very smal fixes is available at https://github.com/jeeger/helm-dash/tree/windows-fixes.

[jeeger]

And an additional wrinkle of docsets containing files with invalid file name characters on NTFS (<>:"/\\|?*). I've tried fixing this with the GNU tar --transform option only on windows systems. To see an example for invalid characters, look inside the C docset, where there are several files that have a colon in their name. I've implemented this in jeeger/helm-dash@279fa5c.

[fleimgruber]

Good job @jeeger! do you plan to create a PR?

[jeeger]

It's available in PR #181.

[kidd]

That's awesome! thanks!

[kidd]

#181 has been merged! 🎉

[kidd]

@fleimgruber, could you try the latest version and tell us how it worked for you?

[fleimgruber]

Using helm-dash-20190316.2009 from MELPA works for me with docsets downloaded using Zeal.

[jeeger]

@fleimgruber Uh, you should be able to download docsets with helm-dash-install-docset now, as this is what changed. Zeal probably doesn't use the helm-dash functionality, or does it?

[fleimgruber]

Ah, then I misunderstood. I thought the docsets were stored locally as archives and any helm-dash lookup would use tar. I just tried and installed the Julia docset via helm-dash-install-docset. Works Over Here.

[kidd]

nice! Closing this one then.

Thank you all!