You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently when hasktags encounters tags with qualified names, it puts the entire qualified name in the ctags file. For example, with the following Haskell code:
Leaving aside the spurious tags for instance for the moment, I think the second line should have A instead of MC.A.
In case it matters (or makes things simpler somehow), I believe that type and data families are currently the only place where bindings can be qualified.
(This is a follow-on to my comments on issue #39. I initially commented there due to a misunderstanding; this is a separate issue, and that one should stay closed.)
The text was updated successfully, but these errors were encountered:
Retaining qualified names is not better, because the qualification is only local: when viewing another module, if I see the name get, I cannot know just from that whether I should be jumping to the tag for get, A.get, or B.get. If there are three definitions of get with different qualifications, the tags file should list all three.
Of course, for a name like get this won't happen, because you currently cannot put qualified value-level names in binding position, as I mentioned in the original bug report. But the point stands anyway: local qualifications should be dropped when creating the tags file, so that there is a predictable tag to request when looking at things outside that local scope.
Currently when hasktags encounters tags with qualified names, it puts the entire qualified name in the ctags file. For example, with the following Haskell code:
I get the following ctags file:
Leaving aside the spurious tags for
instance
for the moment, I think the second line should haveA
instead ofMC.A
.In case it matters (or makes things simpler somehow), I believe that type and data families are currently the only place where bindings can be qualified.
(This is a follow-on to my comments on issue #39. I initially commented there due to a misunderstanding; this is a separate issue, and that one should stay closed.)
The text was updated successfully, but these errors were encountered: