I’m not entirely clear on this part—why not just leave echoing on?
It may not be an issue anymore. Before, when using hyperlink commands, it would print an extra blank line, which was annoying. It goes away if you turn echo off, but you can’t turn it back on mid-game.
This was the original thread about it: Development thread for Bisquixe (asking for js/jquery code review) - #12 by zarf
It may no longer be relevant, which would be great!
Ahh, I see. My inclination would be to ask the interpreters to fix the bug instead of working around it in library code, but I’ll look at SME’s source and see what it entails!
All of the code is completely copied from some code angstmurf posted on this forum years ago, so no thought on my part went into it at all!
It strikes me that there’s something very weird about the way styles are being set in Bisquixe, and I wonder if doing it in a different way would push off the need to adjust the character limit in all but very extreme cases.
I can see that you set the stylesheet using the following phrase:
css-set-fast ".class; attribute; value"
But why is it done that way? That means that css-set-fast is parsing its input out into three parts, doesn’t it? Wouldn’t it make more sense to do it like this?
css-set-fast "class" "attribute" "value"
Or, if you want to also support things like special IDs:
css-set-fast "#my-id" "attribute" "value"
css-set-fast ".some-class" "attribute" "value"
Although I think that doesn’t quite work with the way phrases are defined in I7; but there’s a good reason for that, and to be honest, I think it might be more readable if it were written like this:
set css "attribute" to "value" on selector ".class"
Or if you prefer something shorter, then maybe:
set-css ".class" -> "attribute" = "value"
Is there a good reason why it’s all packed into a single string? Does splitting it up help avoid the character limit at all?
I believe these Glk functions take their input as a single string broken up by semicolons, so the maximum length Inform can make a C string will always be a bottleneck either way.
Hmm, that’s too bad then. But still… I do think what I described would be a better way to expose the function in I7, and that at least means it can guarantee there’s no spaces around those semicolons.
Bisquixe does that because I couldn’t understand Inform 6 arrays. I’m refactoring over the summer so I might have better luck then (I recently used Inform 6 arrays in a game I’m helping someone else write).
If you have a code snippet that works that is an improvement I’d be happy to incorporate it!
By “code snippet” do you mean something like an implementation of the phrasing I described?
Well, without any I6 arrays, you could do:
To set property (property - a text) of class (class - a text) to (value - a text):
css-set-fast "[class];[property];[value]".
Which I think is what Celtic was suggesting.
That’s indeed almost the exact code I would’ve posted. Or for the shorthand:
To set-css (selector - text) -> (attr - text) = (value - text):
css-set-fast "[selector];[attr];[value]".
I do notice that @Draconis put the parameters in a different order than I did, but that order seems fine too.
Yeah, my goal in I7 is always to make the code read as close to natural English as possible, even if that means changing the conventional CSS order of things.
Well, my version also changed the conventional CSS order, putting the selector last instead of first.