chocolat-public icon indicating copy to clipboard operation
chocolat-public copied to clipboard

Add support for custom symbol implementations

Open tobiastom opened this issue 8 years ago • 1 comments

Right now the symbol lists work for some language, and kind of work for others. Some languages don't have symbol lists at all. I would like that to change.

it would be nice to have a hook in a mixin that takes a syntax and a callback function. The callback would be used to parse a given filename for symbols and would return a JSON object.

A simple implementation might look like this:

Hooks.addSymbolParser( 'php', myPhpSymbolParser )

Whenever the mixing is used, and some file would need the symbols for a given file, the callback function would be called. A sample implementation might look like this

function myPhpSymbolParser( syntax, file ) {
    // parse the symbols and return a JOSN object. 
    // most likely this might be a php script that parses php and returns the JSON string…
    // for Javascript this might be tern
    // for less this might be a node module
}

The result of this function call should be something like this:

[{
    'type': 'class',
    'name': 'MyClass',
    'start': { 'line': 23, 'offset': 2 },
    'end': { 'line': 443, 'offset': 0 }
    'children': {
        …
    }
}]

The JSON format I really don't care much about, but it should be easy to generate the information chocolat needs.

As this would be a mixing implementation, support would fall (more or less) into the hand of the mixin author. I think this would be awesome, because then we could also add some non common symbol lists, like e.g. swagger JSON files, or some other custom formats.

tobiastom avatar Jan 30 '16 16:01 tobiastom

One more thing: it would be nice to provide languages from mixin. I see that syntax highlighting might be too much (for now?), but e.g. adding the Swagger language via an mixin, that does the symbol parking would be pretty cool.

Something like: Hooks.registerLanguage( ‚swagger’, mySwaggerObject ) and the mySwaggerObject might then implement a common interface, like:

var mySwaggerObject = {
    extensions: ['json'],
    symbolCallback: function( syntax, file ) {}
    supportUrl: '…' 
}

tobiastom avatar Jan 30 '16 16:01 tobiastom