You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the scarce available magics are part of the xeus-cpp codebase, and adding a new one means rebuilding and releasing xeus-cpp. A plugin system would avoid that. We could leverage the plugin system here (https://github.com/QuantStack/xplugin) . Xplugin would add the possibility to discover magics at runtime
The text was updated successfully, but these errors were encountered:
We would eventually want a generic mechanism to register / fetch magics in xeus. So we could start with a proto in xeus-cpp before going for the generic solution and eventually have xplugin as a dependency in xeus.
I think we could introduce a plugin system for cell magics. It would be pretty helpful to the end-users.
Magics in xeus-cpp are registered into a magics_manager class, that inherits from a preamble which is used for detecting special inputs in the cell before deciding to parse the code.
Currently, the scarce available magics are part of the xeus-cpp codebase, and adding a new one means rebuilding and releasing xeus-cpp. A plugin system would avoid that. We could leverage the plugin system here (https://github.com/QuantStack/xplugin) . Xplugin would add the possibility to discover magics at runtime
The text was updated successfully, but these errors were encountered: