Individual macros as plugins

[Philip-Sutton]

I think the revised Twine system for StoryFormat files - so that all StroyFormnats are treated as plug ins (even the core set of Sugarcane and Jonah) - is a good analogy for what we should do for macros.

I think that Twine should be restructured so that all macros are accessed by the core program as plug ins. I think there should be a core set of macros that come pr-plugged in. There could be an extension set of macros that come with the standard Twine package - and users could choose to plug any of these in through the preference process. And Twine users should be able to add their own macros as a plug in or thet should be able to replace any of the standard macros with a customised version.

(This means that macro code should not live in the StoryFormat header files. But the story formatting process should be able to modify the operation of macros.)

[Stormrose]

One of my main motivations for being here is extensions to the StoryFormat capabilities. I think it is important we retain the current StoryFormat system (with a few absolutely backwards compatible enhancements) because it has a simplicity that anybody that has some understanding of HTML/CSS can make changes to suit themselves. That simplicity is important. We keep the SimpleStoryFormat and then add on the ability to do new stuff as: NewStoryFormat

The general author would never even need to know the difference. Only those doing custom macros and creating NewStoryFormats would ever need to know.

Something like this proposal incorporates much of my own thinking on where a new StoryFormat system should head: we should be building the .html outputs much more smartly. This means: detecting missing macros, and automagically including macro plugins when they are needed (and excluding when they are not needed). The interaction of all this can get a bit complicated but I think probably worth it. The trick is to come up with something robust, but still maintaining enough simplicity.

[mcdemarco]

Generating the header on the fly would solve all the problems that I can see with generating new formats. I don't understand the concern about plugging in macros; I don't see any reason not to include all macros in all story files. If they're not called, they're not called.

I think we would want a new mechanism for causing different behavior of existing macros under different StoryFormats. The existing behavior of Jonah vs Sugarcane could be done with CSS and appropriate marking of the current passage. (I'm not sure how it's done now.) Alternately, we could load a second macro file into the js that could override any default macro in the full macros.js file.