[Haskell-cafe] Re: How to browse code written by others

[Claus Reinke]

>>> If you go this route, I will shamelessly promote hothasktags instead
>>> of ghci.  It generates proper tags for qualified imports.
>> What do you mean by "proper" here?
>
> I think Luke means that if you use qualified names then hothasktags can 
> give you better location information than current ghci ctags.

GHCi :ctags doesn't output tags for qualified names (though it
probably should), but that isn't enough for proper handling of
qualified imports. I believe hothasktags is meant to output
multiple tags per target, one for each module referencing the
target. But that would rely on scoped tags.

> I discussed this with Luke before and I sumarrized what would need to be 
> done to imporove ghci ctags to support qualified names better. Here is the 
> post which explains it with an example:
>
> http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/73116

The problem with that example is that all occurrences of B.x point
to b.hs and C.x always points to c.hs, so it doesn't test the scoping
aspect of static tags. For instance, if you are in b.hs, and try ':tag C.x',
you'll still be sent to c.hs, even though that isn't in scope (see also
':help tag-priority').

If I add a file d.hs that is the same as a.hs but with the qualifiers
exchanged:

module D () where
import qualified B as C
import qualified C as B
localAct = do
  print B.x
  print C.x

and try to add corresponding scoped tags by hand, then I don't
see the scoping being taken into account (though my Vim is old
7.2 from August 2008). Depending on sort order of the tags file,
either all B.x point to b.hs or all B.x point to c.hs. So, one either
gets the wrong pointers in a.hs or in d.hs.

> I did not go to add this to ghci ctags since I barely ever use qualified 
> names so it is a non-issue for me. Also propper support for scoped tags 
> would include some vim macro which (on ^] key-press) tries to find a 
> qualified name first and only after a failure it would try to find plain 
> name without qualification. So if one wants to use it well he/she needs 
> first select the name in visual mode and only then pres ^]. (Or one should 
> use full ex commands for navigation like :tselect.)

One could redefine 'iskeyword' to include '.', but that may not
always be what one wants. haskellmode also uses a script,
though not yet for ^].

>> Your suggested use-case for such a feature is interesting, but
>> we're getting into an area where "live" calls to a scope resolution tool 
>> might make more sense.
>
> Och I would like to have a "vim" with full incremental parser for Haskell 
> ... with things like AST being drawn in a pane, intellisense and 
> completion on symbols but also on grammar/syntax, re-factoring options and 
> all the goodies this could provide. It will not be a vim any more. 
> Probably won't happen in my lifetime either but I can dream :)

The main thing standing in the way is Bram's strict interpretation
of ':help design-not'. It seems to be an overreaction to Emacs as
an OS, wanting to keep Vim small and simple. Ironically, adding
one standard portable way of communicating with external tools
would allow to make Vim smaller (removing all those special
case version of tool communication). And semantics-based
editing is wanted in all languages. So the feature has been
rising and is currently topping the votes:-)

http://www.vim.org/sponsor/vote_results.php

Just keep Vim for what it is good at, and add a way to interface
with language-aware external tools doing the heavy lifting (the
old Haskell refactorer had to use sockets for the Vim interface,
the Emacs interface was rather simpler in that respect).

Claus

> PS: Thanks for your vim support.
You're welcome.