neovimhaskell / nvim-hs Goto Github PK

I've been trying to nvim-hs$ cabal install . the current master c0c98b but it gives:
library/Neovim/Classes.hs|313 col 10 error| No instance for (NFData Object) arising from the superclasses of an instance declarationIn the instance declaration for ‘NvimObject Object’ [1 of 5] Compiling CabalHelper.Types ( CabalHelper/Types.hs, /home/teto/.ghc-mod/cabal-helper/CabalHelper/Types.o )
Here is ghc -v

Glasgow Haskell Compiler, Version 7.10.3, stage 2 booted by GHC version 7.10.3
Using binary package database: /usr/lib/ghc/package.conf.d/package.cache
Using binary package database: /home/teto/.ghc/x86_64-linux-7.10.3/package.conf.d/package.cache
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-6cdc86811872333585fa98756aa7c51e
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-3c8c40657a9870f5c33be17496806d8d
wired-in package base mapped to base-4.8.2.0-0d6d1084fbc041e1cded9228e80e264d
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-3c4cb52230f347282af9b2817f013181
wired-in package ghc mapped to ghc-7.10.3-624693c6aa854116c707bc7b4d0d7cb6
wired-in package dph-seq not found.
wired-in package dph-par not found.

As master is not a stable version feel free to ignore this issue, I was jsut surprised to see the "Build passing" badge.

There is currently no handling in the SocketReader for commands or autocmds that set special flags when they are exported.

We should implement a way to set logging parameters using command line arguments, this way we can specify log files and level in rpcstart(). Currently there's no way to debug rpcstart()ed plugins.

Also, currently outgoing and incoming messages are not logged at all. Logging those in most verbose logging setting would be very useful for following the communications.

There is a closed issue that had almost the same error as myself. (#36)

Building nvim-hs-0.0.7...
Preprocessing library nvim-hs-0.0.7...

library/Neovim/Classes.hs:4:14: Warning: 
    -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS
[ 1 of 27] Compiling Neovim.Log       ( library/Neovim/Log.hs, dist/dist-sandbox-57d0b3ff/build/Neovim/Log.o )
[ 2 of 27] Compiling Neovim.Plugin.Startup ( library/Neovim/Plugin/Startup.hs, dist/dist-sandbox-57d0b3ff/build/Neovim/Plugin/Startup.o )
[ 3 of 27] Compiling Neovim.Classes   ( library/Neovim/Classes.hs, dist/dist-sandbox-57d0b3ff/build/Neovim/Classes.o )
[ 4 of 27] Compiling Neovim.Plugin.Classes ( library/Neovim/Plugin/Classes.hs, dist/dist-sandbox-57d0b3ff/build/Neovim/Plugin/Classes.o )
[ 5 of 27] Compiling Neovim.Plugin.IPC.Classes ( library/Neovim/Plugin/IPC/Classes.hs, dist/dist-sandbox-57d0b3ff/build/Neovim/Plugin/IPC/Classes.o )

library/Neovim/Plugin/IPC/Classes.hs:33:1: Warning:
    The import of ‘Data.Time.Locale.Compat’ is redundant
      except perhaps to import instances from ‘Data.Time.Locale.Compat’
    To import instances alone, use: import Data.Time.Locale.Compat()
[ 6 of 27] Compiling Neovim.Plugin.IPC ( library/Neovim/Plugin/IPC.hs, dist/dist-sandbox-57d0b3ff/build/Neovim/Plugin/IPC.o )
[ 7 of 27] Compiling Neovim.Context.Internal ( library/Neovim/Context/Internal.hs, dist/dist-sandbox-57d0b3ff/build/Neovim/Context/Internal.o )
[ 8 of 27] Compiling Neovim.Context   ( library/Neovim/Context.hs, dist/dist-sandbox-57d0b3ff/build/Neovim/Context.o )
[ 9 of 27] Compiling Neovim.Plugin.Internal ( library/Neovim/Plugin/Internal.hs, dist/dist-sandbox-57d0b3ff/build/Neovim/Plugin/Internal.o )
[10 of 27] Compiling Neovim.Config    ( library/Neovim/Config.hs, dist/dist-sandbox-57d0b3ff/build/Neovim/Config.o )
[11 of 27] Compiling Neovim.Util      ( library/Neovim/Util.hs, dist/dist-sandbox-57d0b3ff/build/Neovim/Util.o )
[12 of 27] Compiling Neovim.RPC.Common ( library/Neovim/RPC/Common.hs, dist/dist-sandbox-57d0b3ff/build/Neovim/RPC/Common.o )
[13 of 27] Compiling Neovim.RPC.Classes ( library/Neovim/RPC/Classes.hs, dist/dist-sandbox-57d0b3ff/build/Neovim/RPC/Classes.o )
[14 of 27] Compiling Neovim.RPC.FunctionCall ( library/Neovim/RPC/FunctionCall.hs, dist/dist-sandbox-57d0b3ff/build/Neovim/RPC/FunctionCall.o )
[15 of 27] Compiling Neovim.RPC.EventHandler ( library/Neovim/RPC/EventHandler.hs, dist/dist-sandbox-57d0b3ff/build/Neovim/RPC/EventHandler.o )
[16 of 27] Compiling Neovim.API.Parser ( library/Neovim/API/Parser.hs, dist/dist-sandbox-57d0b3ff/build/Neovim/API/Parser.o )
[17 of 27] Compiling Neovim.API.TH    ( library/Neovim/API/TH.hs, dist/dist-sandbox-57d0b3ff/build/Neovim/API/TH.o )
[18 of 27] Compiling Neovim.API.String ( library/Neovim/API/String.hs, dist/dist-sandbox-57d0b3ff/build/Neovim/API/String.o )

library/Neovim/API/String.hs:23:3: No entry for: "async"
cabal: Error: some packages failed to install:
nvim-hs-0.0.7 failed during the building phase. The exception was:
ExitFailure 1

The solution was to install a more recent version of neovim.

However, I installed the latest version as described in Neovim install instructions which is 0.2.0-dev and got this error.

What is wrong?

When I removed the StateT monad transformer and started to use async and unliftIO for the backend, I did not really pay attention to the Neovim.Debug module. It should be cleaned up a bit to be more useful. I'll probably do this when I have a specific need to debug something (like the API/code generation).

It should not be limited to the Plugin definition.

I think this package transitively depends on aeson anyway, so it is probably convenient to provide such instances.

Hey!

Congrats, this is awesome!

I am just wondering if there is a way to develop not only for nvim but for vim. I need backwards compatibility with older versions of vim. Perhaps something can be done to make it work?

lib was just the default that dyre used and this clearly indicates that the files in that folder belong to this plugin manager.

The test we fixed couple of days ago is broken again. I added a .travis.yml script, but I can't enable Travis since I'm not the owner of the repo. @saep can you enable it? In the meantime I'll be debugging this.

It only prints the log message. Add this and maybe even add a timestamp too.

I'm currently exploring the possibility of defining the Neovim context as a monad transformer. Apart from being slightly more complicated to initialize, this approach seems to be way more flexible than the current one. I found it quite hard to start a ghc-mod context with the current model and therefore I am exploring this design space before commiting to a (somewhat) final API design for version 0.1.

install from hackage get error
library/Neovim/API/String.hs:23:3:
No entry forObjectBinary "error_types"
build from git is ok.
so

Last time I checked, it does not work because neovim is not a trusted package (see here).

The problem will resolve itself once neovim has a public release, I think. But, if somebody wants to take care of adding a trustworthy ppa to that whitelist, feel free to do so and ping this issue it it is done.

Neovim hangs if the computation does not finish. This can happen, for example, if you accidently force an infinite list. Neovim shouldn't have to be killed because of that.

Hi, thank you for awesome package!
In this line of this commit, MonadCatch and MonadMask instances of Neovim are removed. What is the purpose of this?

I am opening the discussion by providing three work flows on how to distribute plugins. These work flows are not mutually exclusive!

• Community repositories that contain a bunch of plugins

  This is similar to xmonad with xmonad-contrib and xmonad-extra. There is a more or less
  point where you can upload plugins. Each of those repositories will have some kind of criteria of
  what can and should be in it. Criteria can be: not too big dependencies, reviewed by n peers,
  tests, quality of documentation or whatever is appropriate.

  Advantages for this approach are:

  • High discoverability for plugins
  • Plugins are kept up-to-date by the maintainers of the repository and should be compatible with
    releases of neovim or nvim-hs.
  • Can be shipped with (linux) distributions

  Disadvantages:

  • Potentially high entry barrier for new plugins
  • Not really suited for plugins which are still changing a lot

• Git repositories cloned into $XDG_CONFIG_HOME/lib or $XDG_CONFIG_HOME/lib/Neovim
  (naming could be an issue)

  If neovim were to adopt the XDG basedir specification, the paths are probably different again.
  Anyhow, the exact location should better be based on some discussion with real arguments
  rather than my nightly idea which I though should be written down before I forget it.

  Advantages:

  • Low entry barrier
  • Updating to the latest version is just one pull away and hence it is well suited for plugins which are
    still in active development without a stable API

  Disadvantages:

  • Low discoverability (Wiki entry here could point to those repositories)
  • Naming is restricted (or something similar to plug/pathogen/vundle for haskell plugins must be
    implemented)
  • Restart/Recompile times for nvim-hs grow with each plugin!

• Tool-dependent repositories as a cabal package

  This means that a plugin is just a cabal package. With tool, I mean something like ide-backend.

  It's not so easy for me to clearly state advantages or disadvantages. This could easily be the same
  as a community repository whore plugins mainly build on top of such a tool. In any case, I think that
  if some plugin author choses to walk this path, she should think about the feasibility of this
  approach.

A lot of functions are mocked with error ... and should probably use a logger. This would ease debugging and makes the plugin provider more resilient.

Unless somebody has a better idea before starting to implement this, the hslogger library seems to be a reasonable choice.

From the docs:

Create a file called nvim.hs in $XDG_CONFIG_HOME/nvim (usually ~/.config/nvim with the following content:

$XDG_CONFIG_HOME does not necessarily exist on OS X. What's the right place to put nvim.hs on Mac? How can we customize the location of this file?

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?

When use lts-10.0 snapshot to compile nvim-hs, It is problematic to work.
I looked into the logger, found some Error message:

[Context : ERROR] Converting Exception to Error message: thread blocked indefinitely in an STM transaction
[Neovim.Main : ERROR] Error initializing plugins: thread blocked indefinitely in an STM transaction
[Neovim.Main : ERROR] thread blocked indefinitely in an STM transaction

Hangs in this line:

On my system, cloning my fork and running stack build yields the following:

nvim-hs-0.0.5: build
Preprocessing library nvim-hs-0.0.5...

library/Neovim/Classes.hs:4:14: Warning:
    -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS
[18 of 27] Compiling Neovim.API.String ( library/Neovim/API/String.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Neovim/API/String.o )

library/Neovim/API/String.hs:23:3: No entry forObjectBinary "async"

--  While building package nvim-hs-0.0.5 using:
      /Users/silver/.stack/programs/x86_64-osx/ghc-7.10.1/bin/runhaskell -package=Cabal-1.22.2.0 -clear-package-db -global-package-db -package-db=/Users/silver/.stack/snapshots/x86_64-osx/nightly-2015-07-25/7.10.1/pkgdb/ /var/folders/0l/vg6g5pdd32l6ggh_xdngnkwh0000gn/T/stack42345/Setup.hs --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.2.0/ build exe:nvim-hs --ghc-options -hpcdir .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/hpc/.hpc/ -ddump-hi -ddump-to-file
    Process exited with code: ExitFailure 1

Is something wrong with my neovim? Or what?

Or simply do not test for it anymore.

I am working on a relatively thorough documentation which should provide enough information for anyone who is a bit familiar with Haskell to write plugins.

In the same process, I am limiting the amount of exported API functions to what I think is useful and which shouldn't change in the future. This is the first step for an actual release on Hackage!

While working on updating the documentation, I realized that you have to hammer in quite a bunch of commands to get going. I think it would improve the user experience if nvim-hs would offer an interactive installation commands line option.

This issue should gather ideas on how to improve debugging. (Solutions are welcome, too!)

Currently we have:

• Saving a file in $XDG_CONFIG_HOME/nvim will trigger a rebuild and put compile time errors in the quickflix list
• If logging is enabled, the raw msgpack-rpc messages we receive are logged.

Those things are incredibly useful, but I think we can do better!

1. When I was implementing the registration of functions or filling the quickfixlist with compile errors from dyre, looking at the logged msgpack-rpc messages was insanely useful. I think this should be made more accessible and integrated. I imagine opening a window inside neovim that (pretty) prints all the msgpack-rpc communication after issueing a command (e.g. :DebugNvimhs).
2. Implementing new functions that interact with neovim, and hence require the Neovim transformer stack, should be possible from a REPL. I don't know if it's possible to run a ghci-like session inside such a transformer. Or something int he direction of https://github.com/chrisdone/ghci-reload-demo could be conveniently achieved.

1. The remote procedure call specific parts could be made more abstract and put into a generally useful package.
2. The code-generation could be done in a seperate package and use that package as a library to provide different APIs to plugin authors.
3. With regard to 2. implement an example library.

Following the instructions in the docs with a clean clone of nvim-hs, I get the following errors when running cabal install:

[17 of 27] Compiling Neovim.API.TH    ( library/Neovim/API/TH.hs, dist/dist-sandbox-81f5234c/build/Neovim/API/TH.o )

library/Neovim/API/TH.hs:186:9: error:
    • Couldn't match expected type ‘Q Dec’
                  with actual type ‘CxtQ -> DecQ’
    • Probable cause: ‘dataD’ is applied to too few arguments
      In a stmt of a 'do' block:
        dataD
          (return [])
          nme
          []
          (map (\ n -> normalC n [return (IsStrict, tObject)]) cs)
          (mkName <$> ["Typeable", "Eq", "Show"])
      In the expression:
        do { tObject <- [t| ByteString |];
             dataD
               (return [])
               nme
               []
               (map (\ n -> normalC n [return ...]) cs)
               (mkName <$> ["Typeable", "Eq", ....]) }
      In an equation for ‘createDataTypeWithByteStringComponent’:
          createDataTypeWithByteStringComponent nme cs
            = do { tObject <- [t| ByteString |];
                   dataD
                     (return [])
                     nme
                     []
                     (map (\ n -> normalC n [...]) cs)
                     (mkName <$> ["Typeable", ....]) }

library/Neovim/API/TH.hs:190:14: error:
    • Couldn't match expected type ‘Maybe Kind’
                  with actual type ‘[ConQ]’
    • In the fourth argument of ‘dataD’, namely
        ‘(map (\ n -> normalC n [return (IsStrict, tObject)]) cs)’
      In a stmt of a 'do' block:
        dataD
          (return [])
          nme
          []
          (map (\ n -> normalC n [return (IsStrict, tObject)]) cs)
          (mkName <$> ["Typeable", "Eq", "Show"])
      In the expression:
        do { tObject <- [t| ByteString |];
             dataD
               (return [])
               nme
               []
               (map (\ n -> normalC n [return ...]) cs)
               (mkName <$> ["Typeable", "Eq", ....]) }

library/Neovim/API/TH.hs:190:43: error:
    • Data constructor not in scope: IsStrict :: Bang
    • Perhaps you meant one of these:
        variable ‘isStrict’ (imported from Language.Haskell.TH),
        ‘Strict’ (imported from Language.Haskell.TH)

library/Neovim/API/TH.hs:191:14: error:
    • Couldn't match type ‘Name’ with ‘Q Con’
      Expected type: [ConQ]
        Actual type: [Name]
    • In the fifth argument of ‘dataD’, namely
        ‘(mkName <$> ["Typeable", "Eq", "Show"])’
      In a stmt of a 'do' block:
        dataD
          (return [])
          nme
          []
          (map (\ n -> normalC n [return (IsStrict, tObject)]) cs)
          (mkName <$> ["Typeable", "Eq", "Show"])
      In the expression:
        do { tObject <- [t| ByteString |];
             dataD
               (return [])
               nme
               []
               (map (\ n -> normalC n [return ...]) cs)
               (mkName <$> ["Typeable", "Eq", ....]) }

library/Neovim/API/TH.hs:429:13: error:
    • The constructor ‘VarI’ should have 3 arguments, but has been given 4
    • In the pattern: VarI _ functionType _ _
      In a case alternative:
          VarI _ functionType _ _ -> determineNumberOfArguments functionType
      In the second argument of ‘($)’, namely
        ‘case fInfo of {
           VarI _ functionType _ _ -> determineNumberOfArguments functionType
           x -> error
                $ "Value given to function is (likely) not the name of a function.\n"
                  <> show x }’
cabal: Error: some packages failed to install:
nvim-hs-0.0.7 failed during the building phase. The exception was:
ExitFailure 1

Any thoughts on what is going wrong?

The way to install haskell plugins is not as smooth as it is for python for instance where you just drop your .py files in rplugin/python{3}/ and then UpdateRemotePlugins will send a "specs" request over msgpack-rpc. The python host returns a string that is used to register commands/functions in .local/share/nvim/rplugin.vim .

I am a beginner in haskell so I might be wrong but I don't think the previous mechanism is available for haskell ?! Else I would like to volunteer (as a way to improve my haskell skills).
Is that redundant with #41 ?

If PR #71 is merged, Dyre is no longer used to automatically recompile and restart the nvim-hs instance.

A generic function to recompile and restart nvim-hs instances paired with some autocommands is probably the way to go. The autocommands should probably be added to the default stack template and also documented in the general :help page.

If you include a list of plugins from a module and you want to configure one of the plugins differently or replace it with a different configuration, it is currently necessary to explicitly redefine the whole list. It is probably easier to use the last definition.

To implement this, it is necessary to identify plugins and only start the last definition of the plugin.

• add name :: String field to Plugin data type
• implement logic to take the newest definition (i.e. the last occurrence with the same name) when plugins are initialized/started

Possible negative side effects:

• Plugins which happen to have the same name cannot be started from the same process

Although the dyre library helps with (somewhat) dynamic recompilation, it is still a bit annoying to use. Compile errors are silently dumped into ~/.cache/nvim/errors.log and you do not really notice if something went wrong there. Say you are developing a function for a plugin, the function may fail because you did something wrong logically or because it did not compile. It would be a tremendous improvement to be notified about the latter situation immediately. Also, it is still very inconvenient to restart neovim all the time if you change the configuration. To remedy these problems, we should extend nvim-hs to supply some functions and commands out of the box. This issue is a place to collect ideas and document the stage of its development.

The first steps are:

• Implement a way to recompile nvim-hs.

  This is probably best done by subscribing to a notification (via vim_subscribe) on startup and implement a handler for it. Currently, notifications are ignored in the SocketReader. The dyre library has some lower level functions for this, so that we do not have to spawn external processes ourselves. The quickfix list should then be filled with the compiler warnings and errors. We can parse the output in Haskell ourselves or steal that code from somewhere else (e.g. syntastic/ghc-mod).

• Implement a way to restart nvim-hs.

  This should probably be implemented similarly to the previous step. The dyre library has a module for this as well. This leads us to another decision: Do we want to preserve state when restarting? And if so, how should we go about it? XMonad has an extensible state state extension which we could use as inspiration for partially preserving state, but we can simply not care for now and defer this.

Then, we must think about how this is integrated within neovim. I think it is sufficient to provide two commands for the two steps above: :RecompileNvim-hs and :RestartNvim-hs (feel free to suggest better names). If we define them on our side, we don't even have to explicitly call vim_subscribe and can pass it directly to the EventHandler.

This would make the order of the arguments and their purpose clearer.
It's a breaking Change, though.

I'm trying to debug why plugins don't work. I added lots of logging prints and apparently we're not getting any messages at all. While trying to debug, I found this:

> e <- attach' "/tmp/nvimHeJ6f9/0" 
> runNeovim  e () (vim_get_buffers)
^CInterrupted.
> e <- attach "/tmp/nvimHeJ6f9/0" 
> runNeovim  e () (vim_get_buffers)
(Right [Buffer "\STX"],())

Here are attach' and attach:

attach :: FilePath -> IO (ConfigWrapper RPCConfig)
attach sockPath = do
    h <- createHandle ReadWriteMode (UnixSocket sockPath)
    q <- newTQueueIO
    e <- ConfigWrapper q <$> newRPCConfig
    _ <- forkIO $ runSocketReader' h e
    _ <- forkIO $ runEventHandler' h e
    return e

-- | FIXME: This doesn't work!! Use attach!
attach' :: FilePath -> IO (ConfigWrapper RPCConfig)
attach' sockPath = do
    q <- newTQueueIO
    e <- ConfigWrapper q <$> newRPCConfig
    _ <- forkIO $ runSocketReader (UnixSocket sockPath) e
    _ <- forkIO $ runEventHandler (UnixSocket sockPath) e
    return e

However, fixing this doesn't solve the issue. I'm still trying to debug and will close this issue with my PR that fixes plugins.

As seen on the Stackage build server:

[ 9 of 29] Compiling Neovim.Context.Internal ( library/Neovim/Context/Internal.h
s, dist/build/Neovim/Context/Internal.o )

library/Neovim/Context/Internal.hs:76:52: error:
    • No instance for (MonadUnliftIO
                         (StateT st (ReaderT (Config r st) IO)))
        arising from a use of ‘runResourceT’
    • In the first argument of ‘runStateT’, namely ‘(runResourceT a)’
      In the first argument of ‘runReaderT’, namely
        ‘(runStateT (runResourceT a) s)’
      In the second argument of ‘($)’, namely
        ‘runReaderT
           (runStateT (runResourceT a) s)
           (r {customConfig = f (customConfig r)})’
   |
76 |         fmap fst . liftIO $ runReaderT (runStateT (runResourceT a) s)
   |                                                    ^^^^^^^^^^^^^^

library/Neovim/Context/Internal.hs:117:35: error:
    • No instance for (MonadUnliftIO
                         (StateT st (ReaderT (Config r st) IO)))
        arising from a use of ‘runResourceT’
    • In the first argument of ‘runStateT’, namely ‘(runResourceT a)’
      In the first argument of ‘runReaderT’, namely
        ‘(runStateT (runResourceT a) st)’
      In the second argument of ‘(.)’, namely
        ‘runReaderT (runStateT (runResourceT a) st)’
    |
117 |     (try . runReaderT (runStateT (runResourceT a) st)) r >>= \case
    |                                   ^^^^^^^^^^^^^^

I was able to reproduce the build failure locally like so:

stack unpack nvim-hs-0.2.5 && cd nvim-hs-0.2.5
edit stack.yaml # add the following stack.yaml
stack build

# stack.yaml
resolver: nightly-2018-03-10
extra-deps:
- resourcet-1.2.0
- conduit-1.3.0
- conduit-extra-1.3.0
- cereal-conduit-0.8.0

The msgpack API that this prototype is currently using smartly converts integers to the smallest possible representation. The msgpack-rpc specification however states that elements of the messages that are send should have a specific type. However, neovim seems to handle the minimized types quite well.
Can the submodule be removed and the changes for the specific integer size be reversed without introducing bugs?

After reading https://www.fpcomplete.com/blog/2017/06/readert-design-pattern and https://www.fpcomplete.com/blog/2017/06/tale-of-two-brackets, I think it might be worth simplifying the basic stack used. One can always put something like an MVar inside the reader environment and use runStateT when necessary.

• Wait for rodrigosetti/messagepack/pull/12 to be merged
• Open PR on stackage

I think it would be cool to have something like inline-c for vimL.

Apart from being fun to implement, I can imagine these arguments for and against this.

Pros:

• Calling (a lot of) vimL is more convenient
• Each block could be sent as one eval-command to neovim, so that it gets executed atomically (If that is even possible). This could avoid race-conditions with other plugins, or user interaction in general.

Cons:

• Additional complexity, i.e. more bugs.
• It may be used only sparingly as this project was made to avoid vimL.

Feel free to discuss this topic or start asking questions on how to approach this.

It seems that nvim-hs-0.2.2 is now in stackage.

AFAICT, as a result, the README could be updated to simplify the installation instructions that use stack.

This resembles more what dyre does and a stack build or stack ghci will more helpful results.

I cannot really make head or tails on how to actually tell neovim which functions a plugin provider offers. I had a somewhat serious glimpse at the python code, but I could not find the proper location. The :UpdateRemotePlugins function couldn't help me either.

I'm currently writing some plugins to see how convenient the API is. I realized two things:

1. Non-stateful function type is pretty useless, because even though it lets us do IO, we can't evaluate vim expressions and commands using it, because we need Neovim monad for those. So we can't read any vim state, for example I can't do getpos("'<") and get beginning of visual selection.
2. Stateful functions can get method name using reqMethod, so a single stateful functions can be used for multiple functions in a plugin(and they don't need multiple channels, although a channel for each different function call may be used).

So it seems like we can remove stateless functions and use only stateful ones instead. @saep what do you think?

Here's an example stateful function that wraps the selection with parens:

pwrap :: TQueue SomeMessage -> Neovim cfg s ()
pwrap q = do
    req <- awaitRequest q
    -- reqMethod req

    Right (ObjectArray [ObjectInt _, ObjectInt bline, ObjectInt bcol, ObjectInt _]) <-
      atomically' =<< vim_eval "getpos(\"'<\")"

    Right (ObjectArray [ObjectInt _, ObjectInt eline, ObjectInt ecol, ObjectInt _]) <-
      atomically' =<< vim_eval "getpos(\"'>\")"

    _ <- atomically' =<< (vim_command $ "normal! " ++ show bline ++ "gg" ++
                            show bcol ++ "|i(")
    _ <- atomically' =<< (vim_command $ "normal! " ++ show eline ++ "gg" ++
                            show (ecol + if bline == eline then 1 else 0) ++
                            "|a)")

    respond (reqId req) (Right ())
    pwrap q

It's not possible to implement this using stateless functions, since it's not possible to evaluate vim expressions in stateless functions. Note that there's no need to keep this function looping in a thread, but currently we don't have way to implement this in any other way. In the worst case multiple functions can be implemented as a single stateful function and function dispatch can be handled using multiple TChans or reqMethod function.

Plugin authors hopefully want to write tests. It should be made as convenient as possible for them.

Shame on me.

Instead of using "show" for exceptions, we should use a pretty-printing library for displaying helpful text on how to resolve the error. An error could then open a temporary window in neovim (although this should be configurable) with the error printed pretty.

Since this is more a cosmetic matter than a functional one, the priority is set to low.

Hi there,

This is a great project, thanks a lot!

Playing with the example code, I've noticed the following: when I :echo Fibonacci(128), it fails with

Error detected while processing function Fibonacci:
line    1:
Expected any Integer value, but got ObjectUInt 128
0
Press ENTER or type command to continue

It's probably Data.MessagePack that uses ObjectUInt for n > 127.

Not that this is a real problem, I suppose (except that it'd be cool to change the 2000 to a 20 in the example code, maybe). But out of curiosity -- how would you fix the function to work with both small and big integers?

I tried testing the Fibonacci example plugin provided by nvim-hs.

However, when I change the plugin code to something which generates an error, Neovim freezes with no shown error.

For example, the following code would work for :echo fibonacci(0), but the freeze would occur in :echo fibonacci(1).

fibonacci :: Int -> Neovim' String
fibonacci n = return . show $ fibs !! n
  where fibs = [0]

Is that normal?