Closed edsko closed 7 years ago
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.
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 :)
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.
.. 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 :)
.. 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.
Fair enough :)
[Enter steps to reproduce below:]
Atom Version: 1.13.1 Electron Version: 1.3.13 System: Mac OS X 10.12.3 Thrown From: ide-haskell-hasktags package, v0.0.8
Stack Trace
Uncaught TypeError: editor.getURI is not a function
Commands
Config
Installed Packages