No tags for fields with getters/setters about vim-force.com HOT 8 CLOSED

Following the examples on the TagBar wiki, it seems that one can add custom rules to ctags from within vim, e.g.

let $CTAGS = '
    \ --langdef=java
    \ --langmap=java:.java
    \ --regex-java=/(SOME MAGIC PERL REGEX HERE)/\1/f,field/'

but i doubt that regexes are powerful enough to reliably detect fields with accessors.

from vim-force.com.

Padde, thanks for all your suggestions/pull-requests, I will review them when I get a chance.

With regards to identifying Apex properties via a regex - I doubt we can reliably support those because there are quite a few potential permutations of Apex property fields when property have a body, as opposed to just default {get; set;}

How would you display a property in TagBar - as two lines (1 for getter and 1 for setter) or just one?

Not sure what option is beter - support Apex Properties partially (and cause potential confusion when working with unfamiliar code), or do not support them at all until we find a reliable way of doing so.

from vim-force.com.

Hi Andrey,

i guess we will have to create a replacement for ctags in order to detect apex features reliably. The java config just won't do the trick. There's several other ctags compatible projects that generate tags for languages that aren't supported by ctags, e.g. CoffeeTags for CoffeeScript.

It shouldn't be too hard to write a simple parser that understands the basic features of Apex and generates a ctags compatible tag file. Maybe i'll start such a project some time soon ;-)

Cheers
Patrick

from vim-force.com.

I've set up a repo and hope to be working on a proper Apex tag generator soon: https://github.com/padde/ApexTags

from vim-force.com.

Good idea.

Just a suggestion - if you could keep your tag generator limited to just vim-script that would be ideal and allowed to keep the plugin portable. We could also use java (because have to use it to run ANT anyway) but JVM takes noticeable time to start and may become a substantial annoyance, especially in cases where ctags is configured to run on-save.

I am not sure how ctags works but can imagine that if apex tag generator worked on-top of ctags rather than instead-of then this could simplify the job and allowed to concentrate only on the features which ctags does not support.

from vim-force.com.

I must admit i don't like the idea of writing a parser in vim script, simply because i don't like vim script all that much and because my vim script skills are quite limited.

I would rather stick with a scripting language which would make the tag generator reusable for other editors e.g. Sublime.

Lastly, i am not sure about how i should implement my tag generator on top of ctags. My approach would be to write it from scratch including other features such as tags for tests, enumerators and so on.

from vim-force.com.

The reason I suggested to build on top of ctags is because I think you will find it more difficult to write a full parser as opposed to cover a small part which ctags does not support.

In terms of how exactly to work on top of ctags - one option (I am sure ctags supports a better way) would be to wrap ctags call such as when your script is called it calls ctags first (allowing it to cover most of the ground) and then just adds Apex Properties stuff to existing tags files that ctags has just generated.

from vim-force.com.

That would work, you're right.

A parser is needed anyway when you think about accessors in nested classes for example. I think parsing just the "outline" of a class, as i call it, should not be too hard. I'll experiment a bit and let you know when i have made some progress.

from vim-force.com.