Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: OSC sequence to change soft keyboard mode #3733

Open
scy opened this issue Dec 14, 2023 · 1 comment
Open

[Feature]: OSC sequence to change soft keyboard mode #3733

scy opened this issue Dec 14, 2023 · 1 comment

Comments

@scy
Copy link

scy commented Dec 14, 2023

Feature description

Currently, switching the touch keyboard to text input mode and back has to be done by the user manually by swiping.

What if a client application running in the terminal could request the keyboard mode to be set to either the "normal" (direct) method, or the "text" method with autocorrect etc.? For example, a user could configure NeoVim so that entering the editor's "insert mode" to automatically emit an escape sequence to Termux, to request that it switches to text input mode. The user can then enter text, and finally hit Escape to exit NeoVim's insert mode. NeoVim could then send a different escape sequence to tell Termux "alright, you can switch back to the normal, non-predictive keyboard now".

Additional information

I would assume that this would have to be an "Operating System Command" (OSC) sequence. I've looked around whether other terminals have such a feature and found none. There's this Google Sheet attempting to track all known sequences, and I could see nothing like that in there either.

The sequence should probably not only allow for "direct" and "predictive" input, but also other popular soft keyboard modes like "numbers" or "web address", too. Android defines quite a few of these types, and so does HTML5.

As we're defining a new OSC sequence that other terminals might choose to implement, we should keep it independent of the Android or HTML types and define them in a modular way.

For example, suppose we'd give this an OSC number of 112 (representing the position in the alphabet for KB (keyboard), 11 and 2). Then, a sequence could look like \x1b]112;text\x1b\\ to switch to "text" mode (enabling autocorrect etc.) and \x1b]112;normal\x1b\\ to switch to whatever the terminal assumes to be best for general-purpose CLI work, i.e. Termux would probably choose its default, "immediate" keyboard without any autocorrect.

We could start small and only support text and normal, and in the future allow additional modes like

  • email (optimized for email addresses, e.g. by providing dedicated @ and .com buttons)
  • number (shows a number keypad)
  • password (optimized for passwords, with a number and/or special characters row, as well as without any autocorrect or predictive text)
  • tel (shows a number keypad with additional buttons relevant for phone numbers, like +, -, (, ) etc.)
  • url (optimized for URLs, e.g. with https://, / and .com butons)

Keep in mind that actually implementing these keyboards is out of scope for Termux itself, as Android already provides an API to signal to the user's keyboard that one of these modes should be activated. Termux would only need to map these string values to the corresponding Android constant(s).

@Grimler91
Copy link
Member

Interesting idea! hterm has a slightly longer list of OSC's they support here: https://github.com/chromium/hterm/blob/main/doc/ControlSequences.md#operating-system-command-osc-osc

I guess 112 would conflict with Reset text cursor color, so probably we want to choose something else. Should also check additional terminals (xterm etc) if they support additional OSC's

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants