I'd like to be able to create custom blocks that don't have a visible label at the start of them
like these
I don't think its currently possible
Could it be done?
maybe use $myblockname like the image prefixes but just display nothing?
If I understand correctly, it is possible. You just need to create a custom block which has the text you want to have in the middle and use the plus button for adding inputs.
your right of course - I used some wrong examples to illustrate my request 
I'm wanting this feature so I can produce reporters likes this
but without the image prefix (and the ability to have similar looking blocks that are functionally different hence the need for invisible label)
I see. Yes, that is currently impossible, to my knowledge.
It's not impossible! First you do this:
Then you click the words "some" and "thing" to turn them into inputs!
Works excellent for 1st of them
but I can't then make another one without it adding a suffix
so I still think I need to have invisible labels
Could you show how to use that?
Go to the Wikipedia article, copy the character (between the brackets) and paste it somewhere in the blocks title
Got there
To anyone trying this - I ended up copying from last letter of Lorum to first letter of Ipsum - pasting then deleting the m - moving to end and backspacing the I
Its best work-around so far
But not very editing friendly as I've not managed to edit (or even delete) a text field with one in
hmm... What am I misunderstanding?
Sorry - My first post was wrong - see 2nd one for clarification
I'm after two reporter blocks that look the same but are functionality different.
I want to create them to return possible values using pulldown options
e.g one provides a list of possible common LED colours (red,green,blue,white,orange) and another one that provides a list of Pi pin numbers (pin3, pin5,pin7 etc)
Then I just want a programmer to drop whichever custom reporter they need to use inside another blocks slot.
But I don't want (need is too strong a word) to "clutter" up the reporter with a prefix or suffix - hence the FR to have invisible labels
e.g left one is great - its obvious that its a colour on/off reporter - doesn't need a suffix/prefix
The pin one one the right is also obvious and doesn't need a visible label but has to have one otherwise Snap! can't tell the difference
Thanks
I'm finding its very weird (after 45 years of programming) to be copying and pasting an invisible character
Luckily the cursor knows about it and lets me move back and forth across it as if it was visible otherwise I'd be completely lost
Ah, I see, thanks. It's funny, Snap doesn't technically need unique block labels for global custom blocks, this is a user-interface requirement only
So that's good news - no need for invisible labels then
And, for most cases, that is obviously a very good idea - two blocks with no labels would cause an awful amount of problems
but.....
by using different pulldown menus - the UI confusion is negated 
So, what can you offer me to square this circle?
I really don't want to go down @fridolinux zero-width space route if I can avoid it as once I've added one in - its impossible AFAICT, to edit/delete one once created. (Which makes it difficult to play-around with it)
One possible idea: If $zeroWidthSpace was available as a symbol - then at least editing a block header with them in would become possible, as I could stick 2, 3 or 4 of them in-between the two input fields without the visuals looking too bad
Oh, my advice is easy: Just give your blocks expressive labels!
Look - I've not asked for anything in AGES
Throw me a crumb
Well, seriously, then, another idea would be to collapse it all into a single block with nested submenus.
Oh, my advice is easy
My serious reply to this is that I'm basically trying to provide a custom 2 parameter join block where the inputs are menu dropdowns
So, in true Scratch/Snap! philosophy, I should just prefix them with the label join
Which is fine for the 1st block - but we are back to the same problem for the 2nd block - I can't re-use join (wihout adding a zero-width space to the label)
And I can't use same concept with single field blocks of this type as I wouldn't have a join prefix (well I could but I think we'd both agree it looks silly)
