atg / chocolat-public

Public bug tracker for the private chocolat project
http://chocolatapp.com
180 stars 4 forks source link

Add support for custom symbol implementations #1760

Open tobiastom opened 8 years ago

tobiastom commented 8 years ago

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 commented 8 years ago

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: '…' 
}