gf normally goes to multiple types of files.

if I press gf on a path in a haskell file when I have the hdevtools plugin installed/running, instead of opening the file it complains about it not being a haskell import statement.

Please don't override the default mappings! Also please don't set one up on leader - maybe advertise those functions/suggest a mapping but don't map keys by default.

I only occasionally find hdevtools useful (Ack and tags do most of what I want but quicker) so it's annoying that it overrides something less niche.

This happens on first use and doesn't echo anything to terminal. Can we
a) get this to print something and
b) support neovim's async functionality to stop this from halting neovim?

Thanks

This seems to happen for non trivial project, or to be caused by non released resources. Any idea?

Hello, working with vim (nvim) with the integration of hdevtools improves my workflow a great deal. Thank you for this contribution.

Issue
When I call HdevtoolsType from vim's command line I get errors that say the binary can't find the modules in the project. I suspect this is an issue because of the following:

1. in terminal, hdevtools check -g -isrc -g -Wall -g -hide-package -g transformers src/Render/Pre.hs works as expected
2. in vim's command line, echo hdevtools_options I get what is expect: -g -isrc -g -Wall -g -hide-package -g transformers

... so why might I be getting the following when I call HdevtoolsType from vim's command line?

Failed to load targets
/Users/.../src/Render/Pre.hs:12:1: error:
    Could not find module ‘Models’
    Use -v to see a list of the files searched for.
/Users/.../src/Render/Pre.hs:13:1: error:
    Could not find module ‘Lib.Lens’
    Use -v to see a list of the files searched for.

Finally, when I look at the list of files searched, it seems to find them!

Failed to load targets
<no location info>: *** Chasing dependencies:
<no location info>:
    Chasing modules from: */Users/.../src/Render/Pre.hs
<no location info>:
    !!! Chasing dependencies: finished in 0.52 milliseconds, allocated 0.228 megabytes
<no location info>: *** Chasing dependencies:
<no location info>:
    Chasing modules from: */Users/.../src/Render/Pre.hs
<no location info>:
    !!! Chasing dependencies: finished in 0.52 milliseconds, allocated 0.225 megabytes
<no location info>:
    Stable obj: []
    Stable BCO: []
<no location info>:
    Ready for upsweep
      [NONREC
          ModSummary {
             ms_hs_date = 2018-04-07 13:34:20.687163728 UTC
             ms_mod = Render.Pre,
             ms_textual_imps = [(Nothing, Prelude), (Nothing, Lib.Lens),
                                (Nothing, Models)]
             ms_srcimps = []
          }]
<no location info>: *** Deleting temp files:
<no location info>: Deleting: 
<no location info>:
    compile: input file /Users/.../src/Render/Pre.hs
<no location info>:
    *** Checking old interface for Render.Pre (use -ddump-hi-diffs for more details):
<no location info>:
    [1 of 1] Compiling Render.Pre       ( /Users/.../src/Render/Pre.hs, nothing )
<no location info>: *** Parser [Render.Pre]:
<no location info>:
    !!! Parser [Render.Pre]: finished in 1.96 milliseconds, allocated 2.882 megabytes
<no location info>: *** Renamer/typechecker [Render.Pre]:
<no location info>:
    !!! Renamer/typechecker [Render.Pre]: finished in 0.04 milliseconds, allocated 0.020 megabytes
/Users/.../src/Render/Pre.hs:12:1: error:
    Could not find module ‘Models’
    Locations searched:
      Models.hs
      Models.lhs
      Models.hsig
      Models.lhsig
      src/Models.hs
      src/Models.lhs
      src/Models.hsig
      src/Models.lhsig
/Users/.../src/Render/Pre.hs:13:1: error:
    Could not find module ‘Lib.Lens’
    Locations searched:
      Lib/Lens.hs
      Lib/Lens.lhs
      Lib/Lens.hsig
      Lib/Lens.lhsig
      src/Lib/Lens.hs
      src/Lib/Lens.lhs
      src/Lib/Lens.hsig
      src/Lib/Lens.lhsig
<no location info>: Upsweep partially successful.
<no location info>: *** Deleting temp files:
<no location info>: Deleting: 

Thank you in advance for any pointers to resolving this issue.

- E

Hi,

imagine I'm contributing on a project with has a local .ghci files, i.e. a .ghci files in the project root.
Suppose this project hides a package and solves an ambiguity.

If I launch vim from the aforementioned directory, and ask vim-hsdevtools for the type of a function,
this is what I get:

Error loading targets
src/Snap/Snaplet/Internal/Lensed.hs:10:8:
Ambiguous module name `Control.Monad.CatchIO':
it was found in multiple packages:
MonadCatchIO-transformers-0.3.0.0 MonadCatchIO-mtl-0.3.0.5

The error would be fixed reading the proper option (i.e. hide package) from the local .gchi files, but hdevtools seems to ignore it.

I hope the issue is clear.

Cheers,
A.

I feel that, at least for some code, Hdevtools should be able to work out the type of the relevant value/variable without all of the code needing to be able to be compiled.

e.g.

main = print 2*3

It would be great if we could verify that the type of print was Show a => a -> IO ()

For this simple case there is little value in this but for more complex cases (e.g. where type errors do not allow the program to be executed) it would be great to be able to see types of parts of the broken code.

p.s. Thanks for the extension, I use it all the time

Great plugin.

One thing I miss from GHC-mod is insert type ( :GhcModTypeInsert).

It would be nice if vim-hdevtools were configured to also work with *.lhs and *.hsc files out of the box.

Is this also MIT-licensed?

The syntastic integration of hdevtools and stack works great for me. However, for some reason :HdevtoolsType doesn't. Is there a quick fix for that or am I doing something wrong ?

The title says it all really.
This would make go_file a little more robust regarding edition location.

Probably dependent on cabal support in hdevtools: bitc/hdevtools#30

I'm not sure if this is even an issue. But I had trouble with vim-hdevtools not finding sandboxed packages in
hsenv.

I used this in my vimrc to fix it

if isdirectory($HSENV)
  let g:hdevtools_options = '-g-package-conf$HSENV/.hsenv_$HSENV_NAME/ghc_pkg_db'
endif

Otherwise it works great. Thanks

Using hdevtools check with a file that uses template haskell, direct in an imported module, fails in a linker step for ghci:

ByteCodeLink.lookupCE
During interactive linking, GHCi couldn't find the following symbol:
monkyzm2zi0zi1zi1zmIZZax6R8K8W72umuzz6hs2tf_MonkyziTemplate_importLib_closure
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
[email protected]

I encountered this while testing hdevtools with monky.
In the Monky.Modules hdevtools can be used without problems. Files including (direct or transitiv) Monky.Template produce the error.

A similar error (different symbol missing) is produced trying to check bin/Main.hs which includes Monky.Version which also uses template haskell.

Hi everyone,

I've been using hdevtools for a while and this is the first time I'm encountering this problem.
In a nutshell I'm using vim and hdevtools into a sandbox environment (hsenv) but from a tmux window. If I try to check a simple file I get this (obviously digestive-functor is installed!):

src/Models.hs:6:8:
    Could not find module `Text.Digestive'
    Use -v to see a list of the files searched for.

but if I fire up another shell window, this time WITHOUT any tmux session, and I enable hsenv the checking goes well. My speculation is that using Tmux is causing hdevtools not to correctly handling the packages path. Any user experienced the same problem? I can give you Tmux, Ghc and hdevtool version if required :)
I know is a bit vague as bug, and strictly not related to the Vim bundle, but I thought it might be useful not just for me :)
If my memory isn't tricking me, with previous version of Tmux/Ghc/Hdevtools I never experienced this problem (probably I'm talking about 2-3 months ago). Any idea of something which could have broke the equilibrium? :)

Wouldn't it be nice if expressions were highlighted with ordinary vim VISUAL when HdevtoolsType is called? Then highlighting could be cleared with as usual and I think it could also be very useful for performing deletes, yanks and other operations on expressions.

It would be cool if you could review a suggestion made by hdevtools and choose to automatically accept it into your code. So, when hdevtools says:

Redundant bracket Found: ((placeAI x y gameState course)) Why not: (placeAI x y gameState course)

I'd like to say: "Yes! Thank you! Please do that!" and have it edit my code for me.

Is there any interest in this feature? Should I try my hand at it?

The git clone command should refer to "vim-hdevtools", not "hdevtools".

Please add a point between 1 and 2 in Your installation guide (in readme.md):
Assert, that ~/.cabal/bin is in Your search path, otherwise You don't get any error feedback in vim.
E.g. add the folllowing to Your ~/.bashrc File:
PATH=$HOME/.cabal/bin:$PATH

And run afterwards:
source ~/.bashrc

The plugin should ignore :HdevtoolsType commands that are run inside the :HdevtoolsInfo window. It doesn't work, is pointless, and prints an annoying error.

My vimrc has let g:hdevtools_options = '--nostack'.

Yet still, I see huge blocking delays on startup, on :HdevtoolsInfo and also on exit.

During the hangs, I look at the process tree, and see hdevtools admin --status and hdevtools admin --stop-server running stack commands, which causes the long stack updates or whatever.

It'd be nice to have --nostack respected. Or at least have an indication of what's blocking my UI (as in #26).

This is all on Neovim, but I guess it doesn't matter much.

Hi,

Thanks so much for making and maintaining this plugin.

When using the type command, I get the warning:

hdevtools#type: the buffer has been modified but not written

Any idea what's wrong with my setup?

https://github.com/kana/vim-textobj-user

It would be really cool if we could use the code from :HdevtoolsType to turn Haskell expressions into text objects, such that for example with the cursor on a case we can do cie to delete the whole case expression and enter insert mode, d2ae would delete the case expression and the outer expression containing it (the way repeated :HdevtoolsType works) plus surrounding whitespace, etc.

See also Chris Done's videos on "Structural editing" in emacs using his "syntax-mode":

http://www.youtube.com/user/ChristopherDone

Whenever hdevtools emits a warning message, which isn't all that infrequent, something like an unused import or a defined and not used variable will cause it to emit warnings. :HdevtoolsType will give a bunch of errors that make it a huge pain to use.

The code causing the issue is here:

let l:types = []
for l:line in split(l:output, '\n')
  let l:m = matchlist(l:line, '\(\d\+\) \(\d\+\) \(\d\+\) \(\d\+\) "\([^"]\+\)"')
  call add(l:types, [l:m[1 : 4], l:m[5]])
endfor

Since the regex does not correctly parse the warning message. Index 5 is out of range. Causing the following error messages to appear:

Error detected while processing function hdevtools#type:
line   30:
E684: list index out of range: 5
E116: Invalid arguments for function add
... (above two lines repeated often several times, taking up often a good third of the screen)

I personally think the onus is on vim-hdevtools to silently ignore those warnings. Since I will see them on save from hdevtools itself anyway, so I don't need them annoying me whenever I want to check types of things.

Hey,

Hope this does not come out stupid, but it would be cool to get the types also to show if the current file does not compile. E.g. if I am developing a new function and quickly want to check the type of a function I wrote earlier to see if I can re-use it or refactor it to re-use it, it would be cool if I did not have to comment a whole lot of stuff out in order for the file to compile first.