Just need to add a .gitkeep file under doc/

It appears it was broken by this commit c3510ae

We'll use panvimdoc to auto-generate the documentation

It's not too bad, but it can be slightly slow at times due to the way it runs the searches for each keyword sequentially, instead of in parallel.

There's probably a way to make it more async, but I don't really have the expertise to do so.

see: https://github.com/mrjones2014/dash.nvim/blob/master/lua/dash/utils/telescope.lua#L43

There are some tests, but not really enough. We should add additional test coverage.

https://github.com/sunaku/dasht

https://zealdocs.org/

A Linux client to download and search docsets, just like Dash, but without needing the actual Dash.app since that's a macOS app.

We can probably detect whether we're on macOS or Linux, and use a different backend on Linux. Likely will need a separate Rust backend for Linux.

This will also require tweaking the config a bit I think.

It should appear in the list if you run :Telescope

When searching with keywords, put them in the title.

Is it possible to enable previews? Might only be possible in GUI vim since the docs are HTML documents.

It seems to be querying the value instead of the query.

For example, when you have a yml file open, you get this error:

Related to: #25

You can use the Rust backend directly to implement whatever you want with it.

https://github.com/liuchengxu/vim-clap

The last thing this file does is open the selected item in Dash. We should move all core Dash functionality into the Rust backend.

A security vulnerability was found that's been patched. https://blog.rust-lang.org/2021/11/01/Rust-1.56.1.html

I accidentally left some print calls in telescope.lua.

ibhagwan/fzf-lua#57 (comment)

The plugin was working at earlier points but since recent updates it stopped working. On the latest master as of today (791281f) and NVIM v0.6.0-dev+1984-g09e96fe60:

Error detected while processing $HOME/.dotfiles/vim/plugged/dash.nvim/plugin/dash.vim:
line   16:
E5108: Error executing lua 
$HOME/.vim/plugged/dash.nvim/lua/dash/config.lua:6: module 'libdash_nvim' not found:
        no field package.preload['libdash_nvim']
        no file './libdash_nvim.lua'
        no file '/usr/local/Cellar/luajit-openresty/2.1-20210510/share/luajit-2.1.0-beta3/libdash_nvim.lua'
        no file '/usr/local/share/lua/5.1/libdash_nvim.lua'
        no file '/usr/local/share/lua/5.1/libdash_nvim/init.lua'
        no file '/usr/local/Cellar/luajit-openresty/2.1-20210510/share/lua/5.1/libdash_nvim.lua'
        no file '/usr/local/Cellar/luajit-openresty/2.1-20210510/share/lua/5.1/libdash_nvim/init.lua'
        no file './libdash_nvim.so'
        no file '/usr/local/lib/lua/5.1/libdash_nvim.so'
        no file '/usr/local/Cellar/luajit-openresty/2.1-20210510/lib/lua/5.1/libdash_nvim.so'
        no file '/usr/local/lib/lua/5.1/loadall.so'

Environments: Mac OS 11.6, x86_64 (Intel)

This is because the prebuilt binary is only provided as *.so shared module; macOS would require *.dylib.

I think recent changes on the bin/ structure broke the plugin. (commit dfd928c, since v0.4.0)

I'm coming from dash.vim, which has a feature to search for the word under the cursor. (Optionally?) Having the telescope window auto-populate with that word would be helpful.

However, I found that this didn't always work as well as one would like, because the method searched could sometimes belong to quite a few different types of classes. For example, open in Ruby, which in Dash gives results for 36 objects. So my dream feature would be to use the LSP and/or Treesitter to lookup the docs for the method on the correct object type. In other words, var_that_is_a_tempfile.[o]pen (with the cursor on the o) would open the docs for specifically Tempfile.open.

There's a missing test. We're testing the cases where you set the file type keyword to boolean true, and to a table, but we should also test the case where you set it to a string.

e.g. if we specify

yaml = { 'yaml' , '' }

it should search both with the yaml keyword and with no keywords

Installing with packer with use({ 'mrjones2014/dash.nvim', requires = { 'nvim-telescope/telescope.nvim' }, run = 'make install' }), I get a "Failed to install" when running a PackerSync. Thereafter, I get "module "libdash_nvim" not found, did you set up Dash.nvim with make install as a post-install hook?"

Debugging a bit, I found two things:

1. Git times out frequently: ...m/site/pack/packer/start/packer.nvim/lua/packer/jobs.lua:87: Killing git due to timeout!. Now, the connection I'm on is a little weak, but it still downloaded from github at ~500kb/s. I worked around this for now by increasing timeout to 120s (from 60s). None of my other plugins needed this, though...
2. Having worked around that, the post install hook doesn't seem to run? After the packer sync, I guess it tries to load the module, because the debug log shows "Vim(lua):module "libdash_nvim" not found, did you set up Dash.nvim with make install as a post-install hook? See :h dash-install". So maybe that failing is preventing the hook from executing?

I solved the problem for now by cding to the dash dir and running make install manually.

Right now the query building based on the buffer type happens in the telescope utils file. In order to support other fuzzy finders (see #25) we should offload that to the backend and make the Rust code responsible for building the query based on the filetype.

Most likely this requires putting the config module in the backend as well.

In the case a search doesn't come up with anything, it would be nice if there would be a search the web fallback, like the Dash app has, so I don't have to go open my browser and type the same thing in again.

Awesome idea and execution by the way, this has sped me up so much, especially when working with a language I'm not too familiar with. Love it. Thank you 🙏

For example, in a typescript file, it will search with typescript keywords. But there should also be a way to do a search with no keywords. Possibly something like :Dash all or :Dash false or something. Not sure exactly how it should work.

We can use require('plenary').reload(). This should only be used during development really.

I'm not sure if the config will work if its in the Rust backend but lets try it.

https://github.com/Yggdroot/LeaderF

v0.5.0 added a new API methods

Feature request: It would be good to have :Dash <query> (e.g., :Dash blah blah) for a command that launches the telescope window with <query> as a initial query (like :DashWord).

When we call require('dash').setup({ dashAppPath = '~/Applications/Dash.app' }) we should expand the ~. Currently I don't think it gets expanded so you need to use os.getenv('HOME') instead of ~.

There's a few different crates to support Lua bindings in Rust

• https://docs.rs/hlua/0.4.1/hlua/
• https://github.com/jcmoyer/rust-lua53
• https://gist.github.com/jansegre/043f5ab7f53e23890eed

We should experiment with writing a Lua API directly embedded into the Rust backend. This will likely be a lot faster than running it via the CLI with plenary.

Basically, the Rust backend should expose a single function, require('dash-backend').query({ dash_app_path = "/Applications/Dash.app", query1, query2, ... }) and return a Lua table directly, instead of outputting JSON on the command line.

I've got the React docset installed, and some searches work perfectly:

But other searches return nothing:

Compare the above to the Dash app results:

I've looked briefly into how the query thing works and it looks like it calls "/Applications/Dash.app/Contents/Resources/dashAlfredWorkflow" with the query, I can confirm that it returns some results, here's what gets returned:

https://gist.github.com/marcusbuffett/b3490d47696c7240d3f77daa03aae245

Let me know if there's any debug info that could be useful.

It checks only for telescope currently.

Instead of passing the full list of queries to the backend, we should be able to just pass the current file type, the prompt, and whether it was triggered with the bang (!).

This might require moving the config itself into the Rust code as well, but I'm not sure if/how that will work.

Love this! I imagine that since you don't use fzf-lua you'd likely not want to spend time adding support. I haven't dove deep into this repo yet, so forgive me if this already exists.. would you be willing to add some sort of provider so that other pickers might be used?

Thanks!

(PS. I'd be interested in adding fzf-lua support if you were up for having that added)

example here https://github.com/michaelb/sniprun/blob/master/lua/sniprun.lua#L311

https://emmylua.github.io/annotations/class.html

Add another line to the file:

autocmd BufRead,BufNewFile *.handlebars set filetype=handlebars

For example, in a Javascript file, Javascript results should show up first. WIP experiment on branch: https://github.com/mrjones2014/dash.nvim/tree/matjones/sort-by-filetype

we have 2 constants files. now that rust lua module is working we should only have 1

The README has some broken links to. Busted, Luaassert, and Plenary.

When the Rust backend is passed the --pretty-print option it should pretty-print the output JSON.

An example: https://github.com/nvim-lualine/lualine.nvim/blob/master/lua/lualine/utils/notices.lua

Maybe just show a message via vim.api.nvim_err_writeln when there are breaking changes, and inform the user to run a (new) command like :DashNotices that will show any new breaking changes.

The only one in there currently is handlebars filetype detection. If someone is using Handlebars, chances are they're also using a plugin for it, and filetype detection shouldn't be a concern of this plugin.

https://github.com/camspiers/snap

It seems in the Lua world, pretty much everything uses snake_case. Let's migrate everything from being camelCase to snake_case.

Original request from #26

my dream feature would be to use the LSP and/or Treesitter to lookup the docs for the method on the correct object type. In other words, var_that_is_a_tempfile.[o]pen (with the cursor on the o) would open the docs for specifically Tempfile.open.

I'm not sure how we'd implement this but I think it might be possible via LSP info or TreeSitter.