The thing is, I have to run discourse to test the plugin, but the plugin is just a different folder that has a symlink to the discourse plugins folder, so I'm not sure how much gitpod would be able to help with that. Not to mention to run discourse, you need to setup a database, and the whole initial setup takes a while. Plus, I prefer to run stuff directly on my system, so I don't have to rely on some website being able to handle whatever crap I'm doing.
Okay. Fair..
Am I ok to do a test here? (Like what I tried in the Part 1 topic(at least I think it was there)?)
I don't think so, because you can just look at the preview to test stuff out. When I do finish the doscourse plugin though, I will probably do some testing to make sure it's actually working.
Like I did in Part 1 is what I'm talking about.
Yeah, I don't think it's necessary. Snapblocks hasn't been added to the forum yet, so there's no reason to test it out here. Plus, you can see a preview of your post, so there's not much reason to create posts to test stuff out.
When I do finish the snapblocks plugin, and it gets added to the forum, that's when I may try and do some testing (which will probably include other people).
""
I mainly just don't want testing to turn into spam.
Ah, ok. Just asking.
the link is a typo, thats why its blocked
Oh, oops. I fixed it.
What? when did this start happening? YEASSS
I have pushed my current changes to the repo. I have gotten to a point that I'm almost ready to actually add the snapblocks rendering.
Currently is just the text inside [snapblocks][/snapblocks] into a <pre> element, with the class snapblocks-discourse, and also some custom options (like enable / disable wrap, zebra, and showSpaces). The snapblocks rendering will be done after the initial markdown parsing (replacing bbcode with html), specifically because thr discourse sanitizer is super strict, and I don't know if I'd be able to add svg elements inside the markdown parsing. Plus, if I do the snapblocks rendering after the markdown parsing, it can run synchronously, allowing the page to load faster (I don't want the heavy snapblocks parsing to slow down the page loading).
If you would like to contribute, here's the repo with the current code.
Again, I have not implemented the rendering yet. Plus, once I get it finished, I need to create a discourse meta post for it.
I am going to be out of town this weekend, so I won't be able to work on it for a while. I'm just sharing what I have now, in case someone wants to help, and so you guys know I've actually been working on it.
Oh, I'm actually also going to be releasing snapblocks 1.4.3 soon, specifically to fix a few things, and add a new function to the main api (or should this be 1.5.0, because I'm adding a new function to the api, and I might add a new block).
I GOT IT WORKING!!!!
Now I just gotta clean it up, and add a bunch of settings (and release snapblocks 1.4.3).
Something that is also great, is that selecting snapblocks, and then clicking "quote", it doesn't show a ton of css, it just quotes the text. Now yeah, it doesn't create snapblocks, but it's still better than what happens with the current scratchblocks plugin.
edit: I've got [sb] working properly, even with multiline blocks.
I've also got the settings set up
(if someone knows how to create translation keys for options, that would be great, because those values are the values that snapblocks accepts)
All I have left is to clean up the code, and have all the github actions checks not fail.
Great! Let us know when you're ready. 
Should I add the ability to use [scratchblocks] for comparability? Or should I just leave it out? I wanted to include it as a setting, but I'm not entirely sure how to access settings in the file that adds the [snapblocks] and [sb] bbcode tags.
I would just make it a synonym for [snapblocks].
That's what I was thinking of doing. Thankfully it's not hard to just add a new tag (I use the same function for [snapblocks] and [sb]).
I have released snapblocks 1.5.0
This is not a huge release, since most of the changes were to the library itself (stuff I needed for the discourse plugin).
Additions
- You can just type
pause allinstead ofpause all @pause. - Added
<> primitive []block. - Added
(compile (() @addInput) for (0) args)block. renderElement()method.- Choose which element options are accepted by setting the
elementOptionsoption to a list of options instead of a boolean. - Better error handling.
- If an error occurs in
renderMatching(), it will be logged to the console (with the snapblocks code that errored), and will continue to the rest of the elements.
- If an error occurs in
Fixes
- Fix scratch 3 high contrast pause icon.
- Fixed an error with non-existent
wrappedvariable. - Make sure style is a string.
- If a style doesn't exist, just set it to
snap, don't throw an error.
The discourse plugin is also finished, or at least ready to be added to the forum. Here's how to use it.
You can create snapblocks in a post, by typing snapblocks code inside [snapblocks][/snapblocks] bbcode tags. For example:
[snapblocks]
move (10) steps
[/snapblocks]
You can alternatively use [scratchblocks ][/scratchblocks] (there's a space to avoid the current scratchblocks plugin from messing this up) for compatibility purposes (snapblocks is a fork of scratchblocks, and there was an old Discourse plugin on the Snap! forum that allowed users to type scratchblocks inside [scratchblocks][/scratchblocks] tags).
You can also use [sb][/sb] to add snapblocks code inline.
Use the [sb]move (10) steps[/sb] block to move forward.
You can also set options inside a [snapblocks] tag.
[snapblocks blockStyle="snap-flat" wrap="true" wrapSize=100 zebra="true" showSpaces="false"]
if <[] = []> {
forever {
run ({} @addInput) with inputs [Hello world] @delInput @verticalEllipsis @addInput
}
}
[/snapblocks]
Some things to note:
- Since this plugin fixes all the issues that we had with the current scratchblocks plugin, all the workarounds will most likely break (stuff like
@</span>iconName). - Since snapblocks is (slightly) slower than scratchblocks (due to it's complexity), pages may take longer to load if there's lots of snapblocks snippets (or at least, big ones). If there's not many snapblocks on a page, it will not take any longer than usual. I tried to fix this by having it run asynchronously, but I'm not sure if it worked.
- Snapblocks does not work in the profile About me section, because I don't know (and am not worried about it), although the snapblocks snippets will still be replaced, and show up as monospace text.
Dude, this is awesome
this (script :: control) :: sensing
before {was written :: pen} :: control
snapblocks was added :: other
Huh. Do you know about a Snap! feature I don't know about?
