I guess set () () () works too.
/, +, *, and - are already searchable title texts.
Yes, but I just wanted to show the clunkines of having long text before a small operation.
and yet there are already a half dozen set blocks :(
(which is why i suggested what I did)
I don’t think there’s a simple general principle about title text length. Jens doesn’t like it when the palette has to scroll horizontally, so he errs on the side of terseness. I want everything to be self-documenting, so I err on the side of verbosity.
This was a big issue for me in writing the APL library. The Big Idea in APL is what we call hyperblocks, the automatic extension of scalar operators to work on multi-dimensional arrays. But a second important design idea in APL is extreme terseness. Function names never have words in them, not even in the case of functions that have word-names in standard math notation. So, for example, cos(x) is 2◯x. (1 is sin, 2 is cos, etc.) But the goal of APL-in-Snap! is to make APL programming accessible to people who didn’t grow up with that notation. So in the manual Appendix B you’ll find things like
P.S. Now I’m thinking maybe I should make an “APL library (terse names)” in which you really would say 
, even though nobody would use it except me. :~)
It is set () () () not set whatever () to () or even set of ().
yes? but either way you’re typing in set and getting way too many other set blocks.
I count 17 of them, which still fits in one screenful. Although loading SciSnap! probably adds more. I agree that that’s a lot, though. Are there other such cases, or is it just SET?
That was me! I think it’s a terrible idea to have in Snap! (even though I implemented it), because it’s blatantly copying Scratch and I just don’t think it fits. If vertical categories was implemented when BYOB was being turned into Snap!, it would have long been normal by now; but it was not, so the sudden change would be weird and possibly never fit.
The only reason it looks mostly normal in Split is because the project is meant to look like the Scratch UI, but I seriously doubt it would look normal if I took those same changes and put them into normal Snap!. (Actually, I think I’ll try that)
I really see 0 justification. functionally, it’s better for me. by a lot.
“of”, and “text” depending on which library. with scisnap, and custom blocks, I kinda feel like no matter how you do it there just isn’t much space in the palette when searching for some things.
I think worst of all is in old projects, before we had SPACE ABOVE?, it looks horribly cluttered and finding anything normally, so then we would have to use the search bar, and remembering the block name of whatever you want is hard. giving the extra space as an option also helps in cases when custom blocks make categories larger and when custom blocks make searching a pain.