Snapblocks (Part 3)

Share your Projects
101

Then I don't see why we wouldn't want translations. :~)

102

I don't know if it matters much, but you could compile them into one script -- though the translations aren't that large. You could potentially only load the necessary files for the language selected, which is what Snap! actually does.

Also, is there any way to change the toolbar icon for snapblocks? it'd be cool if it were the Snap! logo, or failing that, a lambda character, to distinguish it from the monospace code example. Then I can see if I can put it in the order so it will be in the default toolbar and not behind the cog menu.

103

Yeah, I could add an option to the snapblocks bundler to bundle the translations with the main library.

I mean, I can do that, cause snapblocks allows you to load singular translation files. However, would selecting the languages be site-wide, or just local language settings. I fear for local language, because when one user writes a script in one language, it won't work for another user in another language.

Yes, in fact it's defined right here

However I'm not sure how to add a non-default icon, or what all the available icons are (discourse is not great with their documentation).

For clarification, by "lots of scripts slowing down the load times" I was referring to user written snapblocks scripts/snippets slowing down the page load time. The only reason it slows it down is just snapblocks parsing all the snippets and rendering them (as the rendering is done on the client side).

104

ugh, it turns out that what I wanted is annoying on both counts. :frowning:

  • So only the plugin controls where it's loaded... you could adapt the JS like this:
 api.onToolbarCreate(toolbar => {
   toolbar.addButton({
     id: 'snapblocks',
     group: 'interactions',
     icon: 'laptop-code',
     action: function (toolbarEvent) {
      toolbarEvent.applySurround(
        "\n" + `[snapblocks]` + "\n",
        "\n[/snapblocks]\n",
        "snapblocks_text",
        { multiline: false }
      );
    },
     title: 'snapblocks_discourse.title'
    label: "snapblocks_discourse.title",
   });
 });

At least, I think that's the right set of JS

  • but the icon set is Font Awesome 6 free apparently. Which doesn't even have a lambda in its free set... you have to pay. :frowning:
  • I suspect we could add snap.svg to the font awesome svgs directory because that seems to be what discourse is using but I am not sure exactly what needs to be done. I did hack up a SVG file though... maybe this will work...

File: fontawesome-snap|0x0

but in any event this will be more effort than I expected... I don't know if it's confusing to have 2 code icons in the same visible toolbar and so it's probably best to leave it behind a menu until this is a better icon...

105

Just a couple of things I'd like to point out...

// I sure wish comments were multi-line...

Also, placing two comments next to each other breaks it.

[snapblocks]
// comment
// comment 2
[/snapblocks]

// comment
// comment 2

(Didn't mean to reply to a specific message, my bad.)

106

why isnt ring have empty space
({})

107

it's supposed to be ({}@>), [sb]({}@>)[/sb]

108

First of all, comments can be multiline

/* they can be
multiline with /* ... \*/ */
// or multiline by adding \\ \
at the end of a line
[snapblocks]
/* they can be
multiline with /* ... \*/ */
[/snapblocks]

[snapblocks]
// or multiline by adding \\ \
at the end of a line
[/snapblocks]

And as I was typing this up, I absolutely see your point about comments not being able to be placed right under each other, that's a bug that I need to fix (I also noticed that comments also get placed on blocks if they're under it not next to, so that's something I should fix).

I'm also just now seeing that the second comment still has the bold text, which it shouldn't have, so I'll also fix that.

109

Oh, oops!

110

This compact snippet is broken:

block @>::motion

block @>::motion

Yes, this can be easily worked around by adding a space before the two colons, but I think this still should be fixed.

112

That is working as intended. You have to add a space, because snapblocks will think the :: is included in @<:: (plus, adding a space makes it easier to understand that it's separate).

113

1.8.2

Fixed

  • Block prototypes in Japanese translation
  • Block highlighting
  • Fix viewport height on single scratch 3 define block (pulled from scratchblocks).
  • Default icon color is not affected by zebra coloring
  • Block wrapping in scratch 3 block prototype
  • Stacked comments breaking
  • Multiline comment with // is bolded

Basically you can actually use this now and it won't turn into the Japanese stop block.

{custom block} :: define+

{custom block} :: define+