tags:

views:

279

answers:

1

My Taglist in a C code:

macro
|| MIN_LEN
|| MAX_ITERATIONS
||- typedef
|| cell
|| source_cell
||- variable
|| len_given

Taglist elements (domain):

A = {MIN_LEN, MAX_ITERATIONS, cell, source_cell, len_given}

Code snippets (codomain):

B = {"code_MIN_LEN", "code_MAX_ITERATIONS", ..., "code_len_given"}

Goal: to have bijection between the sets A and B.

Example: I want to remove any element in A, such as the MIN_LEN, from A and B by removing either its element in A or B.

Question: Is there a way to quarantee a bijection between A and B so that a change either in A or in B results in a change in the other set?

+2  A: 

I strongly doubt you can do that. The taglist plugin uses ctags to collect the symbols in your code and display them in a lateral split. The lateral split contains readonly information (if you try to work on that window, vim tells you that modifiable is off for that buffer).

What you want to achieve would imply quite complex parsing of the source code you are modifying. Even a simple task like automatic renaming (assuming you modify a function name entry in the taglist buffer and all the instances in your source are updated) requires pretty complex parsing, which is beyond the ctags features or taglist itself. Deleting and keeping everything in sync with a bijective relationship is even more complex. Suppose you have a printf line where you use a macro you want to remove. What should happen to that line? should the whole line disappear, or just the macro (in that case, the line will probably be syntactically incorrect.

taglist is a nice plugin for browsing your code, but it's unsuited for automatic refactoring (which is what you want to achieve).

Edit: as for the computational complexity, well, the worst case scenario is that you have to scout the whole document at every keystroke, looking for new occurrence of labels that could be integrated, so in this sense you could say it's O(n) at each keystroke. This is of course overkill and the worst method to implement it. I am not aware of the computational complexity of the syntax highlight in vim, (which would be useful to extract tags as well, via proper tokenization), but I would estimate it very low, and very limited in the amount of parsed data (you are unlikely to have large constructs to parse to extract the token and understand its context). In any case, this is not how taglist works. Taglist runs ctags at every vim invocation, it does not parse the document live while you type. This is however done by Eclipse, XCode and KDevelop for example, which also provide tools for automatic or semiautomatic refactoring, and can eventually integrate vim as an editor. If you need these features, you are definitely using the wrong tool.

Stefano Borini
+1 for targeting parsing. Can you clarify it a bit more? What would be the computational complexity for such algoritm?
Masi