Question asked! .t is TADS3 source…
Sure, added it to the list.
Thanks also for me ! Johnny, Eric and Joey gives many interesting snippets, and albeit the copy function works as designed, remain that is faster downloading than pasting in an editor then saving…
Best regards from Italy,
So… a follow up @Dannii : is it possible for the .t files to remain .t files once uploaded, instead of being converted to .txt? It’s just that every time I share a new file with a tester or fellow TaDS developer, I have to include a reminder for them to erase the .txt extension before using it. Thanks!
Is that an issue? Let me see…
catch.t (2.3 KB)
Doesn’t seem to be an issue for me. Are you attaching a file that already has a .txt? If you’re on windows it may hide file extensions - I’ve always disabled that setting because it causes more trouble than it helps.
I did note that downloading a .t from Github adds a .txt. Not sure what’s up with that, but it doesn’t seem to be happening here.
test.t (3.8 KB)
Hm, the first .t I uploaded via DM to someone else showed up as file.t.txt. Maybe we’re good now?
I hadn’t realized this was straightforward to configure. Between things I’ve wanted in the past and things I expect people will want in the future, I’d like to request:
Do people use .i6 and .i7 as file extensions? It’s not the style used in the usual toolchain.
In 10.1, if you compile with inform7 using the --source argument instead of
--project, the Inform 6 output is given the suffix
inbuild recognizes .i7 as an I7 source suffix as well as
.txt), and the inform7 command-line docs use .i7 in an example of compiling a Basic Inform program; I’m unsure whether that’s meant to imply that
.i7 may be preferred for Basic Inform per se source files.
I’m not saying we can’t add these, but are these necessary bare file extensions you would want to upload directly to the forum?
The reason the forum has a whitelist like this is we don’t want trolls uploading every random kind of file that’s going to hose the website or other people’s computers. While extensions with .i7x are pretty innocuous, isn’t .json one that could do weird browser things? (I’m asking since I’m not knowledgeable about this specifically.)
And if you’re wanting to trade a .exe file or anything else exotic, wouldn’t it be better wrapped in a .zip? And if it’s a small file I know people can work around by changing the extension to .txt so the recipient can change it back.
Again, not grumbling about the work because it’s an easy change. My only concern is if everything is whitelisted, the whitelist is no longer a security feature. Are people frequently flummoxed that they can’t trade bare .json files here instead of emailing them privately? (Again, without any intention of snark because I don’t know.)
.json files are completely safe. I don’t think there’d even really be a issue with allowing raw .exes to be uploaded, but it probably encourages good general practices to zip them.
It could be an attack vector for some plausible future browser bug… ultimately, so could .txt files if browser coders get up to something really goofy. But I doubt json would rise to the risk-level of zipfiles, which in turn don’t have a scratch on PDFs.
I have had to rename yaml files to upload them here, but maybe I’m the only one, and it was only twice.
JSON has probably become commoner than yaml as a basis for config files and, in particular, JSON is what Inform 7 v10 uses for project metadata so someone will want to upload it at some point.
But it’s not some horrible outcome if they need to rename it when that day comes.
Maybe you could allow
.html files as well for twine users (full disclosure: I’m not totally disinterested; my games generate html transcripts).
Somebody was tripped by that earlier today:
I mean, we can just turn it off and allow every file type. Maybe it needs to be a conversation of “what is a dangerous file extension we should not allow”?
I just may be overcautious via ignorance, but isn’t html forbidden because it can do weird things to your browser?
If it makes the browser download the file rather than opening it then it could be safe. But I don’t know if it would do that. I couldn’t see a clear answer on the Discourse Meta forum. Probably best to just require HTML files to be zipped.
Unzipped HTML files are definitely an attack vector. There are ways to force files to be downloaded rather than displayed, but I don’t trust browsers to be consistent about that.
I added those except for .i6 and .i7. If they end up being used they can be added later.