Try now.
Those among others. Things like double-click to select a word, too.
When I presented it at the Snap!Con 2021 lightening-short talk, there was not enough time for explaining how it works under the hood.
When making my editor, I was afraid clones would slow it down too much, so I avoided representing letters with clones.
I don't want to impose my way of making the editor, though. So let me wait & see what OP will come up with using his approach.
I would like to point out that my editor did everything (well, except italics, for obvious reasons; no problems if you use a non-monospace font, either) with no help of libraries, whatsoever. (Not even Strings library.)
P. S.
Apropos my no libraries used inside 'battle cry':
If additional three letters, not even existing in English alphabet (but in my native-language one they do exist) were not supported by my editor, I could leave out the associate block (the only exception to the rule), used to convert those three letters from lower case to upper case.
You would need JS but, when ctrl+v is pressed, get the item from the clipboard and add it to the text.
uh use:
window.navigator.clipboard.writeText("[insert text here]")
and pasting:
var toReturn = "";
window.navigator.clipboard.readText().then(text => {
toReturn = text;
})
return toReturn;
// cannot return from the inner function
just, a thought, but what if you just record the sprite's current location, write the letter, than record the distance traveled, then repeat. That way you can then use that data to figure out where each letter is. Might not be the best for speed, unless you don't render all the text all the time.
This method returns a Promise, not a string...
That would work, even in a non-monospace font. But it does have the problem that if you insert or delete text, you have to recompute the positions of all the letters after it on the same line.
That has been the reason I decided to abandon the 'computational' approach (in the project you have seen at Snap!Con2021). I instead have taken the multi-sprite sensing (i.e. touching) approach.
I think you kids rely way too much on using JS, when things can be done without it, using pure Snap! only.
That was before i realized it was bad. If you check the posts.
Vanilla Snap! and its library blocks don't present any way to copy to and read from the clipboard without JS.
or i could just subtract the width of the letter I deleted from every other letter on the same line, and an easy way to do that would be through hyperblocks.
True! I forgot about that. :~)
You are right, I misunderstood because I was convinced that all you wanted was a decent - but not perfect (perfect is the enemy of the good, they say) - text editor to be able to do is copy-pasting words from one line (or part of the text you are editing) to another line within the text, which is text-editing function; not from external text sources (which is operating system's function), in which case yes you would need JS.
In a text editor you don't want to delete single letters only, but you want to be able to delete a whole word at once, too. In this case you want the editor to be able to bring a word from the next line up in the line that became shorter because of the deletion.
If in such a scenario you rely on the
then you will have to do a lot of calculations, when facing a cascade of other words needing to be moved one line upwards from all the subsequent lines.
Yes, good point.
To complicate things further, you have to remember the distinction between a wrapped line, which can become "unwrapped" as you say, and an explicit newline, which can't.
Bottom line: Editors are complicated. No detail is especially hard, but there are a lot of details.
Yes, a lot of scripts were needed for the main sprite (as you can see in the meta-project about the project that was presented at Snap!Con this summer).
As you said, to keep track of a hard_newline vs a soft_newline, two hidden tags need to be inserted, but not printed/written, in the text.
P. S.
Yeah, mathematicians would probably say it's a "bunch of trivial scripts", a task not worthy of them. ;~) Fortunately most programmers are not scientists/math people and are willing to dive in murky waters.