I'm realizing that the $nl I used to make the comment blocks distinct could also be used on the other blocks with cogs - are there any other blocks that you (@qw23) want to remove the cogs from?
Not really.
Okay, that means we're done. Thanks for all your help!
Hey, you know how there are all those hidden blocks in the "MORE stream blocks..." block? What if we were to add this block:
Then the user could easily show all the more advanced tools and have them available in the palette. We could include the block in the "MORE stream blocks..." block like this:
What do you think, @qw23?
Love your suggestion … Why not skip the MORE … block altogether, and replace it with a SHOW / HIDE … block with a switch, or something?
Even more radical: show or hide all library blocks, groupwise (demo based on Streams library 2.0).
I wonder what @bh thinks of all this.
Something like this?
Clicking the Boolean switch while the block is in the palette (or anywhere) will turn the visibility of the blocks on and off.
I think that might be overkill...
Fine with me.
You’re probably right. I just like to explore an idea as far out as possible.
Alright, I will update the project!
That's always a good idea.
PS: With my own modified version of your block, I got this satisfying effect: ![Screen Recording 2025-04-07 161426.mp4 [video-to-gif output image]](https://cdn.forum.snap.berkeley.edu/original/3X/5/c/5c36417677566916370a4b0e3fb68eea5a7582e3.gif)
All else being equal, I think loading a library should make its user-intended blocks visible, without requiring metacognition about libraries.
In this particular case, the MORE BLOCKS block was a compromise regarding our various differences of opinion. I generally hate compromises, but I think this one has worked pretty well for us. Part of the compromise is that we made some blocks available, but not readily available. I'm not eager to undo that.
What about this instead:
Well for one thing, I don't think "advanced" actually describes this motley collection of blocks. Some of them are clearly helper functions not meant for users at all. Some are compromises for speed. And some, as I said, embody disagreements between us. So I think only some are good candidates for a SHOW ADVANCED BLOCKS block.
I agree, “advanced” isn’t the best of characterisations. Let’s keep it at “more”, or “other”.
the defaults need to be list <<true>> @<> and list <<false>> @<> for the switch to appear as false in the palette instead of empty, if I'm not mistaken.
Sure. I just had to whip up some block label 
.
Of the blocks I decided to show? Which ones are helper functions? I don't see any of them being helper functions...
There are two that are used as demoes - are those the blocks that you are talking about?
What do you think of this:
or this
You're right, I misspoke. I was thinking of MAP OVER KEEP FROM MAP, which is an efficiency hack, but users can use it.
Are you thinking you'd show the extra blocks at the bottom of the palette, or distribute them by category with the others? If we have to do this, I guess I'd prefer at the bottom, because part of the reason for hiding them was to keep the palette readable (which is why I'd just as soon not do this at all), although that makes these blocks undiscoverable.
If/when Jens gets around to implementing drawers, that'd make me happier about this whole idea.
I see. That makes sense. I might try fiddling with the block order when I have the time.
The main reason why I wanted a show more blocks block was because not having the blocks in the palette doesn't just make them undiscoverable - it makes them somewhat unusable. I rely heavily on having all of my screen space available to use, so I don't like needing yet another block editor window open to access the hidden blocks (via duplication, a hassle in itself). I could go through each block and unhide them individually, but that would be a lot of work too.
I wasn't thinking you'd keep it open; I was thinking you'd copy out the one block you actually want and then close the editor.
Sorry about the delay, I have now got a few options figured out. Feel free to propose any changes. Firstly, there is the block order:
Integrated Into Existing Groups
Included in Separate Groups
Secondly, there is the method of showing the blocks:
Separate Show and Hide Blocks (alternatively can be shown in the palette)
One Block to Both Show and Hide (alternatively can be shown in the palette)
Individual Control Over Visibility of Blocks Through the Block Editor
I feel @mark4sisb experimenting with different approaches to disclose relatively large libraries is interesting. Including the use of recently added Snap! features.
I don’t see any difference.
I would go for an intermediate level, and I would make the user switch (groups of) blocks’ visibility from the palette area instead of from within a block’s script.
Sorry, I was just experimenting with the hidden blocks. I have them shown by default now.
Edit: Here is a third option for block order (most blocks are integrated into their corresponding categories, only the HOFs/uniques are not): Snap! Build Your Own Blocks
By the way, I forgot to mention that the fourth option for how to show the blocks is that there is no option (other than through the block editor, right click, in palette).
I'm also toying with a slight modification to the look of the show more blocks block to make it into a kind of divider in option 2: Snap! Build Your Own Blocks