In short, I’ve been doing a really terrible job keeping the lights on and I don’t foresee a lot of additional bandwidth in the near term. I haven’t used it actively since the LSP options became usable, but I know there are people who do. Please reach out if you have any interest.
Also, a huge thank you to @andreasabel for doing all of the hard work of keeping Hasktags building with newer versions of GHC.
To be honest it would be probably best to sunset it and recommend ghc-tags (or ghc-tags-plugin) instead since they don’t have any parser-related bugs.
I see you are the maintainer of ghc-tags, Andrzej. Are you sure ghc-tags and hasktags perfectly overlap in their goal and scope?
I am a user of hasktags Jack. Thanks for your work and thanks for deciding to seek a new maintainer here; a positive way forward that shows consideration for the ecosystem and allows previous maintainer a well-deserved closure to manage with other commitments.
I’m not sure about ghc-tags, but I was a user of hasktags until something annoyed me and I moved to fast-tags and that library has been working great for me for years.
I think so. ghc-tags properly generates tags for all top-level definitions since it uses GHC API, unlike hasktags, fast-tags etc. which use ad-hoc parsers. I use it for tags-based navigation in all of the Haskell projects I interact with without any issues. When I was using hasktags, I was constantly encountering definitions I couldn’t jump to because of bugs in the parser. This was annoying enough for me that I ended up creating ghc-tags 
It’s the recommended tool for tags generation: Tags · Wiki · Glasgow Haskell Compiler / GHC · GitLab and is getting support in the GHC repo as an alternative to HLS.
I use (a lot) haskdogs: Generate tags file for Haskell project and its nearest deps which depends on hasktags. I don’t know if it can be modified easily to use another “tagger”.
I use hasktags because it just works. Not perfectly but it hasn’t changed for more than a decade. The source to hasktags is trivial, I could keep it running for as long as I like.
I don’t have that kind of confidence in anything that depends on GHC’s API. As tempting as they are, their maintainers are more at risk of burning out.
Understandable. FWIW ghc-tags uses ghc-lib so I don’t drown in CPP and maintenance for the last 2 years was generally "every ~6 months spend an hour moving to the newest ghc-lib".
And thank you for that!! ghc-tags-plugin is a core part of my workflow ever siice I discovered it, and I couldn’t be happier!
Thank @coot, he developed ghc-tags-plugin and I just repackaged its tag extracting logic into ghc-tags
I use ghc-tags because it picks up definitions in happy/alex files. And generally works with preprocessors.
I used hasktags before that.
I’m more than happy with ghc-tags. Its adoption in GHC is only the consequence of its quality and good user experience, which I can vouch for in both personal and professional contexts.