Multiple scripts and stylesheets

[cjneidhart]

Is your feature request related to a problem? Please describe.

Users that make extensive use of JS and CSS can easily find themselves working with a script or stylesheet that is extremely long, with no easy way to break it apart. When writing prose in a passage, every format has an easy solution to this problem (e.g. (display: ) in Harlowe). But there is no simple way to break apart scripts or stylesheets, leading users to awkward solutions such as tagging passages with script or stylesheet and manually loading them at startup.

Describe the solution you'd like.

The behavior of the "JavaScript" and "Stylesheet" buttons in the "Story" menubar would be changed. When clicked (or tapped or otherwise fired), a list of each script/stylesheet would be shown, alongside a "handle" the user can use to reorder the scripts/stylesheets. At the bottom of the list would be a button to add a new script/stylesheet. Clicking one of the script/stylesheet's names would open the editor for that script/stylesheet. Editing multiple scripts at once would cause them to stack and editing multiple stylesheets at once causes a stack, just like editing multiple passages at once causes them to stack.

The script/stylesheet editors would have a new button on their toolbar, "Rename". This would allow the user to rename that script/stylesheet.

When the story is built, all scripts will be concatenated into one <script> element, and all stylesheets will be concatenated into one <style> element. Potentially, comments could be added to the output, indicating where each pseudo-passage begins.

It is worth noting that all 4 built-in formats support multiple <script> and <style> elements within <tw-storydata>. However, changing the specification of Twine 2's output is unnecessary and offers little benefit.

This solution would necessitate a change in the storage format of Twine; either a Script type and Stylesheet type would need to be created, or a single PseudoPassage type could be used to cover both. These types might look like:

type Stylesheet {
  // ID of the parent story
  story: string;
  // The name of this stylesheet, to distinguish it from others in the same story
  name: string;
  // Body text of the stylesheet
  text: string;
}

Describe alternatives you've considered.

The only alternative to this problem I can find is to continue using bespoke tags to emulate having multiple scripts or stylesheets. However, this is cumbersome and overly reliant on the story format to enable it. It also plays poorly with syntax highlighting, since codemirror modes have no way of realizing these passages are not regular markup.

Additional context on this suggestion.

This issue is similar to #509. However, this issue is more specific and easier to implement. It can also be seen as a "stepping stone" on the way to implementing a repository-based module system, if that's desired in the future.

Presubmission checklist

• I am interested in working on code that would implement this feature request. (This is not required to submit a suggestion.)
• I have done a search and believe that an issue does not already exist for this idea in the GitHub repository.
• I have read and agree to abide by this project's Code of Conduct.

[cjneidhart]

Open questions

• Should the script/stylesheet editors be made more visually distinct from the passage editors? Currently, the main distinguisher of a script or stylesheet editor is its name. Having multiple scripts open, all named by the author, may make them less distinct from passages.

[klembot]

This is a fairly complex proposal so I'll try to be as thorough in my response as I can.

At a very high level, I feel that if authors are spending a lot of time writing JS and CSS, they would be better served by using a traditional editor and a tool like extwee or tweego. If you're writing a lot of code, you're going to miss a lot of capabilities a dedicated editor has (renaming symbols and autocomplete come to mind) compared to something like CodeMirror. But that's not necessarily a reason to not try this out.

The one thing not covered by what you've proposed is output ordering. This matters more with JS, not usually as much with CSS, but is significant. With the UI you're proposing, I think there would need to be some way for authors to specify the order. I guess you could work around this by just saying that the output goes in alphabetical order, but I think that'd lead to gross "0001 - Intro" naming schemes.

Curious if you have thoughts on a "repository-based module system, if that's desired in the future" yourself. This was something that people in the community have suggested in the past, but it never fully materialized. I'd much prefer a way for people to add bundles of CSS and JS to their stories via a URL, like story formats, instead of building a complex UI for direct editing.

Finally--a simple idea came to mind when I thought about this, which is to explore adding code folding to the JS and CSS editors. This seems like a really light implementation lift comparatively, and while it isn't as sophisticated as what you're proposing, would give people some better ways to manage lengthy JS/CSS.

[cjneidhart]

Thanks for your detailed response. Code folding definitely seems like an overall better solution.

A module system based on URLs would be a nice feature, although I haven't given a lot of thought to the logistics involved. I mainly mentioned it here because it seemed like the only similar issue.

[hituro]

This is related to my suggestion for passages with a script or stylesheet tag to just enable codemirror

These tags are meaningful in other compilers, and in Twine 1 formats, so it makes sense that the same behaviour is supported in the editor as well.