"Jump To Method" for PN2

By Simon Steele
Wednesday, April 17, 2002

Doing the multi-language function listing jive:

This is a request for comments white paper - I need to know if this is a sensible way of doing things or not. The idea is to provide a simple list of functions in the current file on user demand - this isn't a background process thing at the moment. Using this is actually much faster than using a tree of functions etc. because you can type in a partial method name and jump to the implementation for that method.

GExperts Procedure List

The image above comes from GExperts' Procedure List add-on for Delphi. Something like this is the goal for PN but functioning in a multi-language (C++, Object Pascal, VB, etc.) manner.

The suggested method is:

Develop a simple DLL interface allowing the DLL to choose a pointer to Scintilla or a filename. There should then be a call to one or other functions depending on this choice when the program wishes to get some feedback from the dll. The DLL will then parse the file either from Disk or using the Scintilla control's features and will call back the results to programmers notepad so that it can populate its list.

Starting a parse:

bool __stdcall FPCanHandleScintilla();
void __stdcall FParseDocument(HWND hScintilla);
void __stdcall FParseDocumentFile(LPCTSTR lpszFileName);

Getting feedback from the dll:

Generally, we can get the following information from each language:

Proc / Func [: Return Type]
Method Name
Class Owned [Class Owner]
Line Number
Full Declaration
? Choice of available image indexes.

Should this information be in structures, or come through callbacks from the DLL? The DLL could pass back an array of structures like this:

struct {
	const char*	rettype;	//null for procedure (no return)
	const char*	methodname;	//should include class:: or class.
	const char*	classname;	//null for no class, or no info.
	long		linenumber;
	short		image;
}

or could pass back this structure one at a time. Both Delphi and C++ can deal with this, so that shouldn't be a problem. PN can then propagate its list as these come in - probably better to use a call per item than passing an array of them?

The reason for doing it in this way is that language afficionados can provide their own function listing DLLs where they're not provided with programmers notepad. A pascal version can use the TMWPasLex thing which will provide much better recognition than a regex match can. Additionally a C++ one could call (or build in) Ctags and return the results.

For simpler RegEx matchable languages, they can use the pointer to Scintilla to get scintilla to do the hard work. Some pascal parsing regex examples are:

function[\t ]+[a-zA-Z.]+[a-zA-Z]*[(a-ZA-Z:;, \t]*[)]*[: \t]*[a-zA-Z]+;

procedure[\t ]+[a-zA-Z.]+[a-zA-Z]*[(a-ZA-Z:;, \t]*[)]*;

These don't use particularly complicated regular expressions - the engine built into Scintilla isn't all that powerful. DLL providers could use a more powerful regex engine and get the data from scintilla or a file. That's the beauty of this system, each language can be handled in whatever way required.

The listing handlers could be used on a per filetype or a per scheme basis. Given that Schemes <> Lexers where PN is concerned a per scheme system could probably be used, with each CScheme storing information about the relevant function counter.

Please send your comments to Simon.

Back to top...