onKeyPressed doesn't listen for modified (e.g. ctrl-u, alt-a, etc.) characters

[stephentalley]

Our app has a need to listen to various control-modified keys (ctrl-u, ctrl-f, ctrl-b, etc.). But:

session {
    var keyPressed by liveVarOf<Key?>(null)
    section {
        if (keyPressed != null) {
            textLine("key pressed: $keyPressed")
        }
    }.runUntilKeyPressed(Keys.Q, Keys.ESC) {
        onKeyPressed {
            keyPressed = key
        }
    }
}

…shows those keys are ignored.

Is there an API to listen for those keys?

• OS: Linux
• Version 1.1.1

[bitspittle]

I don't have access to anything except that which the terminal gives me. So depending on what you're expecting, it's probably not possible. See also: #57 in case it's related.

I wonder if you could write a raw console app, just like a naked main function and use of readLine, and see if you're getting characters in that case.

[bitspittle]

A user on my Discord just pointed out that Mordant has rich support for raw keypresses. Taking notes here.

• At a high level, you have the enterRawMode interface method

• Here's the default JVM implementation, which throws an unsupported error.

Mordant actually supports three implementations that apparently supply raw mode logic.

• Java Foreign Functions and Memory APIs. Requires JDK22+
• JNA. Flexible solution but a bundled native library increases the JAR size
  • See also: https://github.com/java-native-access/jna
• GraalVM FFI (but doesn't support regular JRE runtimes)

Between these three, I think JNA is the way to go. However, I'll need to investigate to see by how much the native library increases the jar size. If it's like a few MBs or less, it may be worth it just to do it. Putting the logic in a separate module doesn't seem too bad.

JNA implementation for windows

Still not sure how mac and linux work. Will investigate later.

---

If I can get this working right, I think for a first pass, I would mostly keep onKeyPressed the same, except I would add
ctrl, alt, and shift booleans. I might also see if I can generate key presses for just CTRL, ALT, and SHIFT on their own.

---

TODO:

• Figure out bundle size of native library / libraries for JNA solution
• Figure out how linux works
• Figure out how mac works
• Update Kotter

[KyleMcB]

I am using kotter to make a shell and also needed alt+n ctrl+n
I wrote my own system to collect and interpret from Terminal.read() from kotter
I'll share it here, but its super early. I wouldn't be surprised if it only works on iTerm2. probably won't work with xterm. also you have to use a runUntilSignal and collect the in the runscope.
https://github.com/KyleMcB/kross/blob/develop/kross/src/main/kotlin/com/xingpeds/kross/utf8Input.kt
my code isn't documented or tested yet sorry. Also it doesn't detect alt+ctrl+n you probably could. I hit a complexity limit before I document and refactor. See the app entry point at
https://github.com/KyleMcB/kross/blob/develop/kross/src/main/kotlin/com/xingpeds/kross/App.kt
note how I signal() and cancel the collectionScope when someone pressing enter.

[bitspittle]

I know it's been almost a year since the last comment, but apologies as I've been busier on Kobweb than expected. Still, I had a few days finally so I thought I'd look more deeply into input handling on Kotter.

It looks like I misunderstood what Mordant was doing. I had thought it was employing special code written for the purposes of surfacing accurate keypresses, but in fact it seems like it is just doing for itself what I've been relying on jline to do for me.

So I don't think I'll be able to surface something like "user pressed U while holding modifier keys shift+ctrl"; I just don't see any way to know it.

However, I'll look into filling in a few more gaps. For example, ctrl-u generates control key 0x15, which at the moment I drop onto the floor, whereas instead I should at least pass it along so a user could handle it if they wanted to, maybe like:

when (key) {
   IsoControlKey(0x15) -> { ... ctrl-u handling here ... }
}

Alt-a would be similarly handled, but using CharKey:

when (key) {
   CharKey('å') -> { ... alt-a handling here ... }
} 

This kind of sucks but it really seems like, the more I look, the more that the terminal world is very opaque. For example, you'll never know if 0x08 comes from the user pressing "ctrl H" or "ctrl h" or "backspace".