Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First pass at ctags integration #95

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

naddeoa
Copy link

@naddeoa naddeoa commented Nov 6, 2016

This adds a bunch of ctag kinds that I find useful for myself.

Configuration options:
g:elm_ctags_config - Location of the .cnf file that ctags uses. By
default, it is defaulting to the one that I've added to this repo. I
added this option because people may have their own ~/.ctags file with
elm configuration (and other languages) already, which causes tagbar to
show duplicate entires.

g:elm_ctags_target_dirs - The directories that should be indexed by
ctags. By default, I made it ./elm-stuff and ./src so that people can
jump around their own source as well as the core library stuff.

g:elm_ctags_exe - Name of the ctags executable, just so people can point
it to /usr/local/bin or something.

Outstanding issues:

  • No scope features
  • No idea how to support signatures in ctags. I really just wanted
    signatures to show up in tagbar. I was able to get it working by
    changing the .cnf to create tag names like MyFunc (A -> B), but then
    those are then interpreted as actual tags, so you can't jump around using
    <c-]> in Vim. I'm considering having two .cnf files: one for generating
    the tags file and one for use with tagbar to get around it. The ctags
    documentation mentions the --fields+S options, but it also says that it
    only works for C family languages and there doesn't seem to be a way of
    adding it via the --regex- flags.

@naddeoa
Copy link
Author

naddeoa commented Nov 6, 2016

Thought I would throw this out there. I noticed you were starting to do some ctag stuff as I was. You probably have more experience writing vimscript than I do and I'm not sure if I'm going about it the right way yet.

I was considering somethign more substantial but I heard that there is a lot of work going into elm-format pretty soon so I wanted to hold off an anything more fancy than a ctags script.

@naddeoa
Copy link
Author

naddeoa commented Nov 6, 2016

Thought might be helpful to include a screenshot of how this ends up looking in practice atm. I'm open to suggestion of course. I do like having things like imports split out into a separate tag section, especially when I drop into other people's code and I want a quick overview of the things they depend on.

screenshot sun nov 06 2016 15 09 59 gmt-0800 pst 1262x1056

@ajhager
Copy link
Contributor

ajhager commented Nov 17, 2016

Thank you for this PR! There seem to be some problems with the regex patterns, though. Constants, functions, and ports display the names twice (perhaps they are matching twice, once for the type declaration and once for the thing itself.) Also, I am getting values in the 'contructors' section that are not actually defined in that file, but are just used (for instance True, False, Maybe, Just, etc.)

Finally, for some reason I am seeing "This branch has conflicts that must be resolved: Conflicting files ftplugin/elm/tagbar.vim", so I am unable to merge it at the moment.

@naddeoa
Copy link
Author

naddeoa commented Nov 17, 2016

I'll resolve the conflicts. I probably just have to rebase from your repo.

As for the duplicates: I had that issue too. For me, it was caused by having repeats of the regex language definitions in ~/.ctags (or other configuration locations). I packaged the ctag definition along with the addon in my commit to make it "Just work", but if you already had the definition somewhere else then they both get used. Is that the case for you? I know you must have had them at one point if you were playing around with ctags.

Do you have a pastebin or something of the file that shows the True, False etc? I didn't see that in my testing. One important note: it really only works properly on a file that is formatted by elm-format. Without making some assumptions its pretty hard to get all of these in with just --regex switches in ctags.

This adds a bunch of ctag kinds that I find useful for myself.

Configuration options:
g:elm_ctags_config - Location of the .cnf file that ctags uses. By
default, it is defaulting to the one that I've added to this repo. I
added this option because people may have their own ~/.ctags file with
elm configuration (and other languages) already, which causes tagbar to
show duplicate entires.

g:elm_ctags_target_dirs - The directories that should be indexed by
ctags. By default, I made it ./elm-stuff and ./src so that people can
jump around their own source as well as the core library stuff.

g:elm_ctags_exe - Name of the ctags executable, just so people can point
it to /usr/local/bin or something.

Outstanding issues:
* No scope features
* No idea how to support signatures in ctags. I really just wanted
signatures to show up in tagbar. I was able to get it working by
changing the .cnf to create tag names like `MyFunc (A -> B)`, but then
those are then interpreted as actual tags, so you can't jump around using
<c-]> in Vim. I'm considering having two .cnf files: one for generating
the `tags` file and one for use with tagbar to get around it. The ctags
documentation mentions the --fields+S options, but it also says that it
only works for C family languages and there doesn't seem to be a way of
adding it via the `--regex-` flags.

Hack to make sure that imports don't define tags

Currently, `import Html` will make vim jump to the import statement
instead of the Html module. This hack will make sure that the tag
generated in the import statement doesn't get jumped to.
@naddeoa
Copy link
Author

naddeoa commented Nov 17, 2016

Ok, I just squashed them into a single commit and rebased, you should be good to go now. Let me know if you prefer having the commits broken out too; I can switch it back.

I noticed one thing when I was resolving conflicts: I had a typo. I misspelled constants in mine, so that might be one source of duplication in tagbar.

@naddeoa
Copy link
Author

naddeoa commented Nov 26, 2016

Any updates here? Just noticed I was still using my own branch when I ran VundleInstall and it reset back to your repo.

@dustinfarris
Copy link
Collaborator

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants