What method should I use for a "search all symbols" feature?

[Danny Tuppeny]

VS Code has a "search all symbols" feature (Ctrl+T). I originally implemented it with search.findTopLevelDeclarations but realised that top-level includes classes but not their fields. I just tried search.findMemberDeclarations but that doesn't include things like classes.

Does it seem sensible for me to call both of these and merge the results, or is there something that already searches everything that I've overlooked?

[Brian Wilkerson]

Calling both and merging the results seems like a reasonable short-term work-around, but it seems like we ought to provide a more convenient and performant API.

Note that search.findMemberDeclarations takes a name (such as 'length'), which makes it unsuitable for this purpose as designed. However, the implementation currently builds a regular expression by adding anchors at the beginning and end of the passed string to ensure that we don't match partial names, but neglects to escape any characters in the name itself. I don't think this was our intent, and we reserve the right to fix this in the future, but I think if you pass in '.*' as a name that we'll match every member name. (It's only because of this bug that you have any hope of using it to get the information you want.)

Brian

On Sat, Aug 6, 2016 at 5:34 AM, Danny Tuppeny <da...@tuppeny.com> wrote:

VS Code has a "search all symbols" feature (Ctrl+T). I originally implemented it with search.findTopLevelDeclarations but realised that top-level includes classes but not their fields. I just tried search.findMemberDeclarations but that doesn't include things like classes.

Does it seem sensible for me to call both of these and merge the results, or is there something that already searches everything that I've overlooked?

--
You received this message because you are subscribed to the Google Groups "Dart Analyzer Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to analyzer-discuss+unsubscribe@dartlang.org.
Visit this group at https://groups.google.com/a/dartlang.org/group/analyzer-discuss/.

[brianwilkerson]

I should have asked earlier, but... What results should such an API return? Is it just the names of any top-level declarations plus the names of all members? Do you need to know anything about the results (like where the declarations are)?

Brian

[Danny Tuppeny]

On Mon, 8 Aug 2016 at 17:01 'brianwilkerson' via Dart Analyzer Discussion <analyzer...@dartlang.org> wrote:

I should have asked earlier, but... What results should such an API return? Is it just the names of any top-level declarations plus the names of all members? Do you need to know anything about the results (like where the declarations are)?

Looking at the TypeScript results it seems to be returning absolutely everything! Classes and their fields/properties/methods, Enums and their values, and even local variables within methods (even when those files are not open)! This is similar to functionality in VS (`Ctrl+,`); I can use the same search to find a class or a property, etc.

The TypeScript one is even returning all the surface area of the base library stuff (this might be a side-effect of the `core.lib.ts` file being inside `node_modules`, I don't know if it was deliberate).

The VS Code API allows me to return an array of SymbolInformation, which includes:

• name
• location
• kind (SymbolKind)
• containerName

Here's a screenshot of how it looks:

The containerName (the text on the right) seems to be the filename for a top-level element, the class for a class-level element, the method name for local variables, etc. The Kind is used just for the icon.

I'm aware how massive this now sounds; but there's no requirement to match all the functionality. The more you can include the better, but even just top-level things and class members would be awesome without all the local variables etc.

[Danny Tuppeny]

On Monday, 8 August 2016 16:04:09 UTC+1, brianwilkerson wrote:

Note that search.findMemberDeclarations takes a name (such as 'length'), which makes it unsuitable for this purpose as designed. However, the implementation currently builds a regular expression by adding anchors at the beginning and end of the passed string to ensure that we don't match partial names, but neglects to escape any characters in the name itself. I don't think this was our intent, and we reserve the right to fix this in the future, but I think if you pass in '.*' as a name that we'll match every member name. (It's only because of this bug that you have any hope of using it to get the information you want.)

FWIW, this doesn't seem to be the behaviour I'm seeing; we get matches as if there's no anchor at the end:

==> {"id":"7","method":"search.findMemberDeclarations","params":{"name":"doT"}}

<== {"id":"7","result":{"id":"1"}}

<== {"event":"search.results","params":{"id":"1","results":[{"location":{"file":"m:\\Coding\\Applications\\NewsWoWBot\\bin\\danny.dart","offset":84,"length":7,"startLine":6,"startColumn":3},"kind":"DECLARATION","isPotential":false,"path":[{"kind":"METHOD","name":"doThing","location":{"file":"m:\\Coding\\Applications\\NewsWoWBot\\bin\\danny.dart","offset":84,"length":7,"startLine":6,"startColumn":3},"flags":0,"parameters":"()","returnType":"dynamic"},{"kind":"CLASS","name":"Danny","location":{"file":"m:\\Coding\\Applications\\NewsWoWBot\\bin\\danny.dart","offset":73,"length":5,"startLine":5,"startColumn":7},"flags":0},{"kind":"COMPILATION_UNIT","name":"danny.dart","location":{"file":"m:\\Coding\\Applications\\NewsWoWBot\\bin\\danny.dart","offset":0,"length":0,"startLine":1,"startColumn":1},"flags":0},{"kind":"LIBRARY","name":"","location":{"file":"m:\\Coding\\Applications\\NewsWoWBot\\bin\\danny.dart","offset":-1,"length":0,"startLine":1,"startColumn":0},"flags":0}]},{"location":{"file":"m:\\Coding\\Applications\\NewsWoWBot\\bin\\danny.dart","offset":313,"length":7,"startLine":21,"startColumn":3},"kind":"DECLARATION","isPotential":false,"path":[{"kind":"METHOD","name":"doThing","location":{"file":"m:\\Coding\\Applications\\NewsWoWBot\\bin\\danny.dart","offset":313,"length":7,"startLine":21,"startColumn":3},"flags":0,"parameters":"()","returnType":"dynamic"},{"kind":"CLASS","name":"Danny2","location":{"file":"m:\\Coding\\Applications\\NewsWoWBot\\bin\\danny.dart","offset":301,"length":6,"startLine":20,"startColumn":7},"flags":0},{"kind":"COMPILATION_UNIT","name":"danny.dart","location":{"file":"m:\\Coding\\Applications\\NewsWoWBot\\bin\\danny.dart","offset":0,"length":0,"startLine":1,"startColumn":1},"flags":0},{"kind":"LIBRARY","name":"","location":{"file":"m:\\Coding\\Applications\\NewsWoWBot\\bin\\danny.dart","offset":-1,"length":0,"startLine":1,"startColumn":0},"flags":0}]}],"isLast":true}} 

[Danny Tuppeny]

On Monday, 8 August 2016 16:04:09 UTC+1, brianwilkerson wrote:

Note that search.findMemberDeclarations takes a name (such as 'length'), which makes it unsuitable for this purpose as designed. However, the implementation currently builds a regular expression by adding anchors at the beginning and end of the passed string to ensure that we don't match partial names, but neglects to escape any characters in the name itself. I don't think this was our intent, and we reserve the right to fix this in the future

If you do fix this, please let me know in advance if possible; as I'm not taking advantage of it! =)