free software resistance
the cost of computing freedom is eternal vigilance
### i-think-we-can-rule-out-neocities-for-blame-here
*originally posted:* nov 2024
so trying to debug this is more for fun and curiosity than anything else.
also if gemwiki was to blame, id prefer to fix it if its not too much trouble.
im not sure it is gemwiki, but im pretty sure neocities isnt to blame.
basically, i copied the code from this page to "create" an editor:
=> 2024/she15.py
i say "create" with quotes, because im already the author of that code, its been online since march (at least 7 months ago) and its been on neocities since october. if i copy and paste it im only creating a new copy.
but when i do this, to get the code to work i have to capitalise every instance of the word "Control", because something (browser, site, css, my javascript) thinks its an html tag.
its not. but first, it was easier to fix the application itself:
=> 2024/she16.py
she 1.6 exists for two reasons- the primary reason is to fix the appto command so that it saves a file in utf-8. thats what most features of she are designed to do, but i tried to appto a file the other day and it stopped mid-write (the program continued, the write did not) because it encountered a unicode apostrophe.
ive fixed that, and ive also fixed the way the code for the keyboard shortcuts is displayed wrong on this website. heres the diff:
```
39c39
< self.ver = "1.5"
---
> self.ver = "1.6"
120c120
< outfile.write(each + nl)
---
> outfile.write((each + nl).encode('utf-8'))
310,316c310,316
< self.textarea.bind('', self.new_file)
< self.textarea.bind('', self.open_file)
< self.textarea.bind('', self.save)
< self.textarea.bind('', self.save_as)
< self.textarea.bind('', self.ctrlt)
< self.textarea.bind('', self.ctrlt)
< self.textarea.bind('', self.qu)
---
> self.textarea.bind('<' + 'Control-n>', self.new_file)
> self.textarea.bind('<' + 'Control-o>', self.open_file)
> self.textarea.bind('<' + 'Control-s>', self.save)
> self.textarea.bind('<' + 'Control-S>', self.save_as)
> self.textarea.bind('<' + 'Control-b>', self.ctrlt)
> self.textarea.bind('<' + 'Control-t>', self.ctrlt)
> self.textarea.bind('<' + 'Control-q>', self.qu)
```
same as the code itself and the diff on the page i took that from, the "before" part of the diff displays "Control" without capitals. it doesnt do it on this line: Control, Control, Control. but thats because there are no brackets. its html tags, and things the page thinks are html tags, that are affected. "Control-S" isnt an html tag, not even if you add angle brackets, but when you add the brackets the page thinks it is.
im not going to get the people who make python-tkinter to change this, and its really not their fault. just a spoiler- im going to tell you what ive tried to figure this out so far, but ive basically ruled out neocities (ill tell you how) and ive probably ruled out my script.
it just gets weirder from there. ive fixed the only example of this i care about (the latest version of she is unaffected, by design) but im still very curious.
lets start with a workaround- if you click "view source", youll find the instances of code that say "control" on this page are actually "Control" when you view the source. in the fixed version, its enough to add ' + ' to the code which convinces whatever does this to do it differently. thats the workaround for my python source- im not saying its elegant.
because gemwiki isnt a LOT of code, i started by looking there. you can do that yourself if you want, heres a link:
=> ../gemwiki.js
thats the "engine" which displays this and most of the pages on the site. the precursor of gemwiki is freewiki, and a few pages still use that. but i dont like writing webpages anymore, i prefer to work with gemtext. gemwiki lets me write gemtext but still display it on a website. that means if you view source, you still get the gemtext version. it means i dont have to recompile when theres an edit to the gemtext. it would make converting the website to a gemlog much easier- its almost there already.
if you did look at the javascript, you may find this part a bit sus- i did:
```
function linkproc(s) {
if (right(s.trim(), 4).toLowerCase() == ".gif" || right(s.trim(), 4).toLowerCase() == ".jpg" || right(s.trim(), 4).toLowerCase() == ".png" || right(s.trim(), 5).toLowerCase() == ".jpeg") {
return '.split()
';
}
return '' + fixlink(s.trim()) + '';
}
```
obviously thats the culprit, right? i mean i dont think its actually returning a string thats corrupted, and i dont think its to blame. but if im wrong, ill feel silly so lets rule it out:
```
function linkproc(s) {
return s;
}
```
thats the only part of the script that might do this in a way thats obvious, and making linkproc(s) just return s without other processing doesnt change anything. maybe this doesnt rule out the whole script, but for now the mystery continues.
i wanted to rule out neocities, so i saved the page and downloaded it. i downloaded gemwiki.js and also the style.css, so i could load them in the browser without neocities.
just to be clear, copying the page to a local folder changed nothing- neocities is innocent here. the page i downloaded isnt tampered with- i checked in a text editor, it still happens in the browser. just like with neocities, view source and its fine. view the page and it removes caps from the code. disable the suspected function and it still happens.
how else can we rule out the script? i tried pasting the same code with just pre tags and that was the only html, but guess what happens:
```
< self.textarea.bind('', self.new_file)
< self.textarea.bind('', self.open_file)
< self.textarea.bind('', self.save)
< self.textarea.bind('', self.save_as)
< self.textarea.bind('', self.ctrlt)
< self.textarea.bind('', self.ctrlt)
< self.textarea.bind('', self.qu)
---
> self.textarea.bind('<' + 'Control-n>', self.new_file)
> self.textarea.bind('<' + 'Control-o>', self.open_file)
> self.textarea.bind('<' + 'Control-s>', self.save)
> self.textarea.bind('<' + 'Control-S>', self.save_as)
> self.textarea.bind('<' + 'Control-b>', self.ctrlt)
> self.textarea.bind('<' + 'Control-t>', self.ctrlt)
> self.textarea.bind('<' + 'Control-q>', self.qu)
```
lol, that isnt helping. i realise the solution to that is sort of html 101, and maybe i need to make the script output entities more thoroughly, but its already doing better than pre tags by themselves- the "tags" that arent tags just get hidden without the script.
i dont write many tkinter programs, and anyone having this problem can fix it by clicking view source. as for pinpointing the issue, i havent yet. at least not with confirmation, or with a more elegant and more complete fix.
if you suspect the css file, i did. heres the css for this page, that page and most of the site:
```
body { background-color: #fbfbfb;
color: #111111;
line-height: 1.7em;
font-family: monospace; font-size: 1.3em;
alink
}
pre { font-weight: bold;
color: #fcfcfc;
background-color: #000000;
padding: 5px;
overflow: auto;
}
span { color: #111111;
font-family: monospace;
}
ul { color: #111111;
font-family: monospace;
}
h1 { color: #111111;
font-family: monospace;
}
h2 { color: ##111111;
font-family: monospace;
}
h3 { color: #111111;
font-family: monospace;
}
blockquote { color: #111111;
background-color: #e5e1d4;
padding: 5px;
overflow: auto;
font-family: monospace;
}
a:link { color: #000099; font-weight: bold; }
a:visited { color: #000099; font-weight: bold; }
a:active { color: #000099; font-weight: bold; }
```
its fun to note that the internet archive mangles this even worse- ia mangles even "view source" on both pages, while the non-archived versions are BOTH ok without the archive.
but it doesnt mangle them the same way- the "fixed" version (archived and viewed with "view source") replaces the angle brackets with the entity or html shortcut, which is not valid tkinter code. the previous version preserves the brackets (it doesnt mangle them)- though it removes the capitals even with view source, which is worse than the non-archived version. so the non-archived version is slightly better.
if i want to fix even the archived version, i have to stop using brackets altogether and just use chr(60) and chr(62) in their place. i also have to use chr(38) for ampersand- that is, i want to fix my python code so that archive.org doesnt screw it up. but for now, the "live" version of she16.py is working on neocities and offline- with view source and also on the page that gemwiki displays.
im happy with version 1.6, but im not as happy with html- this really is why i like gemtext. if you want to point out that javascript is more at fault than html- yeah, theres some truth to that. but id like to think the internet archive people know and care about their script more than i care about mine, and they have more websites to think about preserving code from.
heres a summary of versions 1.5 and 1.6, especially regarding this issue:
1.5:
* doesnt have the unicode fix for the appto feature
* doesnt display properly on this website (live)
* renders on this website properly with "view source" (live)
* doesnt display properly on ia version of website (archived)
* doesnt render properly on ia version with "view source" either (archived)
1.6:
* has the unicode fix for the appto feature
* displays properly on this website (live)
* renders on this website properly with "view source" (live)
* doesnt render properly on ia version with "view source" (archived)
* but, renders/displays properly on ia version (archived)
thats 3/4 ways that 1.6 works- you can get a proper, working version live or archived.
to make the archived version work with view source (4/4) i would have to at least abandon angle brackets and ampersand in the code, and use chr(60), 62 and 38 instead.
the code i copied and pasted to a new local file from the archived version (not view source) not only matched with diff -w, it even had the same sha256 hashsum. the latter of course depends even on how many newlines follow the code, but the archived version is very far from useless as-is.
even the older version 1.5, from the diff, gives a pretty good idea how trivial it is to get it working- 1.6 is meant to cater better to people who dont know python, and just want the code to run.
license: 0-clause bsd
```
# 2018, 2019, 2020, 2021, 2022, 2023, 2024
#
# Permission to use, copy, modify, and/or distribute this software for any
# purpose with or without fee is hereby granted.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
```
=> https://freesoftwareresistance.neocities.org