Make Arrow Up and Arrow Down work like <ctrl-p> and <ctrl-n>

[SirVer]

I looked into that really quickly, but it seems a bit more involved. It would be very useful though since on some keyboard (kinesis advantage) and keymaps (Neo2) the cursor keys are much easier to reach than the ctrl-* cords.

[rschmitt]

I use a Kinesis at work and an ErgoDox at home, so I know what you mean. This is tricky to support, since it requires CSIs to be parsed. There are also two different sets of control sequences for arrow keys, depending upon which mode your terminal is in. I guess I can give it a shot, but it's probably going to be buggy.

Note that the tab key is equivalent to ctrl-n in Heatseeker.

[SirVer]

I know that is a bit bitchy to implement. I tried for 20 minutes and could not find an ideal solution. I think you should probably think about reusing some terminal abstraction library to not needing to deal with this issue. ctrl-n is fine, but I am not used to that - I use Up and down everywhere else because it lays on the homerow in my keyboard layout.

[rschmitt]

I've never attempted this before, even though people always ask for it to be added to Selecta. How far did you get in 20 minutes?

[SirVer]

Well, the beginning was easy: there is a function that asks if more keystrokes are needed and you can easily modify it to wait for one more after an escape has been seen. But then the code breaks each string into a list of unicode code points - and that is not working for arrow keys. I dug around that area a bit but decided that the redesign would require me to understand more of the internals of heatseeker that I had time for to learn right now. I then gave up.

[SirVer]

Forgot to mention: I would be interested on pairing on this. First to understand how you designed and how that soltution might look and also because I am interested in trying out floobits.com. Would you be up for that?

[rschmitt]

What, like over Skype? The time zones might be tricky, but other than that I'd be open to it. The relevant functions are get_buffered_keys and possibly translate_bytes.

The more_bytes_needed function you're referring to was created mainly out of paranoia: I'm not aware of any atomicity guarantees made by terminal devices, and I wasn't sure whether I'd have to do blocking reads on the input channel in order to see all the bytes of a multi-byte code point. I have the same concerns about parsing control sequences. I'd like to read the code of JLine or ncurses to see how they handle this.

By the way, there's another use case for this sort of parsing, which is to obtain a cursor position report. This would make it possible to render hs more intelligently, e.g. by taking up all available vertical space at the command line (as opposed to a fixed number of lines, currently 20).

[SirVer]

What, like over Skype?

I am thinking videochat over Skype or Hangouts and floobits.com which I am interested in trying out, but never had the chance.

The time zones might be tricky, but other than that I'd be open to it.

I work a lot with people in your timezone. It can either work under the week pretty late for you (~22pm ish for you, 7am for me. I am an early bird) or on the weekends in the morning. Weekends will need more planing.

[cursor position report]

That feels like we are going down the path of reimplementing termbox. But I can see how that particular feature is useful.

[rschmitt]

Remember, I'm working in Rust. It's not surprising that a lot of the things I'll need to write in Rust are reimplementations of functionality that is already available in another language.

[SirVer]

Well, rustbox is already there and rather excellent: https://github.com/gchp/rustbox

I am not sure though if it can write non-fullscreen (full terminal?) application. After all you still want a commandline tool.

[rschmitt]

Right, ncurses seems to work the same way. It solves a ton of problems for you, but it wants to own the entire screen. And remember, any other abstraction layers that I use will have to be abstracted away again within Heatseeker, because I also support the Windows console. (The Windows console actually makes my job pretty easy. The API calls are icky, but conceptually it's the sweet spot: a frame buffer that you can draw things on, without having to manage the state of the entire buffer.)

[SirVer]

Have you looked at rustbox then? It is wrapping termbox which is inspired by the Windows API for the console. Maybe it really does what you want already. And it supports Windows and posix already.

[rschmitt]

Interesting. I'll have to take a closer look.

[SirVer]

Cool! Thanks!

Am 25.10.2015 um 22:42 schrieb Ryan Schmitt notifications@github.com:

Closed #12 via 40ba3a9.

— Reply to this email directly or view it on GitHub.

[rschmitt]

Does it work?

[SirVer]

Yes, like a charm :)