Soon? Your message start out saying (paraphrase) “I personally (me) have limited time for IF ideas” and then ends with “won’t happen soon”. The issue is that it already happened! Jon Ingold demonstrated and prototype coded these features in the Inform 7 natural language, dedicated window of hyperlink (Dead Cities 2007), hinted input (“The Wilds Of Orkney.gblorb” mentioned in this posting), way back in 2007, 2011. Open source code was there, working examples. What these were really showing was ideas on changes to Glk to understand Interactive Fiction - but implemented using the only means possible at the time (keyboard polling with the single timer, creating a Glk window of hints [story specific vocabulary] to replace and/or supplement the readline() prompt at the bottom of the window in both cases).
Favoring Inform 7 for a moment, the vocabulary of words has always been somewhat predictable. “go west”, “smell flower”. If localization is brought into the picture - the numeric indexed Hyperlink system would be ideal to localization because translators could cross-reference the numbers to translations (even to fit screen sizes, which Android fully supports for a decade now). But there is entrenched purist attitude toward favoring the full size keyboard via keystrokes - and Glk is right in the center of that in that it is extremely obsessed with keystrokes and single characters… not meaningful words that is the bread and butter of novels, fiction! Why not the same kind of approach for hinted input? The Chinese or Hindi phrase for “go west” could be indexed to a local operating system keyboard and translated via the established means of the operating system. Same goes for menus (choice fiction) - why not define a Glk idea of a menu (indexed list of quotes, numeric code of which one was picked) - instead of doing keystroke-driven menus like I’ve seen in hundreds of Inform 7 games. The modern operating system has to be aware of localization all the way out to the extreme edge, as the marketing material (screen shots) all have to be in the language of the end user - and it extends all the way out to the search engine at Amazon / iTunes / Google Play / Ubuntu Software bring the user into the app.
Jon Ingold was showing all this off and the fiction writer author-syntax - what was missing was Glk API’s for making it something that any Interactive Fiction system that comes along could abstract (not just Inform 7)! Instead, I see thousands of apps being developed and used without Glk because it still thinks in terms of lines and keystrokes - and that’s not how novels and stories are built. I’m not the one who has made keyboards disappear for many youth and transition to interactive swipe touch screens! That’s happened around all of us. I’m only observing what’s going on and how the most popular open platform for computing, Android mobile, has presented failure after failure for years on being implemented! The same goes for speech recognition - if you know the vocabulary and can hint to the operating system what words you are listening for - the results dramatically improve. All this would have been there if Glk had exposed an API for hinting words / vocabulary as Jon was showing in 2007 to 2011 - and stories compiled 10 years ago would have had the immediate benefit of having the dictionary handy before it even gets into the interpreter engine! And hard-core traditional players can tell their app to discard the hints that Glk provides to make it more difficult.
I feel like there is a very heavy attitude of “not invented here” in the technical side of the community (both Glk and app developers who hold the signed keys for publishing updates). That open API’s for hinted keyboards that exist in the most popular computing devices in history are still being questioned instead of understood just how tied they are to the concepts of prose-language Interactive Fiction novels and stories! It’s a dreamy world on mobile to know the vocabulary of the words as the user types them! Huge labor has been spent on this in computer science over the past decade! And here you have a natural-language system parser concept that’s been around since the middle 1970’s that’s built on a specific limited vocabulary and even a rather predictable grammar ordering.
Compass directions in games WERE practically invented by Interactive Fiction. “Go west, Go East, Go Southwest” is in thousands of stories over half a century! Yet, Glk doesn’t seem to think that an API needs to exist to numerically index these phrases for a 12 year old human child on an iPad in Tokyo who would want to swipe or tilt in compass directions! Why can’t Glk have an API to send a list of valid exits for a room so that a UI can color which directions are valid and invalid? Inform 7 knows these concepts at the authoring level, but Glk strips them down to meaningless ASCII encodings that have to have Regex applied on the other end! Glk seems like an API that doesn’t understand fiction and room movements at all! What about having an API to send inventory to a client to present it’s own way, inventory seems a pretty standard Interactive Fiction concept in multiple interpreters (and one Jon Ingold took time to share code with in 2007). And the code for selecting inventory could be similar to an indexed navigation menu, and localized (on a small device, it could be “swipe screens / change screen to view inventory”, on a larger device - a window onscreen - or even a second display monitor. Integer indexes and string lists are sent via Glk and the app sends back into Glk which ones were interacted with. Inform 7 extensions could prototype these Glk API calls as they are worked out. Even CheapGlk could do inventory window by just putting it into the single window TextBuffer stream when the player puts in a special command.
Jon Ingold was doing amazing work back in 2007, 2011 showing off the need to standardize these concepts in Glk. He was putting hints right next to the readline() prompt. Anticipating and visionary work of what was coming down the pipe. But it seems pretty frustrating that it’s not been seen as a general-purpose multiple-interpreter Glk need and instead of a need to fix now-broken Inform 7 extensions. And what I’ve seen is that mobile apps are being built that have entirely avoided established interpreters and Glk with it’s heavy focus on readline() and getchar() conventions. What Interactive Fiction input API should have at heart is a readHumanWord() type concept (callback when space or backspace is pressed) that the authors can set as directives in their authoring (a novice player could be shown hints of the noun structure next, and a limited device (such as speech or a smartwatch) drop the articulation but internalize those hints). Of course legacy char and readline() can still be in the API, never to be depreciated.
Someone went so far as to make an entire app, open source it, 2.5 years ago that highlights this problem. Both speech output and speech recognition. That person brought it to this community - and it was promptly ignored for what it is - a request that Glk have word hinting so that speech recognition vocabulary could be tied into the operating system. How does “press space to continue” work in Glk - with a speech interface? youtube.com/watch?v=D6i7c7j … e=youtu.be – “Press space to continue” may seem natural to take all the way from the Interpreter in only one human language to someone doing C code for decades, but that doesn’t make any kind of sense in a speech interface - and the world of prose language fiction novels can have a standard API for such interaction. But “press space to continue” and menus both are the realm of Glk - and localization presented these issues long before speech recognition. By having an indexed API call to present “press space to continue” - you can translate it to Korean at the other end of the API - and fit the needs of the player’s human environment. That’s not just shuffle of printf() and readline(). And, being in Glk as a concept, new interpreters could be built that never use those legacy concepts of char and line.
Just this past year university students in Germany were instructed by their professor to demonstrate augmented readline concept - they added the obvious words to an Android app (really a readHumanWord() idea like Jon demonstrated with timers). Something that really could have been in Glk shortly after Jon published his several blogs on the topic back in 2011. ref: https://intfiction.org/t/if-archive-hugo-downloads/59/1
Right now I would have to dig deep into the Glulx interpreter and teach it to build me a list of words out of the compiled Inform 7 story, or build a static tool to extract the words - because Glk API has ignored Jon Ingold’s work that’s at the very heart of natural human language concerns of Interactive fiction. If, instead, the API would treat menus as indexed lists - and hinting words and verbs and nouns (specific to the story) it would be serving the player instead of C 32-bit unsigned byte structures.
The message I have gotten around here is that there is always, and I mean always, a chicken and egg issue of “no interpreter (app) supports it” regarding the critical bridge of Glk. But Jon Ingold was implementing away Glk ideas in the two examples I gave of hinted input replacements for readline(). What I see is that Glk ignored this and didn’t see that natural human languages were at the very heart of Interactive Fiction, not keystrokes! Keystrokes were just the primitive tools of the 1978 VT100 terminal. All along the fiction itself was built around dictionary! Why should Glk throw it’s hands up and say the human word “Xyzzy” is Greek To Me, just chars? It could be South Korean, Japanese, or Greek, known before it event gets past Glk and into the interpreter!
I’m very frustrated how little understanding Glk has of human languages and how little concern this seems to be to anyone. A menu is what you see at a restaurant, and you use to pick what you want to order - often Chinese restaurants in Europe or Americas even allow you to order by numeric index to cross the hybrid language and culinary barrier! Why can’t Glk see this common problem to Interactive Fiction? I have poured my shitty human language on this page to express that, and I’m pretty sure it will mostly serve to irritate and offend - and not be heard! As Jon Ingold’s far better human expressions wasn’t heard as a Glk API request specific to the unique realm of Interactive Fiction, and that’s clearly what it seems to be to me in his own way, and Glk is right there ignoring what he did in 2007 & 2011… and I’m being told today that it’s a radical idea - when I see hinted keyboards in use on the public bus every day by people who have no idea just how much Inform 7 is built on the concept of human languages and their verb noun structures!
P.S. I started out saying that I wish there was a forum here for more open dialog and organization on technical ideas instead of just tools - because it strikes me that people like Jon Ingold knew to stay away and on blogs (that mostly got ignored here) - because things seem very “not invented here” with a kind of inbreeding attitude toward new ideas. The sore thumb of Android and Glulx - and the ho-hum ignoring of Incant’s speech code on Github collecting dust now for 2.5 years - I think is also similarly an example of “staying away from complex conversation” because people here are concerned about politics of who is in power (including social power and beyond, as in Michel Foucault’s ideas) instead of actually what seems to fit with the common needs of Interactive Fiction input and I/O- which the topic of “word hinting” to speech and keyboard via a standard Glk API seems blindingly obvious! DavidC wanted the “name of room” exposed in his API and has code to show that. This seems a lot like Jon Ingold’s experience here with the local ‘regimes of truth’ on what is Glk. The idea of knowing the Room Name as an object seems to fit well with an API that knows something about novels and fiction prose! Glk doesn’t seem to care at all about names of rooms as human Objects, instead it has a generic idea of a “status window with grids of characters”. DavidC is one of the few who I see stays here with progressive ideas on input/output that fits with natural language - but I also note he has abandoned Glk entirely with it’s keystroke + readline focus ideas of input/output. I personally would have given up a month or two ago if RemGlk hasn’t given me a “atomic transaction / frame update” input/output concept beyond the primitive character concept of Glk. Compared to DavidC, Jon was more directly addressing in 2007 & 2011 that Glk needed to move forward and produced open source code while he explained the benefits to a fiction storyteller author.