which tags program should I use?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

which tags program should I use?

Henry Laxen
Dear Group,

I have a simple question, that as far as I can tell, has never really
been well answered.  I would like to generate TAGS files for haskell
source.  Reading the http://www.haskell.org/haskellwiki/Tags page
suggests using :etags in GHCI or hasktags, or gasbag.  Of the three,
hasktags comes closest to "working" but it has (for me) a major
inconvenience, namely it finds both function definitions and type
signatures, resulting in two TAGS entries such as:

./Main.hs,63
module Main where6,7
main ::24,25
main =25,26

Now when I do an emacs find-tag (I use icicles) I will always have to
choose which tag I want to visit, and the completion buffer contains
something like:

main ::
hs/Main.hs

main =
hs/Main.hs


Granted, this is a minor (and very specialized) complaint, but if
hasktags were to select only ONE of either the type signature (my
first choice) or the function definition, (if no type signature) this
annoyance would disappear.  

I also tried using etags, which I think would work, but it seems to
have one killer bug (feature), namely that it dies if it finds an
uninterpreted import:

  when (not is_interpreted) $
    let mName = GHC.moduleNameString (GHC.moduleName m) in
    ghcError (CmdLineError ("module '" ++ mName ++ "' is not interpreted"))

I think it would work much better if it just warned you, instead of
dying.  This makes it unusable any time you import something
precompiled.

Now some looking at the README of hasktags leads me to:

"In the past this tool was distributed with ghc. I forked and added some
features.  hasktags itself was moved out of the ghc repository. Then I only
verified that my fork finds at least as much tags as the one forked by
Igloo."

That makes me feel a little queasy.

A google search for hasktags igloo turns up
http://hackage.haskell.org/trac/ghc/ticket/1508 
whose title is "hasktags program needs replacement"
which makes me feel even more queasy.

So I guess my question is, what are us disciples of "the one true
editor" to do?  Thanks in advance for you sage advice.

Best wishes,
Henry Laxen




_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: which tags program should I use?

Evan Laforge
> suggests using :etags in GHCI or hasktags, or gasbag.  Of the three,
> hasktags comes closest to "working" but it has (for me) a major
> inconvenience, namely it finds both function definitions and type
> signatures, resulting in two TAGS entries such as:
>
> ./Main.hs,63
> module Main where 6,7
> main :: 24,25
> main = 25,26

The hasktags I have has a --ignore-close-implementation flag, you
might try that.

> So I guess my question is, what are us disciples of "the one true
> editor" to do?  Thanks in advance for you sage advice.

I'm also a user of the one true editor (namely vim ;) and I'd be
interested in an answer to that too.  Every once and a while I go look
at the various tag programs to see if there's anything that works
better than hasktags.  The continuing proliferation of tags programs
implies that others are also not satisfied with what's out there, but
no one is devoted enough to the cause to devote the effort to make the
One True Tags program.

I like the idea of hothasktags since I used qualified imports and have
lots of name clashes, but it's very slow on 300+ source files.  It
might be possible to use per-file tags and attach tag regeneration to
the buffer-write, but that would require a bit of extra vim/emacs
hackery.

I tried gasbag and had some issue, I'll have to try that again to
remind myself.  I'll try out the latest couple of entries.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: which tags program should I use?

Erik Hesselink
In reply to this post by Henry Laxen
I use hothasktags [1] which works very well. The only problems are
sometimes with obscure extensions, where haskell-src-exts (which
hothasktags uses) can't parse the file, but that happens very rarely.

Regarding speed: it takes 2-3 s on about 250 source files totaling
about 25000 lines on my laptop.

Regards,

Erik

[1] https://github.com/luqui/hothasktags/

On Sun, Sep 25, 2011 at 15:41, Henry Laxen <[hidden email]> wrote:

> Dear Group,
>
> I have a simple question, that as far as I can tell, has never really
> been well answered.  I would like to generate TAGS files for haskell
> source.  Reading the http://www.haskell.org/haskellwiki/Tags page
> suggests using :etags in GHCI or hasktags, or gasbag.  Of the three,
> hasktags comes closest to "working" but it has (for me) a major
> inconvenience, namely it finds both function definitions and type
> signatures, resulting in two TAGS entries such as:
>
> ./Main.hs,63
> module Main where 6,7
> main :: 24,25
> main = 25,26
>
> Now when I do an emacs find-tag (I use icicles) I will always have to
> choose which tag I want to visit, and the completion buffer contains
> something like:
>
> main ::
> hs/Main.hs
>
> main =
> hs/Main.hs
>
>
> Granted, this is a minor (and very specialized) complaint, but if
> hasktags were to select only ONE of either the type signature (my
> first choice) or the function definition, (if no type signature) this
> annoyance would disappear.
>
> I also tried using etags, which I think would work, but it seems to
> have one killer bug (feature), namely that it dies if it finds an
> uninterpreted import:
>
>  when (not is_interpreted) $
>    let mName = GHC.moduleNameString (GHC.moduleName m) in
>    ghcError (CmdLineError ("module '" ++ mName ++ "' is not interpreted"))
>
> I think it would work much better if it just warned you, instead of
> dying.  This makes it unusable any time you import something
> precompiled.
>
> Now some looking at the README of hasktags leads me to:
>
> "In the past this tool was distributed with ghc. I forked and added some
> features.  hasktags itself was moved out of the ghc repository. Then I only
> verified that my fork finds at least as much tags as the one forked by
> Igloo."
>
> That makes me feel a little queasy.
>
> A google search for hasktags igloo turns up
> http://hackage.haskell.org/trac/ghc/ticket/1508
> whose title is "hasktags program needs replacement"
> which makes me feel even more queasy.
>
> So I guess my question is, what are us disciples of "the one true
> editor" to do?  Thanks in advance for you sage advice.
>
> Best wishes,
> Henry Laxen
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: which tags program should I use?

Claus Reinke
In reply to this post by Evan Laforge
>> suggests using :etags in GHCI or hasktags, or gasbag.  Of the three,
>> hasktags comes closest to "working" but it has (for me) a major
>> inconvenience, namely it finds both function definitions and type
>> signatures, resulting in two TAGS entries such as:

Some customization required? Tweaking the output format is
usually the easiest part of a tags file generator. Alternatively, add
information about the kind of tag, have both tags in the tags file,
and do a little filtering on the editor side (in Vim, try ":help
taglist()"),
so that you can go to the type or value level definition with different
key combinations.

> I'm also a user of the one true editor (namely vim ;) and I'd be
> interested in an answer to that too.  Every once and a while I go look
> at the various tag programs to see if there's anything that works
> better than hasktags.  The continuing proliferation of tags programs
> implies that others are also not satisfied with what's out there, but
> no one is devoted enough to the cause to devote the effort to make the
> One True Tags program.

Some notes from someone who has written his share of tags file
generators:

1. there are trade-offs to consider: fast or detailed? incremental (file by
    file) or tackle a whole project at once? should it work on syntactically
    incorrect code (regexes, parsing, or parsing with recovery)? how much
    detail can your editor handle, without requiring extra scripting (emacs
    tags files can't hold as much info as vim tags files can - the latter
are
    extensible; but to make use of that extra info, scripting is required)?

2. once you reach the borders of what quick and dirty tags generators
    can do, things get interesting: haskell-src-exts makes it quite simple
    to generate top-level tags with proper parsing, if the file can be
parsed;
    GHCi knew about top-level definitions anyway, so it was easy to output
    that as a tags file; but what if the file cannot be parsed? what if the
    import hasn't got any source (not untypical in the world of GHC/Cabal)?
    do the interface files of the binary modules have source location info??
    how to handle GHC/Cabal projects, not just collections of files?

3. what about local definitions? what about non-exported top-level
    definitions? Here the editors get into difficulties handling too many
    tags without distinguishing features. As it happens, I've recently
    released support for (lexically) scoped tags in Vim, with a generator
    for Javascript source:

    http://libraryinstitute.wordpress.com/2011/09/16/scoped-tags-support-for-javascript-in-vim/

    I'd love to see a scoped tags generator for Haskell (the scoped
    tags format is language independent, and the Vim script support
    could be reused), but that would double the size and complexity
    of a simple parsing tags generator (beyond traversing top-level
    definitions: traversing expressions, handling Haskell's complex
    scopes) or require additional code for a GHCi-based generator
    (of course, a regex-based generator would fail here); also, the
    Haskell frontend used would need to record accurate source spans;

    I'd also like to see type info associated with scoped tags, for
    presentation as editor tooltips, at which stage the air is getting
    thin - parsing alone doesn't suffice, so you need parsing,
    type-checking, and generic scope-tracking traversals of typed
    ASTs, with embedded source span info; perhaps an application
    of scion, but by then you're beyond simple; and all that power
    comes at a price of complexity, speed and brittleness: no tags
    if parsing or typing fails, where the latter requires reading
    interface files, or handling whole projects instead of isolated files..

Perhaps combining a quick and dirty incremental tags generator
with a detailed and sound full-project generator could do the trick?

Or, you could drop the tags file generation and treat the detailed
and sound full-project analyzer as a server which your IDE/editor
could ask for info about code, while reloading only those files that
change (as if the language query server was a programmed GHCi
session running in the background). Which seemed to be the
direction scion was heading in..

    https://github.com/nominolo/scion

Tags files are a nice interface between language-aware generators
and general purpose editors/IDEs, but they are limited. I still think
it is worth using them, in extended form, but if your editor doesn't
make such extension easy, or if you want to leverage the complex
language frontend for other purposes, switching from offline
tags file generators to online language query servers makes sense
(even back in the C days there were both ctags and cscope).

I hope this helps to explain why there is no One True Tags program?

Claus
http://clausreinke.github.com/
 


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe