Auto-completion of handlers (on/end __) - where to intercept keyboard, or hook into autocomplete/syntax checker?

[Jimw338]

I want to add functionality that will autocomplete on and end lines in handlers - if the user types "on mouseup", have it insert"\n\t\nendmouseup" and place the cursor after the tab character on the second line. I figure I can add the stuff using "ScriptEditor:: appendNamedBlock()" (line 466)

But how should I detect when the user has typed the proper string [ 'on' ('mouseup'|'mousedown'|...) ]?

One idea would be to intercept the return character by adding to the HyperTalkTextEditor custom key listener (line 67: in "scriptField.addKeyListener(new KeyListenable()..")

But would there be a better seem to hook that into the the return key. I'd think might be would be InsertBreakAction() (RTextEditorKit.java:1465)

Or hook into the online parser and syntax checker, or the autocompletion kit.

Suggestions?

[defano]

No good suggestions, sadly. I wanted to implement this feature myself but couldn't come to an elegant way to do it--not that I spent too much time looking into it.

Seems like the "right" way to do this is to hook into the ability of the syntax-aware text field https://github.com/bobbylight/RSyntaxTextArea. As I recall, this feature exists, but was designed for languages whose blocks were denoted by a single token (i.e., { ... } or begin ... end, not on mouseUp ... end mouseUp).

I'd start by looking there. Let me know what you find. Would be nice to have... that, and HyperCard's native auto-indent capability.

[Jimw338]

Yeah, the auto-indent was one of the first things I noticed. I just fired up Sheepshaver and noticed that HC (2.4.1) doesn't actually have handler auto-complete after all. Buttons have a default "on/end mouseup" handler, but if I type "on mousedown", it doesn't autocomplete.

I suppose the "performance burden" incurred by putting it in a general key listener wouldn't be that big - an FSM that looks for "\n-o-n" in that order, and if it doesn't find doesn't find it it just lets everything fall through until the next return character. So most keypresses would have only 1 comparison (to "\n")

Generally, how much should I be concerned about "efficiency"? In that I perhaps have the misfortune of starting my programming self-education when a 16 Mhz, 4 MB SE/30 was considered "really good", and 20 MB was considered "more space than you'd ever need". And when object-oriented programming (which has objects all over the place, doing all sorts of things in the background) didn't really exist (I never learned about MacApp or whatever the MPW OO-like framework was).

So I'm always rather paranoid about "making things more efficient" - which arguably isn't really important these days. And ironically, my first programming experience was HC, which as an interpreted language is probably slower than anything compiled.

I modified VisualEffectSpeed.java to see how how fast the visual effects could go, and got the checkerboard running "up to" (down to actually) about 150 ms, before I couldn't really see it anymore, and increased the the checkerboard size up to 100x100 (!) before it seemed to "slow down".

I noticed that the the visual effects seem rather squirrely - it looks like the destination image is the destination card with the buttons and fields rendered, but not the bitmap layer. I have a test stack that has a bunch of buttons and fields on two cards, and then each painted (fully) with a different pattern. If I go back and forth with a visual effect, the background picture doesn't appear until it's finished.

I figure after converting it to ObjC - whenever I get around to that, and then rebuilding the interface in Swift (maybe from HyperCardPreview project, or a "Swift Swing" framework that might be out there - depending on how much Google as ported in J2ObjC), it might get faster depending on much the the JVM can optimize things. It would be nice to figure some way to maintain as much of the Swing layer as possible, with some kind of translation for the Swift, so that behaviors could be shared between the Java and Swift targets. Java for Android and non-Mac desktop, and maybe Mac desktop as well, Swift for iOS.

I'll take a wild guess that Apple would not look kindly upon running a JVM for an iOS port of something. (They probably don't like J2ObjC either, but can't really do anything about it.) If it's even possible to do an iOS-JVM and stay inside sandboxing (and other) restrictions. Did Apple's more-hate-than-love relationship with Java start with Steve Jobs? Although Java used to be supported - or "semi-supported" - by xCode up until 2007 (is it gone yet?).

Did they at some point seriously considered making Java the "official" programming language of the Mac, or just because WebObjects was written on top of it, and they wanted to support WO with xCode? (But why? WO was always an enterprise tool of no particular interest to end users, right?)

[defano]

As Donald Knuth is famous for writing, "premature optimization is the root of all evil." I wouldn't imagine adding a few lines of code to a key listener would have any perceptible impact on performance. Plus, almost nothing in this codebase was written with performance in mind. :)

The visual effects have been squirrly indeed! I've run into all kinds of problems with them, mostly related to threading and the complicated and opaque gymnastics that Java performs under the hood to optimize screen painting. Nevertheless, I think I have that bug fixed in a recent commit on the feature/hc-import branch. But I'm sure this won't be the last...

Have you looked at https://github.com/uliwitness/Stacksmith? It's a more serious attempt at a HyperCard clone written in C++/ObjC.