SlickEdit Community

SlickEdit Product Discussion => SlickEdit® => Topic started by: blueboy on September 15, 2007, 07:27:48 AM

Title: user defined tags (similar to codewright outline parser)
Post by: blueboy on September 15, 2007, 07:27:48 AM
Hello,


I'm using slickedit for 5 days, my former editor was codewright (the last 8 years).
Now I think I have found a good replacement with slickedit V12.03.

I have found nearly everthingn't I need, but one thing ist still missing.

In codewright you can add/describe your own tags with a regex expression, these
tags will then be visible in the outline window:

e.g. I'd like to see all messages occured in this context:
 MsgId( MY_MESSAGE_X )

the regex will be:
,^[ \t]*((MsgId))\(.\c(MY_)[ \t]*[a-zA-Z_][a-zA-Z0-9_]*[^a-zA-Z0-9_]

Codewright have shown in the outline window:
MESSAGE_X

and I can jump to it by a simple click.


How can I add (in an easy way) this user defined tags in slickedit?
Must I write an own slick-c macro, or is it build in and I haven't found the location?
Title: Re: user defined tags (similar to codewright outline parser)
Post by: Dennis on September 20, 2007, 02:12:21 PM
We support this through callbacks in our macro language.  Assume you're new file extension is "xyz", if you write a "xyz_proc_search(_str &proc_name, int first_first)" function, SlickEdit will find the function and use it to scan for symbols and populate the Defs tool window (outline), as well as all other tagging functionality.

Here is an example proc_search.  All you need to do is plug in your own regular expression and you should be set to go.

Code: [Select]
_str gl_proc_search(_str &proc_name, int find_first)
{
   if ( find_first ) {
      if ( proc_name:=='' ) {
          proc_name='[A-Za-z0-9_\-]#';
      }
      search('^[ \t]*(function):b\c'proc_name'[ \t]*([(]|$)','@rih');
   } else {
      repeat_search();
   }
   if ( rc ) {
      return(rc);
   }
   _str line='';
   get_line(line);
   line=expand_tabs(line);
   int p=pos('([ \t(]|$)',line,p_col,'r');
   /* Parse out the name.  Cursor is on first character of name. */
   proc_name=substr(line,p_col,p-p_col);
   return(0);
}

Here's my attempt (untested) at plugging your regex.

Code: [Select]
_str xyz_proc_search(_str &proc_name, int find_first)
{
   if ( find_first ) {
      if ( proc_name:=='' ) {
          proc_name='[A-Za-z0-9_\-]#';
      }
      search(',^[ \t]*MsgId\([ \t]*(MY_)\c'proc_name'[^a-zA-Z0-9_]','@rih');
   } else {
      repeat_search();
   }
   if ( rc ) {
      return(rc);
   }
   _str line='';
   get_line(line);
   line=expand_tabs(line);
   int p=pos('([ \t(]|$)',line,p_col,'r');
   /* Parse out the name.  Cursor is on first character of name. */
   proc_name=substr(line,p_col,p-p_col);
   return(0);
}
Title: Re: user defined tags (similar to codewright outline parser)
Post by: Phil Barila on September 20, 2007, 03:20:49 PM
Dennis,  Although I'm not sure about blueboy's specific case, I have a similar question, but for stuff that the tagging engine currently doesn't pick up.  For example, in the Microsoft WDK, if you are writing a KMDF-based driver, you will frequently use this construct:
Code: [Select]
typedef struct _MyContext
{
   DWORD Member;
} MyContext, * pMyContext

WDF_DECLARE_CONTEXT_TYPE_WITH_NAME(MyContext, GetMyContext);
Later on, you use it like this:
Code: [Select]
pMyContext pMine = GetMyContext(myWdfObjectHandle);
Is there any way to coerce SE to parse that declaration (which has already been tagged, it can certainly find the definition of WDF_DECLARE_CONTEXT_TYPE_WITH_NAME) so that GetMyContext is recognized as a function call?
Title: Re: user defined tags (similar to codewright outline parser)
Post by: Dennis on September 20, 2007, 03:23:26 PM
@Phil:  Tools > Options > Tagging Options..., "C Preprocessing..."
Title: Re: user defined tags (similar to codewright outline parser)
Post by: Phil Barila on September 20, 2007, 03:28:51 PM
I guess I neglected to mention that I've added a few of the WDF macros attempting to do just that without success?  Maybe just adding the symbol to the preprocessor wasn't sufficient, I needed to actually define it as something?
Title: Re: user defined tags (similar to codewright outline parser)
Post by: Dennis on September 20, 2007, 03:36:04 PM
Yes.  If you just leave it blank, then you are telling SlickEdit to ignore that macro.  Also, since this macro takes arguments, you need to define the parameters as you would in the regular #define.

WDF_DECLARE_CONTEXT_TYPE_WITH_NAME(typ,nam)

define as (for example):

typ* nam(WDF_OBJECT_HANDLER* handler);

You would be best off to use the *exact* definition the way the #define is in the WDK headers.
Title: Re: user defined tags (similar to codewright outline parser)
Post by: Phil Barila on September 20, 2007, 04:28:52 PM
I may be able to get it there with enough futzing.  Here's a question that reveals my ignorance of the tagging engine.  That macro actually references a bunch of others.  Those are also tagged.  What keeps the tagging engine from doing this automatically?
Title: Re: user defined tags (similar to codewright outline parser)
Post by: Dennis on September 20, 2007, 05:03:43 PM
Yes, you will have to define those other symbols.

And, yes, tagging may know about these #define's, but there are several issues:

   1) do you want the tagging engine to do full C Preprocessing
       (severely killing performance)?

   2) alternatively, do you want the tagging engine to to a database lookup
       for every identifier it sees in order to check if it is a #define.

       Also, this technique does not work when you are building the
       database unless you do two passes, one to collect defines,
       and another to do the actual tagging.  Either way, it would
       kill performance.

   4) Some #define's are interesting and useful to expand, others are best
       left as is, and others should be ignored.  For example:

         a) #define SOME_CONSTANT 22
             void my_function(int parm = SOME_CONSTANT);

             This is best left as-is, otherwise your prototype becomes

             void my_function_int(parm=22);

         b) #define STUPID_DECL __STUPID_ATTRIBUTE(blah,blah)
             #define STUPID_ATTRIBUTE  __compiler_specific_attribute_keyword
             class STUPID_DECL MyClass { ... };

             This is best ignored.

         c) And finally, your example is an example of something that should be
             expanded otherwise you will be missing critical definitions.

How is the tagging engine supposed to guess what #define's to expand and what not to?  In general, it can't.  This is why the C Preprocessing dialog exists.  It allows you to specify what macros you want to be expanded and how.  It also lets you specify that a macro should be ignored, such as the "STUPID_DECL" above.  Finally, using it instead of trying to do full preprocessing allows us to keep performance very high.

This may seem like a pain in the neck, and I realize in your case, the preprocessing is coming from a 3rd party library and not your own code, but in general, this is the price you pay when people use the preprocessor to write code instead of using the language as intended.  I am so glad that Java and C# and most other modern languages eschew preprocessing.  There is so much more tooling that could have been done with C++ if only the preprocessing were not constantly in the way.  The same problem is rapidly becoming true for the C++ template system, as people are abusing it in even more clever ways than people have abused the preprocessor.
Title: Re: user defined tags (similar to codewright outline parser)
Post by: hs2 on September 20, 2007, 05:23:26 PM
Good explanation Dennis - and I also prefer speed over avoidance of some manual tool adjustments.
So everything will be really great as soon as the CPP setup is (optionally) workspace related ...
Any plans for v13 ?

HS2
Title: Re: user defined tags (similar to codewright outline parser)
Post by: Phil Barila on September 20, 2007, 05:49:03 PM
Thanks for the enlightenment.   :D
Title: Re: user defined tags (similar to codewright outline parser)
Post by: blueboy on September 21, 2007, 05:09:40 PM
Hi Dennis,


I have already found the 'xyz_proc_search' method, this will work for new extensions,
but what about an add on to an existing extension. I need this special parsing
in .c. A c_proc_search already exists in cparse.dll. Do you know how to add the
c_proc_search function or will SE execute both. Second question what about the
statement 'SE will find the function xyz_proc_search', is it sufficient to load
the macro during startup (just include in user.e)?


Thanks for your commitment.

BR
Robert
Title: Re: user defined tags (similar to codewright outline parser)
Post by: hs2 on September 21, 2007, 08:55:17 PM
SE finds a macro function/command after the containing <module>.e was loaded (and compiled to <module>.ex). Dunno if a macro function conflicts with an existing DLL version with the same name...
HS2
Title: Re: user defined tags (similar to codewright outline parser)
Post by: apnakon on September 24, 2007, 11:28:52 AM
Hi Guys,

For what it's worth, I'd *love* to see SlickEdit have a regular expression outline parser like Codewright did.

No offense Dennis, but the method you describe is very convoluted in comparison to what was available in CodeWright.
Some time ago I did send quite alot of info (including screenshots) of how CodeWright implemented the functionality.
They did quite a brilliant job, to be honest.  It was easily the most useful and powerful part of the editor - you could handle any language, dump file format, etc.  Incredible.

I can only hope that SlickEdit would also provide this capability sometime soon.  It would be a terrific additon to SlickEdit.  :)

Cheers,

Adrian.

Title: Re: user defined tags (similar to codewright outline parser)
Post by: jimlangrunner on September 24, 2007, 01:14:09 PM
Hi Guys,

For what it's worth, I'd *love* to see SlickEdit have a regular expression outline parser like Codewright did.

...

Hi guys.  I'd like to throw my $0.02 in here as well.  While I love the thought that SE can parse just about anything, the fact that I could, in CodeWright, set up function definitions with a total of 6 regular expressions was the reason I bought in in the first place.  They didn't have support for VB 6 property defn's built in.  It took me a short time to build a regex to "build" the outline in CodeWright.  The lack of support & a few killer bugs made me go looking for something better.  Or at least supported.

I have yet to figure out the Slick-C language (?) well enough to even begin to attempt this.  So I do without.  SE 11.0.2 does the job well enough, and a search to find other function defn's and split windows does the job for me.  I also keep VB6 & VC++ open on the side & reload as needed.

Thanks for a great product & forum to go with it.

Jim.
Title: Re: user defined tags (similar to codewright outline parser)
Post by: blueboy on September 24, 2007, 04:00:42 PM
Hi Dennis,


I have now tested your proposal and it works fine (there was only a small typo, the ',' in search statement)
for new extensions.
I have just made a new extension xyz and I have added the xyz_proc_search function to a loaded
module. But I didn't succeed in using a c_proc_search function (as already mentioned, that this may be
conflicts with the c_proc_search function of the parse dll). Usefull hint how to solve this conflict?

Second item (only a minor), how can I use a different icon/type  (I only need functions, defines and
this user defined results in the defs window and I need different icons for the function and the user defined
message).

Title: Re: user defined tags (similar to codewright outline parser)
Post by: blueboy on September 25, 2007, 07:28:55 AM
Hi Guys,



now I managed to change the used tag icon, wasn't really complicated just add something like this:

  proc_type='class';
  proc_args='';
  class_name='';
  tag_flags = VS_TAGFLAG_inclass;
  proc_name=tag_tree_compose_tag(proc_name,class_name,proc_type,tag_flags,proc_args);

It's just the question what you like to have in the tag window.

But my main problem is that I haven't found where to hook into the c_proc_search. If I use
a own c_proc_search this won't be used. So my next idea was to refer the c extension
to an own extionsion (like xyz) and than call the original c routines, but check before own
search function. C extension can't be refered:-(.

Any one an idea where to hook a own search algorithm for c extensions (only with macros, there is no plan to write a dll), it should be extend the original c_proc_search and not replace ?


Something like this should be possible too:

new_c_proc_search(...)
{
  // check own search function
 if (xyz_proc_search(...)!=0)
 {
   c_proc_search(...);
 }
}


but where is the hook? ???