Author Topic: regular expression driven outline parser  (Read 5598 times)

apnakon

  • Community Member
  • Posts: 27
  • Hero Points: 2
regular expression driven outline parser
« on: September 07, 2006, 10:59:03 AM »
Hi All,

This is more of a feature request - but I think that a regular expression driven outline parser, like the one that was available in Codewright, would be really neat.

It was very powerful since it was possible to allocate user defined outlining of functions, procedures, symbols etc. based on the
different regular expressions that you set up.  Very nice / deadly effective - esp. for ad hoc file types etc.

Although I think Slickedit is a great editor, one of the reasons I stayed with Codewright for so long was because of this facility.  I'd love to see it implemented into SlickEdit (I've already noticed that Slickedit has regular expression support, so I'd hope that this would not be so difficult to do).

I'd like to hear how the SlickEdit Team feels about this feature.

Many Thanks,

Adrian.

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: regular expression driven outline parser
« Reply #1 on: September 07, 2006, 03:33:52 PM »
We're always interested in ideas for new features. I'm not sure I completely understand what you're looking for, though. It sounds like you'd like to use regular expressions to drive code collapsing, what we call "selective display" in SlickEdit.  If that's correct, can you provide a few more details? I'm not an experienced Codewright user.

Are the regular expressions given in begin/end pairs?

Are the regular expressions global to all files, or do they work on a per-extension basis? You mention this is great for ad-hoc files, so that suggests global. But it seems like these could trip over each other if you work in multiple langauges.

Can you provide some specific examples of the types of things you used this on? Functions and procedures are built into most collapsing systems, including SlickEdit's.

How do you tend to use outlining? Do you start with all elements collapsed and expand the items you are interested in? Or do you start with all items expanded and collapse the uninteresting items.

I feel that most outlining systems introduce too much clutter in the display, with little pluses and vertical lines drawn everywhere. Do you like this approach, or is there an alternative you would recommend?

We've been discussing some changes to our selective display functionality, and I'd like to understand what you're doing so I can factor this into any revisions we make. Sorry for the detailed questions, but consider this like submitting a change request for your own project. I need very detailed descriptions or I'm very likely to do something other than what was requested.

--Scott

apnakon

  • Community Member
  • Posts: 27
  • Hero Points: 2
Re: regular expression driven outline parser
« Reply #2 on: September 08, 2006, 07:07:54 AM »
HI Scott,

Thanks for the reply.  I'm more than nhappy to help out!   :)

This is how Codewright set up the regex outlines - very nice and neat (please see attachment : codewright_outline_parser.bmp)
I would open the 'Customize' Window, then click on 'Outline Symbol Patterns'.

Using PL/SQL as an example (but, as I hope is clear from the bitmap above, you can set this up for *any* file type), you can see
how this is used in the bitmap 'plsql_and_outline_parser'.  I have assigned, in the outline parser, different 'little' icons for the different regular expressions I defined.  I can click on an item in the 'Outline' list and it will take me to that item in the main file.

This is *so* powerful because, as a coder writing/modifying code, or a sysprog chasing down system problems (which I do alot of - trawling through dumps/logs etc.) - I can adapt the editor to meet *my* needs exactly - *absolutely* - and easily [using regular expressions] - which I did a great deal with Codewright.  I must say that, in this respect, Codewright was magnificent, and is the major reason I used it for so long after Borland killed it. 

I'm not sure what you were referring to, but Codewright did not handle Outlining in the way that you described.  I hope that the bitmaps I've sent kind of show that.  I always felt that Codewright did this very well - and cleanly. 

As an aside, it would (also) be great if Slickedit could allow Lexer colouring to be controlled by regular expressions as well as word lists.  It would also be good if you added multiple user definable lists - currently Slickedit only has one user definable list, and I find this a little restrictive.

All that said, I think that SlickEdit is a *terrific* editor - that's why I bought it!  :)  The support for ssh/ftp is fantastic, and its speed and robustness is superior to Codewright's.  I recon if you were able to add in some of the features I talked about here, I would be in Editor Utopia!  :)

Please let me know what you think, as well as any other info you might need.

Cheers,

Adrian.



Graeme

  • Senior Community Member
  • Posts: 2796
  • Hero Points: 347
Re: regular expression driven outline parser
« Reply #3 on: September 08, 2006, 09:40:37 AM »

So this is a little like the classes or defs toolbars in Slickedit where e.g. all function names are presented in an alphabetical list - except that in Slickedit, slick "understands" the language being used whereas Codewright outlining lets you display items grouped according to their matching a regular expression.

What is a "parser type"  - it looks like Codewright also has "language understanding" that it lets you add on to ??

For a .h file, it looks like "Function" is a parser type  - so what is a "parser name" for.
Is the "Function" parser driven by a regular expression or is it built-in parsing.

What is the checkbox "use for selective display" on the outline parsers dialog?
What control do you have on the ordering in the outline window?

You could write a macro (or a simple form that let you enter a list of regular expressions) in slick C that ran a series of searches using regular expressions with "append to output" and you would get the same lists of items that Codewright is giving you  - not as pretty or as cleanly displayed though.

Graeme