Uncaught TypeError: editor.getURI is not a function about ide-haskell-hasktags HOT 6 CLOSED

That happens when Atom suddenly changes behavior on you and you have to update all your packages... Thanks for catching that, should be fixed in v0.0.9.

from ide-haskell-hasktags.

Yup, fixed. Question: what exactly is the goal of the package? I just wanted to give it a spin. So far I like that symbols don't appear twice (which is what happens without it, one for the type decl and one for the def). But I guess it's not using a tags file in the directory? I tend to run

hasktags -x -c ..

in most of my projects because they are part of a larger project, and I want the symbols for the whole project, not just this component. Mind, this isn't a feature request necessarily :)

from ide-haskell-hasktags.

The goal of the package is to provide symbols-view-like support for hasktags that isn't horrible... And it was born out of frustration in the early days, so things might've changed for the better since.

For one, tags are automagically updated when files change on disk. It ignores tagsfile though, since I figured there are enough packages that provide support for that, besides symbols-view. This package also provides reasonable 'go-to-definition' drop-in replacement, which actually works (I had a lot of trouble with builtin one in the past -- again, maybe that has changed for the better)

Note that it watches all currently-open projects, and should show tags from all of those (I didn't check that, so there might be bugs lurking) -- and opening component projects as sub-projects in Atom is the preferred way of dealing with that, but of course YMMV.

Overall, this package aims to be a drop-in replacement for symbols-view that "just works" with no additional setup (like re-/generating tagfiles, etc). If you want to extend it for your particular needs, you know that PRs are always welcome ^^. Note that it uses etags (emacs format), which was easier to write a (sorta) streaming parser for at the time. It should be reasonably easy to extend it to merge existing etags file with the generated one.

P.S. the reason why it doesn't generate two tags for one identifier is that it uses Map to store parsed data. Now that I think about it, it might be not the best idea ever, since it will mess up if definition is below implementation, e.g.

main = putStrLn "something"
main :: IO ()

would send you to definition, while

main :: IO ()
main = putStrLn "something"

will send to implementation.

There is a solution for that actually in hasktags already. --ignore-close-implementation hasktags flag will ignore implementation if it's close to the definition.

from ide-haskell-hasktags.

.. but then what kind of monster writes

main = putStrLn "something"
main :: IO ()

?? :-D But there might be other more important concerns? I don't know, stuff like

data Foo = ...

data Bar = Foo Foo

stuff like that (different Haskell namespaces)?

Anyway, I've been using built-in support for tags, occassionally calling hasktags -c -x . and it seems to work okay for me, not sure that the maintenance overhead of this package is worth it for you. I'd be curious to know if you tried to switch back if there's something major you miss (or, in other words, if I should switch over to this package :)

from ide-haskell-hasktags.

.. but then what kind of monster writes

Well, it's a stupid example, but it's entirely possible to have something like

fun1 = ...
fun2 = ...
...
funn = ...

fun1, fun2, etc :: SomeType -- shut up compiler warnings

Which could be rather problematic. Anyway, this was somewhat-fixed back in February, so it's beside the point.

maintenance overhead of this package

is negligible. Frankly, there isn't much to maintain in the first place.

from ide-haskell-hasktags.

Fair enough :)

from ide-haskell-hasktags.