Decompile to multiple files?

[tmedwards]

Allow decompiling input sources to multiple files.

Possible options:

• One file per passage.
• One file per passage type—i.e., script, stylesheet, regular.

Questions:

• Should scripts and stylesheets decompile to Twee files containing tagged passages or actual .js/.css files?

[Mochnant]

I came looking for this exact functionality. +1

[Uzume]

How about per tag? In fact it would be cool if tweego could have an option to add passage tags based on original filenames so they could be decompiled in a similar reverse fashion. The reason I ask is because grouping TwineScript passages into groups makes sense (but how would tweego know which were in what group without tagging or some other grouping?).

Also since tweego can directly compile CSS and JS files, it would be cool if it could reverse this by decompiling back into such files instead of dropping it into passages in a twee file. Of course the question becomes one of what filenames to use when decompiling. Currently there is the -o switch but that can hardly define multiple output filenames correctly. This is why I suggested tweego add source filename tags when compiling.

Also having more switches to help when HTML source that was not compiled by tweego would be good too. It should at least be possible to have some heuristic to split CSS and JS into individual files. I am not sure how grouping Twine script passages would work. Methinks human intervention would be needed (decompiling does have limitations).

[ezsh]

@Uzume , my fork can do that to some extent and provides the following options:

Source split:
  --max-depth=NUM            Maximal depth for nested passage folders (default: -1)
  --min-fragment-length=NUM  Minimal length for a passage name fragment.
                             Shorter ones will be glued together (default: 3)
  --min-group-size=NUM       Minimal number of passages in a group. (default: 2)
  --name-delim=STRING        Regular expression to split passage names and
                             group them into folders (default: \s+)

Can add grouping by tag but how reliable that can be? Which tag to select if a passage is marked with several of them? Otherwise html2twee --extract-media --split -o <destination directory> <source HTML> can decompile HTML into a file tree, extracting CSS, media, and scripts into separate files and splitting the passages into files using the default rules from above.

[Uzume]

@ezsh That is interesting and I am glad to know others are thinking of such things. Methinks I would have chosen Rust if I wanted to migrate to a new language. Perhaps I should port it and make a tweers (not too far from tweezers)? At least with C/C++ (and Rust too) it should be somewhat easier to port it to web client APIs and retarget for web assembly. Doing so might allow one to add a Twine 2 like GUI and finally have a unified command-line and GUI codebase once again.

Of course if one is interested in going so far, Twine compatibility becomes a questionable default feature. I never understood the need to keep the story format wiki markup directly in the HTML when it can never be rendered "as is" anyway (and is always dynamically pulled out and expanded before stuffing it in the main "passages" stage). I am also not a fan of all the special names (e.g. passage special names). It seems to me all the configuration details could be centrally located and controlled easily enough.

[ezsh]

Why do you want to port it to Web when the sole purpose of the Tweego project was a local command-line compiler that can be used to assemble large projects on desktops?

[Uzume]

@ezsh

Why do you want to port it to Web when the sole purpose of the Tweego project was a local command-line compiler that can be used to assemble large projects on desktops?

I do not want to port it to the web as per se. I am more interested in a unified code base that powers both a command line and a GUI visualization.

Twine 2 is close if it would just incorporate/combine command line functionality into it. There are a few older and mostly unmaintained forks/applications of Twine 2 for such purposes but as long as they are separate code bases and one is developed without the other they will diverge and one will eventually become unmaintained. Some examples include:

• klembot/twine-utils
• klembot/grunt-entwine
• videlais/extwee

It also becomes problematic to make large changes like drastically changing the base Twine format, etc. without having a unified join command-line and GUI set of tools in one development repository.

[synackisback]

This feature is needed yup!

[felix9]

I think I'd like faithful bidirectional translation: if you tweego multiple files, it should create a Twine .html file with tags or other metadata that will let tweego deconstruct it back to the original files.

And this should let someone edit the story in Twine, and then easily propagate the changes back to the twee files, which makes several types of collaborative workflow easier.

I think a sensible implementation would be to add a tag like "tweefile:filename.tw" to each passage.

• This won't work for special passages like StoryData, or script/stylesheet passages, so those will need special handling, perhaps send them to default filenames, with command-line options to override.
• If multiple passages go to the same file, try to preserve the order that's in the original file. I think most of the time, it should be good enough to just use the order of the passages in the .html file. But perhaps there are cases where it should try to be smart about minimizing diffs when updating a twee file.

(If this seems sensible, I can try to implement it)

[synackisback]

Okay bidirectional using tweego is straightforward. I should just need to add .twee to each generated file. It will then allow you to compile a .html file again as expected. Can additional tagging be a separate feature. The ability to compile and decompile back and forth can be completed and tested this weekend.

…

On Fri, Aug 12, 2022, 4:33 PM felix ***@***.***> wrote: I think I'd like faithful bidirectional translation: if you tweego multiple files, it should create a Twine .html file with tags or other metadata that will let tweego deconstruct it back to the original files. And this should let someone edit the story in Twine, and then easily propagate the changes back to the twee files, which makes several types of collaborative workflow easier. I think a sensible implementation would be to add a tag like "tweefile: filename.tw" to each passage. - This won't work for special passages like StoryData, or script/stylesheet passages, so those will need special handling, perhaps send them to default filenames, with command-line options to override. - If multiple passages go to the same file, try to preserve the order that's in the original file. I think most of the time, it should be good enough to just use the order of the passages in the .html file. But perhaps there are cases where it should try to be smart about minimizing diffs when updating a twee file. (If this seems sensible, I can try to implement it) — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVCQEWHK35JVQQPSLP2VBWLVY3NK7ANCNFSM4J62OUIA> . You are receiving this because you commented.Message ID: ***@***.***>