By space dots i mean the dots that appear when you put a space in an input field. They look kinda ugly (and maybe even unnecessary in cases where you normally wouldn't put only spaces in like say blocks), so I think there should be an option to disable them.
They do look ugly but are needed due to the way Snap! uses an empty slot.
If they were invisible, then programmers wouldn't be able to tell the difference between a single space and an empty slot, just by looking at the code.
Think of them as one of the (small) downsides of being able to program in powerful Snap!
what if a brown/purple dot represented an empty slot, and spaces were invisible?
how would you tell how many spaces there were?
by counting the empty spaces between words
they are EMPTY, how can you count them
I think that's an example of two wrongs trying to make a right 
In the same way that you do in any text editor
The brown dots aren't there to make it simple to count spaces - that's just a side benefit
so? they should still be there, that was also one of the reasons when I came to snap!. I support this topic since it is an OPTION, but you are trying to tisable it altogether.
I'm simply suggesting that its a fundamental Snap! feature that distinguishes it from every other programming language.
[edit = to clarify - it's a non-issue in other languages as an empty function is identified normally by () or [] and we can tell the difference between them and ( ) and [ ]. We can't in Snap (without narrowing the slots and then that probably wouldn't look nice ]
And given past statements on not having flags/settings, if at all possible, I don't think this request would be accepted
For a workaround, there is probably a keyboard sequence to insert an alternative Unicode space (such as one represented by decimal 160)
I don't know what that would be and would probably vary from OS to OS
I use Unicode 160 myself in my dropdown menu project so that they look nice
If we were to consider anything like this, it'd have to use some other notation; it'd confuse users enormously to flip the meaning of the same notation!
In the past I've tried to convince Jens that we should mark specifically those empty slots into which something will be substituted, like this:
(never mind the unintended tail on one of the borders...) but without success. The little dots in the empty rings tell you "I'm expecting a function with this many empty slots."
One objection to this plan is that it'd be doable in the CALL block, but quite hard to work out for user-defined higher order functions. It'd be really complicated for Snap! to read the code of every custom block that has a ringed input looking for where that function is actually called. (And what if it's called twice with different numbers of inputs?) But I'd be quite happy to require the authors of custom HOFs to include the number of inputs expected in the declaration of the ringed input if they want this indicator.
But I'd still want to keep the brown dots. :~)
Huh maybe I should do that too, in the color library.
It's really tempting to support options for every controversial topic, but over time there have been quite a number of controversial ideas for which options have been suggested (sometimes by me...). Here's a partial list:
- measure angles counterclockwise from east
- measure angles in radians
- disable retina display support as a per-user persistent setting
- support circular lists
- lazy evaluation
- hybrid scope
- dark skin
- zero-origin indexing
- strict type checking
Not to mention all the options we have already. Jens hates options because checking them slows Snap! down. I don't hate them exactly, but when you have a lot of options it becomes hard for users to anticipate what a program will do.
So, it's generally much better for us to try to do a good job of designing the language than to try to avoid design decisions with options.
If you shift-click the options menu you'll see a zillion extra options. These aren't things we're keeping secret; they're things we put in for our own use during the design process, to help us decide whether something is a good idea or not. But in a perfect world we wouldn't have options at all, but would just always do the right thing. :~)
After going down a few google bad routes, I've found how to do it in Windows
To get Unicode 160 (the HTML non breaking space char &NBSP) just hold down the Alt key and then type 0160 on the numeric keypad and then let go of the Alt key - doesn't work if you don't have a numeric keypad 
as you can see - the brown dot goes and you can see 160 in the list instead of the normal 32
And Snap! will even treat it as a valid word delimiter
yes
.......
here it is
between these words
The hexadecimal for a no-break space is A0 for the Chromebook users (like me) out there.
You didn't actually delete it.