If it’s based on character count, I’d say GET is 25% better than TAKE.
GET is 75% of TAKE, but TAKE is 33% longer than GET.
Math is completely subjective. ![]()
+1 to tab completion should be on the feature check list for any parser engine being built from scratch in 2025.
As it happens, I’m working on a modern Javascript parser, and my first thought on reading this was that it seems pretty doable. My first concern was for accidentally revealing unearned information, but as you say, suggestions can be restricted according to what’s known by the player. But the larger concern I immediately ran into is that tab-to-complete breaks the standard wai-aria accessibility pattern for keyboard navigation. There are ways around that, but they would require the accessibility user to accept non-standard behavior. To be fair, it seems like this feature would have to be a user preference. Or more likely a stacked preference: functionality built into the parser, an author’s preference to allow its use in their game, and then the user preference.
I really don’t understand this TAKE vs GET discussion.
Just TAKE IT, GET IT?
But the larger concern I immediately ran into is that tab-to-complete breaks the standard wai-aria accessibility pattern for keyboard navigation.
Yeah, and GUI toolkits also offer navigation via the TAB key.
Perhaps another special key could be used instead? The INS (insert) key maybe, I haven’t seen it used for much except as a toggle between insert and overwrite modes.
But the larger concern I immediately ran into is that tab-to-complete breaks the standard wai-aria accessibility pattern for keyboard navigation.
Maybe some context-sensitivity would help, for instance moving fields if the command line is empty, and completing otherwise. Although in a lot of interpreters the command line is the only field, so what are you going to tab to anyway? Maybe links, if the game uses them, but that would be shift-tab from the command line anyway. At least IF doesn’t need to worry about tab’s third standard meaning, indenting.
Although in a lot of interpreters the command line is the only field, so what are you going to tab to anyway? Maybe links, if the game uses them
The thing I’m working on runs in a web browser (and plays nicely enough to coexist on a page with unrelated code). In that context, the tab key blurs the currently selected field and focuses on the next focusable element - and if there are none on the page, focus moves to the browser UI (browser tabs, the address bar, bookmarks bar, etc). I guess if you were designing for a standalone app with a singular input field and no other UI, it would be less of an issue? I’m less familiar with that accessibility pattern. A quick search suggests that Alt or Ctrl+F2 are used to reach OS menus. So, yeah, maybe?
I play parsers via CLI interpreters on the Linux Console and have an aversion to webapps, so the conflict between tab to complete in the CLI and tab to cycle focus on a webpage didn’t even occur to me.
Also, since accessibility was mentioned I think its worth mentioning that several screen readers use insert as their default command key so screen reader keyboard shortcuts are less likely to conflict with OS and app-specific keyboard shortcuts. At least for their default desktop keyboard layout(caps lock is a common alternative for laptop layout and I think some laptops and reduced form factor external keyboards discard the insert key since it is of so little use to most users(I’m not sure the keyboard I’m typing this on has an insert key)) I know this is true for Orca(Linux’s graphical screen reader), am about 99.99% sure its true for JAWS and NVDA for Windows, and it might extend to Window Narrator, some of Linux’s many console screen readers, and and Voiceover for OSX(assuming MAC keyboards have an insert key, I know Apple violates the PC keyboard standards, but I’m not sure of all the differences).
Just TAKE IT, GET IT?
“Won’t eat no Captain Crunch, won’t eat no Raisin Bran…”
if there are none on the page, focus moves to the browser UI (browser tabs, the address bar, bookmarks bar, etc).
I was thinking it doesn’t seem to be possible to tab reliably into the browser UI, or at least I’ve had much frustration trying to tab around in browsers, so anyone wanting to get to the UI would be in the habit of using some other shorcut (F6, maybe?) to get there.
For accessing browser UI, I mostly just ctrl+l to the address bar or alt+letters to the menus. Don’t really care about tabbable UI elements other than the address bar and you have to be at the top/bottom of the active page to tab into the browser interface, so it’s easier just to jump to the address bar than to tab into the interface.