Closed Templar-von-Midgard closed 2 months ago
I think the whole idea of having a fallback mapper is a very healthy. The plugin is extensible by means of the custom mappers supplied by the user. The plugin already comes with two mappers for Python and MD syntax. The mapper (e.g. MD mapper) is a very simple routine that can either access the editor object model or use raw file instead. Thus indeed if there is a mapper that uses View.symbols
approach it can be easily integrated.
Unfortunately I am not fluent in ST3 dev enough to do such a development efficiently. But if someone provides/contribute it I would gladly include it into the plugin. :)
Honestly, using the syntax file should be possible with a few definitions... ie comments linked to the comment markers, block comments, functions / classes, etc... I could look into adding something like this into my mapper ( which requires settings things up with rules - at the very least it could parse a syntax file and add the rules that way )...
No promises though - I am working on a lot and I am considering moving to Visual Studio Code as it is like ST3 and Atom but supports better panels and seems to be just as quick as ST3 and supports threading for searches... I just need to make sure it supports a few other things before I decide fully though... If I do switch, I could release what I have already at the least..
Sublime Text 3 has built-in options to support the development of this plugin, namely: the
View.symbols
function that powers built-in symbol search. Implementing a mapper for this could be a good fallback if there is no available mapper yet for the given syntax.