SlickEdit Community
Archived Beta Discussions => SlickEdit® Core for Eclipse => Topic started by: bercikr on June 02, 2008, 03:22:52 PM
-
Ryan,
I have a number of files for which I would like to show items in the outline view, but I would not like to insert them into context-tagging, however it seems to be the default for context tagging to add these items. How do I tell SlickEdit which items i would like to tag and which items to ignore?
Thanks,
Rob
-
I think that it's impossible to have something show up in the outline view without it being tagged...the outline view is from context tagging...
:(
-
I'm curious why you have items that you don't want tagged. What is the downside of having these items tagged?
-
Well, I'll give you an example. We have a number of Sections within certain language files, often very many...between 5-20 say and we have lots of these files(not gonna go count though) :). Its very important to have these items in the outline view for our users since they need them to navigate within the file. However, outside of the individual files these are never referenced and so when we try and do some other syntax-expansion/code assist type of stuff, all these Sections show up as globals and really make finding the relevant global functions more difficult. Essentially these tags litter the database and make it somewhat less useful to find the 'real' tags.
-Rob
-
Can you share more about this? What language are you using? Do you have an example of how those symbols are defined? I'm trying to understand if there is some characteristic about them that we could use to filter them out of completions and still have them appear in the outline.
The challenge is finding a way to mark some as symbols as of local interest only or to specify which of the tagging mechanisms use those symbols. A better understanding of your code might help us design something that addresses this.
-
Well the language(s) we are using are all custom in-house so I can't really share too much about them...nothing top secret or anything but there are over 8 of them and it just wouldn't be feasible to give all the details.
The ideal way to accomplish this would be to add an _[extension]_ignore_tag callback or alternatively a separate _local_proc_search hook just for setting up the outline view. It shouldn't be incredibly difficult to add something like this or perhaps something like this is already available and I am just not aware of it.
-Rob
-
Tag them as statements. Statements are never transferred to the tag file.
You will need to add the following to enable statement tagging in the Defs tool window:
int [lang]_are_statements_supported() {
return 1;
}
The statement tag types include: statement, if, loop, break, continue, return, try, pp, block
For you case, I would recommend using "block" or "pp"
There is a secondary solution, but it doesn't appear to work the way you might want.
We have a tag flag, VS_TAGFLAG_ignore, if you give items this tag flag, the items
will still be put in the tag database, but all of the context tagging queries will ignore them.
A third solution is to tag the symbols as "static", then their scope will be restricted to the
current module (as static's are in C and C++). This would have a somewhat similar effect
as using the ignore flag.
You can pass back the flags from your proc-search using tag_tree_compose_tag(),
which you should be using already.
-
Cool, just re-tagged and it looks like that took care of it. I noticed that it displays the function 'f' icon for blocks, is there any way to instruct it to use something different. I think I was using the 'form' keyword before because i thought the icon looked good. If its not possible its not a big loss, just would be nice. Thanks Dennis!
-Rob
-
hmmm, block should be a yellow box. Is that a yellow, magenta, or black "f" icon you are seeing?
-
Its the magenta 'f' that shows up for functions in other files. Here's the line I am using:
proc_name = tag_tree_compose_tag(proc_name,"","block",VS_TAGFLAG_static);
I'm not really sure if "block" is the right argument. Is it?
-
"block" is indeed correct. Post your entire proc-search, that will make it easier to see what's happening.
-
_str generic_process_search(_str &proc_name, int find_first)
{
_str specific_search = '^[\t ]*(SECTION[\t ]+'proc_name'[\t ]*;|FUNCTION[\t ]*'proc_name'[\t ]*\([^\)]+\)[^:]*:[^;]*;|DIAGNOSTIC[\t ]+'proc_name'[\t ]*;|PROCEDURE[\t ]*'proc_name'[\t ]*\([^\)]*\)[^;]*;)';
_str general_search = '^[\t ]*(SECTION[\t ]+[^;]+;|FUNCTION[\t ]*[^\(]+\([^\)]+\)[^:]*:[^;]*;|DIAGNOSTIC[\t ]+[^;]+;|PROCEDURE[\t ]*[^\(]+\([^\)]*\)[^;]*;)';
_str search_string = general_search;
if (find_first && proc_name :!= "") {
search_string = specific_search;
}
if ( find_first ) {
search(search_string,'UI>?');
} else {
repeat_search();
}
if ( rc ) {
return(rc);
}
_str line='';
get_line(line);
_str eatit;
if(pos('^[\t ]*SECTION',line, 1, "UI")){
parse line with eatit proc_name ';';
proc_name = tag_tree_compose_tag(proc_name,"","block",VS_TAGFLAG_static);
//message(proc_name);
}else if(pos('^[\t ]*DIAGNOSTIC',line, 1, "UI")){
parse line with eatit proc_name ';';
proc_name = tag_tree_compose_tag(proc_name,"","block",VS_TAGFLAG_static);
}else if(pos('^[\t ]*PROCEDURE',line, 1, "UI")){
_str args = "";
_str ret_type = "";
_str params[] = getParamNamesFromFunctionLine(line, false);
int i=0;
for(;i<params._length()-1; i++) {
args = args '' params[i] ', ';
}
if(params._length()>0) {
args = args '' params[params._length()-1];
}
parse line with eatit proc_name '(' eatit ')' eatit;
proc_name = tag_tree_compose_tag(proc_name,"","func",0,args, ret_type);
messageNwait("are we here2: " proc_name);
}else { //handle the function case here
_str args = "";
_str ret_type = "";
_str params[] = getParamNamesFromFunctionLine(line, false);
int i=0;
for(;i<params._length()-1; i++) {
args = args '' params[i] ', ';
}
if(params._length()>0) {
args = args '' params[params._length()-1];
}
parse line with eatit proc_name '(' eatit ')' eatit ':' ret_type;
proc_name = tag_tree_compose_tag(proc_name,"","func",0,args, ret_type);
//messageNwait(proc_name);
}
return(0);
}
-
I assume that the function you posted is being called by another wrapper function with the "[lang]_proc_search()" name. FYI, the "proc" in "[lang]_proc_search" stands for "procedure", not process.
Either way, I set up a small test and it is working fine, block is being tagged as a block (square yellow box). The only explanation I could have for you getting different results is if you are back-revved. Are you using 13.0 (SlickEdit 2008)? If you are on an earlier version like 12.0.3, you could use "statement" instead of "block".
-
Well we are using the SlickEdit Core and I do believe that is based on an earlier slickedit version than 13.0.
-
Yea it's based on 12.0.3 (Help > About SlickEdit Core)...have you tried using statement instead of block?
-
statement does not seem to work even using the [lang]_are_statements_supported callback you mentioned. I did a quick search through the macro directory and didn't see that callback referenced anywhere so I'm not sure it's even applicable to this version of SE.
-Rob
-
Define "does not seem to work". With "block", which was a new tag type added in 13.0, you said you got the wrong bitmap. What bitmap do you see when you use "statement" instead of "block"?
The callback is checked in _are_statements_supported(), which is in listproc.e. True, it really doesn't make a tremoundous amount of difference, except for enabling the menu option to show or hide statements in the Defs tool window. In your case, since you are inserting statements using sort of a back-door mechanism, turning off showing statements in the Defs tool window won't really make a difference anyway.
-
When i say, "Does not work" I mean nothing shows up in the outline view at all when I change "block" to "statement".
-
ok, I think you have two options at this point:
1) you could use "label" instead of "statement"
2) you could right click in the Outline view and turn on "Show Statements"
-
Label works ok. I get a black square box instead of the magenta 'f'. So, does it really matter what I choose now that I have chosen the VS_TAGFLAG_static? Is that the reason these aren't showing up in my tag files any longer or is it the "block" command that is causing that?