_[lang]_proc_search and context-tagging

[bercikr]

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

[Ryan]

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...

 

[ScottW, VP of Dev]

I'm curious why you have items that you don't want tagged. What is the downside of having these items tagged?

[bercikr]

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

[ScottW, VP of Dev]

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.

[bercikr]

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

[Dennis]

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:

Code: [Select]

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.

[bercikr]

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

[Dennis]

hmmm, block should be a yellow box.  Is that a yellow, magenta, or black "f" icon you are seeing?

[bercikr]

Its the magenta 'f' that shows up for functions in other files. Here's the line I am using:

Code: [Select]

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?

[Dennis]

"block" is indeed correct.  Post your entire proc-search, that will make it easier to see what's happening.

[bercikr]

Code: [Select]

_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);
}

[Dennis]

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".

[bercikr]

Well we are using the SlickEdit Core and I do believe that is based on an earlier slickedit version than 13.0.

[Ryan]

Yea it's based on 12.0.3 (Help > About SlickEdit Core)...have you tried using statement instead of block?