Use of dyre

[osa1]

We talked about this in neovim gitter channel yesterday. I don't know a lot about XMonad, so when someone say "XMonad-like plugin management" it doesn't mean anything to me. I feel like we've already hand-rolled all the infrastructure and we don't need dyre for anything now, but I'm not sure. @saep do we still need it? Can we implement an example that uses dyre features and document how it works?

[saep]

I think dyre (or at least something similar) is very convenient for developing plugins. With dyre, you are able to recompile the plugin code you are working on and test it within the same neovim instance without having to restart neovim. (Ideally, we would not even have to restart the plugin provider explicitly in neovim.)

Anyhow, I explain the simplest usage scenario without going into detail why you have to do it that way. Most of the paths etc. are configurable.

Assuming we have two cabal libraries that provides some plugins for our plugin provider. To use those plugins, we have to create a custom nvim-hs binary that contains the libraries. This can be done quite conveniently with dyre. Just create the file ~/.config/nvim/nvim.hs with the following content.

import Neovim -- Our basic API

import qualified Neovim.Plugin.ExternalPluginFromLibrary (functions)
import qualified Neovim.Plugin.ExternalPluginFromAnotherLibrary (functions)

main = neovim def {
    , functions = functions def -- Maybe we provide some by default
                        <> Neovim.Plugin.ExternalPluginFromLibrary.functions
                        <> Neovim.Plugin.ExternalPluginFromAnotherLibrary.functions
    }

If we start nvim-hs, possibly from within neovim with rpcstart(), the dyre library will test whether it has to recompile the binary (e.g. ~/.config/nvim/nvim.hs has been modified) and eventually do so. After that, it will replace the current nvim-hs process with the custom binary in place, which is conceptually the same as calling exec in a shell script. The plugins are now available in neovim.

To install new plugins, you just have to add new imports and those functions to the configuration options as before. Then we have to instruct nvim-hs to recompile (possibly via a default plugin) and the new plugins are immediately available.

You don't even need cabal-ized plugins. You can just dump the code for a plugin inside ~/.config/nvim/nvim.hs and add the functions to the list. Additionally, you can drop haskell files inside ~/.config/nvim/lib/ in import them. Say we create the file ~/.config/nvim/lib/Custom/Plugin.hs, then we can import it directly with import Custom.Plugin inside ~/.config/nvim/nvim.hs.

I think this is a nice way to manage and handle plugins, but maybe I am just used to XMonad too much.

[saep]

We could nevertheless make dyre optional, either by providing a flag or by creating an additional package (e.g. nvim-hs-dyre). But until we actually do a release, it is (still) more convenient to have everything in one module as the build times are short.

[saep]

Just as an update: #20 is heavily dependent on dyre. I don't think we can provide a /scripting experience/ without it. If you want a single static binary that contains all your plugins as a cabal project, that is still possible (the test plugin does it by calling realMain directly). If somebody raises an issue with the dependency to dyre, we can split that into another package.

[saep]

In any case, if anyone has a nice(r) alternative, I would gladly take a look at it.

[saep]

Since we are now able to reload code inside a ghci repl, the dyre functionality could be moved to a different package. I think a decision for this can wait until the first full release, though.

[saep]

XMonad has implemented a flexible solution in the 0.13 release. I think that adopting it might be nice. Dyre had some changes for stack compatibility as well. I think I should reiterate on the design decision i took.

[saep]

I don't see an issue in the way it is currently done. You can use dyre, but you must not. Simply not including the default plugins will get rid of it.