I haven’t really worked on the editor’s key bindings much (apart from making up/down work!). Home/End’s current behavior is coming from the default TextField class, which I cloned to make my editor class. It’s a bit aggravating to think about, since VCV captures a lot of the keys (e.g., PgUp/PgDn move the whole patch); not that I think that’s bad, but a text-editor within VCV is a little hamstrung.
In fact, I didn’t know that Home/End did anything in the editor until you wrote this :). But perhaps I’ll return to the editor at some point, although, phew, it’s not much fun to work on. Text editors are harder than they look!
The length of an array is never set. One surprising principle of this language is that there cannot be runtime errors; there’s no way to report them, and “stopping” just because of some programming error is not what a user in a music-making system wants. So all things that are normally breaking errors (dividing by zero, accessing at some index never set) just have defined behavior and carry on.
The one exception, of course, is that programs can stall (e.g., while extending the vector long enough to accommodate index 10,000,000, if you set it). I just encountered the thread on priority inversion, and, yeah, I’ve got some stuff to work on there (primarily around compiling on the main thread).
So if you want your code to work better and you expect to maybe write to foo[10000000], I’d currently suggest that the first thing your code does is set the largest index in the array you expect (e.g., foo[10000000] = 0.1); it might stall then, but at least it won’t be stalling later. The next release will make “initialization” code like that MUCH easier to write.
mahlen