better generation of vi ctags in ghci

[Peter Hercek]

Claus Reinke wrote:
> Haskell isn't like other languages. If you search on source lines of
> definitions, that'll break every time you change a pattern, parameter
> name, parameter order, clause order, ..
This is what I do. The whole line is searched to avoid as much of false 
positives as possible. So far I did not get any false positive in my 
code with this approach.

> ; if you search on less than the full line, you get additional 
> misleading matches, especially because you
> can only search forward or backward, not both (also, the fallback of
> /^<tag>/ won't work for infix operators, classes, data, ..).
>
> Ideally, one (well, I at least;-) would like a mixed approach: start with
> source line, figure out if the line is right, if yes, done, if not, 
> then search
> (starting from the old position). But that seemed to be beyond posix 
> tags, so I stuck with line numbers.
I tried some form of that (set position before the expected loction 
before searching). It could be done better but then the tag file would 
get big (inline all the code for each tag, or we would need some 
functions defined outside of the tags file). Anyway the reason I dropped 
this was that my vim did not parse this file correctly and tag kinds (as 
defined in the vim tags file) were not shown in the :tselect list. So I 
decided it is not worth it for now. It would be cool to have something 
better but I do not know whether it is possible aside from just writing 
an interactive compiler (something like yi people are trying - I do not 
know how far did they get).

>> * All top level symbols defined in a module are added to the tags 
>> file. Even the non-exported ones. These are marked as static (file:) 
>> so the default tag selection (Ctrl-]) works fine based on the file 
>> you started the search from.
>
> Thanks, I had meant to do this, don't know why I didn't (you use the new
> static tag format, not the old, I assume?).
I use the latest format:
{tagname} {TAB} {tagfile} {TAB} {tagaddress} {term} {field} ..
Where {tagaddress} is a search expression looking for whole lines.
 
>> * Tags get kinds added so you can select whether you want to get to a 
>> type constructor or a data constructor (that is if you share names 
>> between the two).
>
> You mean 'kind' in the tags file sense, using it to record namespace, 
> similar to haddock's t/v distinction?
I mean kind in the tags file sense. I do not know about haddock's t/v 
distinction so I cannot compare to it.
So far I use:
* v (varId),
* t (typeCon),
* d (dataCon),
* c (class).

>> * In general it is a nice addition to vim haskellmode. If you search 
>> for help on symbols in libraries then opening haddock is cool. If you 
>> search for help on a symbol in your project then opening the tag in a 
>> preview window (Ctrl-W} or ptselect) is cool.
>
> That's why I suggested the addition in the first place!-) Thanks for
> taking it further.
NP, it is great! I did not know there is at least one more person 
wanting better tags. I did not even know about ghctags. Otherwise I 
would probably just use them if they are any good (generate non-exported 
symbols too and use search patterns instead of the line numbers ... so 
they are at least a bit useful after some edits). Ok, the reason I care 
about tags to be useful after some edits is that for some of my files it 
takes some time to compile them in ghci. And I don't  want to think 
about regenerating them regularly. Now I need to regenerate them only 
when the tag cannot be located or it found an incorrect place (which did 
not happen to me yet).

> for GHC's sources, which GHCi :ctags couldn't, last time I tried). A 
> secondary issue was what to do with non-interpreted modules
> (probably: just skip, and rely on them having their own tags files).
Skipping is fine with me.

>> * If your code happens to have definitions on lines which happen to 
>> exist more times in one source file then it may put you at an 
>> incorrect location. I doubt it will ever happen but if anybody thinks 
>> it is really bad we can keep the original format of vim tags too. 
>> Then e.g. :ctags would generate tags with line numbers and :ctags! 
>> would generate tags with search expressions.
>
> See above for other things that can go wrong with search-based tags,
> so I'd prefer to have both options.
Ok, I can add it. Generating line numbers instead of search patterns 
will be quicker too. For big projects, the time difference may be 
noticeable.
So what about UI? :ctags would generate tags with line numbers and 
:ctags! would generate tags with search patterns? Or will we add an 
argument to :ctags to specify what kind of tags we want? This option 
would break ghci UI backward compatibility.

Peter.