-
Notifications
You must be signed in to change notification settings - Fork 372
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
POC input rawmode #65
Conversation
I like the idea. There should be a way to get input from the terminal without relying on termbox's parsing abilities. But I will elaborate more on that tomorrow. Need to think about the way to do it in the API. |
Yeah I played around with it a bit and what really would be best (I think) is a hybrid of sorts. Return raw AND parsed event. The diff I wrote was tiny but it looked wrong since it was setting event.Raw before calling extract_event. Anywho glad you are going to noodle on it. Having this available would make my life easier so that i could parse some additional keystrokes. |
Well, the question is tricky, because there is also windows implementation and it has raw input too. On windows in fact I cut a lot of input info explicitly to emulate terminals behaviour. I'm thinking about some common interface that fits both. On terminals you get a raw stream of bytes, on windows you get structured events. As an option I can fill an array of bytes with raw bytes and/or this input structure on windows. But returning a slice as you did is not an option, it leads to mallocs, I'm thinking about io.Reader kind of interface. |
I haven't forgot about this issue. Still not sure how to do it right. :) Will try a couple of things today, but no promises. May take awhile. |
I am eagerly awaiting it. Meanwhile I am trying to figure out unicode stuff with termbox-go. |
Well, right now the only way I see it is this:
And add some kind of an int to While it's trivial to implement for *nix, it's a bit harder for windows, but not impossible. What do you think about that kind of API? |
Oh. On *nix it returns the raw stream of bytes of course. The feature must substitute both keyboard and mouse events. Will also add a new event type "EventRaw". |
I think I can live with that :) What may be neat is to expose the event parser. So that way one can intercept "magical key/mouse strokes" and pass on the event to the parser and get an Event type as termbox sees it. |
That's a good idea too. |
I am ready for this! Fighting with ^? vs ^H term stuff is amazingly bad... Thanks for looking at this btw! |
^? and ^H are two backspaces I think, there are Backspace and Backspace2 in termbox-go. In my opinion just handle them as if they are the same key. As for raw input stuff, sorry, I'm a bit busy right now. It probably delays until the weekend. |
Oh my I am an idiot. I did not see KeyBackspace2 at all. Thanks! |
Added *nix implementation. It's just a basic stuff, nothing fancy yet. More to be done. |
Have you decided on exporting the key parse call? |
Yes, but can't say when I'll add it. Sorry, busy with various stuff lately. This week though.. |
Added ParseEvent API. |
I'm closing the pull request. Because the functionality is in the repo now. No windows implementation yet, which is planned, but has low priority (not because it's windows, but because termbox-go in general is not the top priority in my list). |
This is a proof of concept to hand of raw terminal input to the calling application. We all agree that terminal input is absolutely awful but this way the application can do it's own parsing and be responsible for the entire keymap.
What do you think?