I'm not sure what to do about the "python2" issue...
In PEP 394 it says: [quote]in preparation for an eventual change in the default version of Python, Python 2 only scripts should either be updated to be source compatible with Python 3 or else to use python2 in the shebang line
Being source compatible with Python 3 requires being very careful about what syntax you use, I don't see this working in practice. Using "python2" on the "#!" line is what I did, but seems to cause problems on operating systems that are not yet compatible with the PEP 394 recommendations.
Changing the "#!" line to use just "python" instead of "python2" will work on most systems, but not all, since some systems have Python 3.x as "python". And I expect that will become more common as time progresses.
Maybe an alternative is to use "python2.7" on the "#!" line, since we now depend on 2.7 (OrderedDict is new in 2.7) and there is an official statement that there will never be a Python 2.8.
So, I tried getting twee by cloning from https://github.com/tweecode/twine and it creates html files that have javascript errors that I don't get when I use tweego (which appears to have gone away...probably because he thought that it wasn't useful any more....that sucks).
So, basically, when I create my HTML file with tweego, all is good. I have created a number of macros and have added a fair amount of javascript. When I switch to the twee in the current master on github, I get a few error alerts such as: Miggys Library: Unexpected token ILLEGAL Nothing has changed, only the program used to parse my code.
I'm using SugarCube header and have several [script] passages. I can dig around later to see if I can identify what is broken in case there is something in particular in my code that this version of twee doesn't like, but it will be much later.
So, basically, when I create my HTML file with tweego, all is good. I have created a number of macros and have added a fair amount of javascript. When I switch to the twee in the current master on github, I get a few error alerts such as: Miggys Library: Unexpected token ILLEGAL Nothing has changed, only the program used to parse my code.
Until recently Twine's twee would reorder passages while tweego would preserve the input order, but that difference was removed a few days ago, so if you are on the current master branch the order of passages should be the same.
You could try to install the "xmllint" tool, it's part of the libxml2 tools. Then run it like this:
I do see some weirdness at the end of the xmlformat output: what looks to be JavaScript code interpreted by xmllint as HTML tags. So it's possible JavaScript code is not escaped somewhere where it should be.
Edit: Actually there is a ton of error messages from xmllint on stderr, which I didn't see before because I hadn't redirected stdout yet. It seems xmllint doesn't like the fact that SugarCube uses "<" and ">" unescaped inside JavaScript sections. Is that a bug or is that something that is considered valid in HTML5? In the old days, JavaScript code was inserted as an HTML comment (<!-- -->) to avoid parsing problems.
mignon wrote:
I'm using SugarCube header and have several [script] passages. I can dig around later to see if I can identify what is broken in case there is something in particular in my code that this version of twee doesn't like, but it will be much later.
I'm not aware of any reason why that wouldn't work. I've done some coding using twee, SugarCube and custom JavaScript and it works fine for me.
tweego (which appears to have gone away...probably because he thought that it wasn't useful any more....that sucks).
As nomdepony pointed out, tweego is still there (the source and all six binary distros). While I haven't worked on it in a while (and the code is hacky), I don't plan to remove it.
mth wrote:
I do see some weirdness at the end of the xmlformat output: what looks to be JavaScript code interpreted by xmllint as HTML tags. So it's possible JavaScript code is not escaped somewhere where it should be.
That's likely from the header's own <script> tags. I'm unsure if xmllint's HTML parsing mode is correctly following the old specs, let alone the current ones wrt <script> content restrictions. I'm not sure any of the headers follow the restrictions either, but that's a different kettle of fish.
mth wrote:
Edit:[/b] Actually there is a ton of error messages from xmllint on stderr, which I didn't see before because I hadn't redirected stdout yet. It seems xmllint doesn't like the fact that SugarCube uses "<" and ">" unescaped inside JavaScript sections. Is that a bug or is that something that is considered valid in HTML5? In the old days, JavaScript code was inserted as an HTML comment (<!-- -->) to avoid parsing problems.
It's not a bug, that's been considered valid in every version of HTML since the introduction of the <script> tag. And JavaScript used to be wrapped in comments to protect it from really old browsers who didn't understand the <script> tag at all, and would thus actually render the JavaScript as part of the page that hasn't been necessary or recommended in well over a decade.
I think we're looking in the wrong direction here. mignon, I just compiled an old version of AIWW with Twee (v1.4.2) and I'm not seeing any issues so far. If you've edited your library since with the Chrome developer tools or one of the online JS testing suites (e.g. jsfiddle), check your check your library, you may have some embedded non-printing characters that are mucking things up.
PS: Twee (v1.4.2) doesn't seem to be maintaining passage order properly.
PS: Twee (v1.4.2) doesn't seem to be maintaining passage order properly.
Hmm, it seems I accidentally used the wrong version of the "twee" script when doing the tabs to spaces conversion. I'll fix it and submit a pull request.
Edit:[/b] Actually there is a ton of error messages from xmllint on stderr, which I didn't see before because I hadn't redirected stdout yet. It seems xmllint doesn't like the fact that SugarCube uses "<" and ">" unescaped inside JavaScript sections. Is that a bug or is that something that is considered valid in HTML5? In the old days, JavaScript code was inserted as an HTML comment (<!-- -->) to avoid parsing problems.
It's not a bug, that's been considered valid in every version of HTML since the introduction of the <script> tag. And JavaScript used to be wrapped in comments to protect it from really old browsers who didn't understand the <script> tag at all, and would thus actually render the JavaScript as part of the page that hasn't been necessary or recommended in well over a decade.
Ah, you're right, that was indeed to prevent JavaScript from being displayed. Maybe I remember having to escape it because I used XHTML for quite a while; I think XML parsers won't have exceptions for the <script> tag.
It's invisible characters. If you care, here is a barebones example that causes the problem. I can fix my code, so I'm not saying it's a bug, but if you are curious, they are in the set statement...unless the forum software removes them. There should be three of them.
:: Start Testing asdf
:: StoryBanner Testing again
:: StoryTitle ASDF
:: StoryCaption This is just a test. Please move along
OK, I think those are just tabs...so, the official twee (at least in it's current state) seems to get confused when you put tabs in a set statement...or...something:)
Ah, you're right, that was indeed to prevent JavaScript from being displayed. Maybe I remember having to escape it because I used XHTML for quite a while; I think XML parsers won't have exceptions for the <script> tag.
Well, to be fair, parsing <script> tags properly is a bugbear (still). I'm not sure there was more than a set of half-assed guidelines the last time libxml2 was in active development. Heck, there wasn't even a detailed spec on how HTML should be parsed until HTML5 (this largely only mattered in the case of non-compliant documents, however, most documents were exactly that).
Hello, I just downloaded twee and tried to use it with SugarCube but I get the following error, even with a minimal source file that only has a Start:
Error: this passage does not exist: START_AT
I'm new to twine but as a Linux user I definitely prefer to use a text editor and the command line which is why I downloaded twee instead. I did try the Twine GUI and I also tried the v2 beta and it just felt clunky in comparison to the text editor workflow that I'm used to.
If you grabbed the version from the Twee repository, then that's your problem (AFAIK, the that repository is out of date).
The current version of twee is part of the Twine repository. I'd say just grab the whole repo, but if you only wanted what you absolutely needed, then I believe you could get by with the following files:
twee untwee header.py tiddlywiki.py tweelexer.py tweeregex.py version.py
If you grabbed the version from the Twee repository, then that's your problem (AFAIK, the that repository is out of date).
Thanks for such a speedy response! Yes, that was indeed the problem. I had read through the thread but didn't notice that the pull request was in the twine repository and not the twee repository. It works fine now, as far as I can tell.
Comments
In PEP 394 it says:
[quote]in preparation for an eventual change in the default version of Python, Python 2 only scripts should either be updated to be source compatible with Python 3 or else to use python2 in the shebang line
Being source compatible with Python 3 requires being very careful about what syntax you use, I don't see this working in practice. Using "python2" on the "#!" line is what I did, but seems to cause problems on operating systems that are not yet compatible with the PEP 394 recommendations.
Changing the "#!" line to use just "python" instead of "python2" will work on most systems, but not all, since some systems have Python 3.x as "python". And I expect that will become more common as time progresses.
Maybe an alternative is to use "python2.7" on the "#!" line, since we now depend on 2.7 (OrderedDict is new in 2.7) and there is an official statement that there will never be a Python 2.8.
So, basically, when I create my HTML file with tweego, all is good. I have created a number of macros and have added a fair amount of javascript. When I switch to the twee in the current master on github, I get a few error alerts such as: Miggys Library: Unexpected token ILLEGAL Nothing has changed, only the program used to parse my code.
I'm using SugarCube header and have several [script] passages. I can dig around later to see if I can identify what is broken in case there is something in particular in my code that this version of twee doesn't like, but it will be much later.
Until recently Twine's twee would reorder passages while tweego would preserve the input order, but that difference was removed a few days ago, so if you are on the current master branch the order of passages should be the same.
You could try to install the "xmllint" tool, it's part of the libxml2 tools. Then run it like this: That should show the differences in output.
I do see some weirdness at the end of the xmlformat output: what looks to be JavaScript code interpreted by xmllint as HTML tags. So it's possible JavaScript code is not escaped somewhere where it should be.
Edit: Actually there is a ton of error messages from xmllint on stderr, which I didn't see before because I hadn't redirected stdout yet. It seems xmllint doesn't like the fact that SugarCube uses "<" and ">" unescaped inside JavaScript sections. Is that a bug or is that something that is considered valid in HTML5? In the old days, JavaScript code was inserted as an HTML comment (<!-- -->) to avoid parsing problems.
I'm not aware of any reason why that wouldn't work. I've done some coding using twee, SugarCube and custom JavaScript and it works fine for me.
As nomdepony pointed out, tweego is still there (the source and all six binary distros). While I haven't worked on it in a while (and the code is hacky), I don't plan to remove it.
That's likely from the header's own <script> tags. I'm unsure if xmllint's HTML parsing mode is correctly following the old specs, let alone the current ones wrt <script> content restrictions. I'm not sure any of the headers follow the restrictions either, but that's a different kettle of fish.
It's not a bug, that's been considered valid in every version of HTML since the introduction of the <script> tag. And JavaScript used to be wrapped in comments to protect it from really old browsers who didn't understand the <script> tag at all, and would thus actually render the JavaScript as part of the page that hasn't been necessary or recommended in well over a decade.
I think we're looking in the wrong direction here. mignon, I just compiled an old version of AIWW with Twee (v1.4.2) and I'm not seeing any issues so far. If you've edited your library since with the Chrome developer tools or one of the online JS testing suites (e.g. jsfiddle), check your check your library, you may have some embedded non-printing characters that are mucking things up.
PS: Twee (v1.4.2) doesn't seem to be maintaining passage order properly.
Hmm, it seems I accidentally used the wrong version of the "twee" script when doing the tabs to spaces conversion. I'll fix it and submit a pull request.
Ah, you're right, that was indeed to prevent JavaScript from being displayed. Maybe I remember having to escape it because I used XHTML for quite a while; I think XML parsers won't have exceptions for the <script> tag.
This is correct - what you're actually supposed to do is use a different set of tags.
But you shouldn't really be used an XML linter in the first place because Twine's HTML5 output is not XHTML.
xmllint has an HTML parser mode (the --html argument), but apparently it doesn't treat <script> the same as web browsers do.
I just downloaded twee and tried to use it with SugarCube but I get the following error, even with a minimal source file that only has a Start: I'm new to twine but as a Linux user I definitely prefer to use a text editor and the command line which is why I downloaded twee instead. I did try the Twine GUI and I also tried the v2 beta and it just felt clunky in comparison to the text editor workflow that I'm used to.
The current version of twee is part of the Twine repository. I'd say just grab the whole repo, but if you only wanted what you absolutely needed, then I believe you could get by with the following files:
Thanks for such a speedy response! Yes, that was indeed the problem. I had read through the thread but didn't notice that the pull request was in the twine repository and not the twee repository. It works fine now, as far as I can tell.