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.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
