Extend features to `NeuronGroup` and `Synapses` definitions

[mstimberg]

Currently, highlighting/completion/verification are only done in Equations definitions. Without much additional work, we could also extend this to NeuronGroup and Synapses, when they directly define equations as their model argument.

[Mohamed-Sobea]

Hi @mstimberg,

I'm interested in this project for GSoC and I'm looking at this issue to get a better understanding of the codebase.

I've checked the logic in brian.injection.json.
Since model is a named argument, should the new trigger look specifically for the model= keyword? Also, is there a preferred way or a specific script you use to test the syntax highlighting?

[mstimberg]

Hi @Mohamed-Sobea. Happy to hear that you are interested in this project. To clarify this issue: NeuronGroup and Synapses both accept an Equations object wrapping a string, or directly a string (which then gets wrapped into Equations internally). Only Equations objects currently get highlighted:

eqs = Equations("dv/dt = -v/tau : volt")  # ← will be highlighted
group = NeuronGroup(100, eqs)

group = NeuronGroup(100, Equations("dv/dt = -v/tau : volt"))  # ← also highlighted

group = NeuronGroup(100, "dv/dt = -v/tau : volt")  # ← not highlighted
group = NeuronGroup(100, model="dv/dt = -v/tau : volt")  # ← not highlighted

As you can see from the last two examples, model can be a named argument, but it can also be given as a positional argument, so we'd have to support both use cases (and technically, spurious whitespace as in NeuronGroup(100, model = "...") is correct as well.

It has been a while since we worked on this project, so I don't remember all the details clearly, but I think to do everything we want to do without making the code too complex, we'd probably have to replace the regex-based parsing by proper AST parsing at some point. Ideally, we could re-use some work for this from other Python extensions, but not quite sure whether this is possible.

[Mohamed-Sobea]

Thanks @mstimberg for the detailed clarification! I spent some time looking into both the named and positional argument use cases.

I know that one of the core aims of this GSoC project is to "Implement a smart and robust detection of equation strings." As an immediate first step toward that goal, I just opened a PR (#12) that uses Textmate injection rules to robustly detect and highlight the named argument scenario (model=...), including handling spurious whitespace and escaped quotes as you mention.

Regarding the positional arguments (NeuronGroup(100, "dv/dt...")), I realized that relying on Regex to parse them is unreliable. For instance, the equation string is the 2nd argument in NeuronGroup(N, model) but the 3rd argument in Synapses(source, target, model).

Trying to write a purely regex-based finite state machine to track argument positions across different constructors could lead to unmaintainable code. I think, as you suggested, that AST parsing might be the better long term solution.