New struct for Key
Hi, awesome project, I would like to propose a new struct for Key, here is a rough example of what I would like to propose. This is a piece of code I didn't touch for a long time, I have several modifications in my mind already, so it's more like a draft.
Key point: just encode any possible combination of keys into a single struct.
The design is largely based on:
TermKeystruct used in vim/neovim, here it is.- Kitty terminal's proposal on Comprehensive keyboard handling in terminals.
I would be happy to hear your thoughts on this idea. I'm also willing to contribute this change.
Hi, Thank you for your interest in mibu. About key module/struct, I'm also thinking about changing it, but I would like to continue using a little hardcoded struct, mainly because its easier to use match keys using switch (here is an example).
mibu it still fairly uncomplete, and I'm open to change things. Maybe we can work together in a better Key module. Currently mibu doesn't support all keys yet.
These days I don't have too much time, but after I can work more on mibu.
but I would like to continue using a little hardcoded struct, mainly because its easier to use match keys using switch
It's true that it's easier with switch. My main concern is that I often use 4 modifiers: control, shift, alt, super. I see these problems:
- A lot of text to write with all possible combinations
- We have to memorize the exact order in which these keys occur, so for example,
CtrlShiftAltEis correct butShiftCtrlAltEis incorrect
An alternative to switch in my example is if (key.isCtrl('e')), for reference. This is less convenient and less fast. But at least performance shouldn't be an issue when we process keys. This also has a problem that you have to memorize the order, e.g. isCtrlShiftAlt('e') or isShiftCtrlAlt('e') but an alternative also exists isCtrl('e') and isShift('e') and isAlt('e') which is more verbose but also more universal.
Do you have any other concerns that you would like to discuss regarding my proposed implementation or any ideas of your own? I would like to hear any other interesting ideas. And feel free to answer at your pace, I won't expect anything quickly. Thanks!
Sorry for the late response, now I have more time to work on it.
You're right about combinations, maybe we could use a struct to avoid some verbosity, like key.isCtrl('e').isAlt('e') to key.isCtrl and key.isAlt. Also some keys can have an upper struct, like most common ones, so user can choose when use which. Sometimes it's better to use switch arms, and sometimes if else is needed.
What do you think?
Also some keys can have an upper struct
Do you mean an "upper letter" as in isCtrl('A')?
like
key.isCtrl('e').isAlt('e')tokey.isCtrl and key.isAlt
The first option looks something like a monad, we will need some helper functions to wrap/unwrap it. So the result would be something like key.isCtrl('e').isAlt('e').unwrap().
I'm sorry, I didn't explain it well. I meant like an two keys structs, A and B. A would be your proposal, B is mine proposal. B inherits A (not really, but basically that).
Do I understand correctly that you would like to take this option as a base isCtrl('e') and isShift('e'), and also add to it isCtrlC and other most common combinations?
Yes, only to most common ones.
That looks interesting, yes. I will soon try to implement parsing and using my variant for the key, I will also try to implement the most common combinations then, and I will see how it goes. I'm going to mostly use the parsing code from kakoune editor and also consult with your option. I can't say the timings on when I will be ready to present it so I think you can start implementing it too. We will be able to compare our implementations in this case and maybe get some interesting insights. Otherwise I will remember to share my implementation with you when it's ready.
For reference, I'm working on a text editor kisa and this is why I need this functionality. I also tried to use this mibu library at first, but later decided to write my own implementation. Mostly because of inline functions that allocate a buffer on the stack (this should work fine but for me it looks too hack-ish)
https://github.com/xyaman/mibu/blob/0eae78563eeee43560acd1a7053c9bdec2e2f334/src/color.zig#L29-L32
and because some functions accept comptime-known arguments whereas I needed runtime
https://github.com/xyaman/mibu/blob/0eae78563eeee43560acd1a7053c9bdec2e2f334/src/color.zig#L19-L21
and because I needed only a small subset of functionality which is not hard to implement.
Okay, I will work on my implementation. I made some hack-ish things, yeah, but mostly because I always thought about improving later and never thought people will be interested on the project (at least for the moment, it's very far for complete). Another thing to keep in mind is that I've never worked on terminals before, so everything is new for me. I will also work on making a comptime and a runtime version for every method, and I'll try to remove the buffer.
Thank you very much for your time and for helping to the project. It's always useful to have different perspectives about things.
Sure, thanks for your efforts on this project. Good luck with your implementation.
Hi, I decided to not add Ctrl + Shift option, it's not easy, as most terminal send the same code for Ctrl-Key and Ctrl-Shift-Key. I'm working on refactoring events struct.
I'm thinking something like this
const Key = union(enum) {
char: u8,
ctrl: u8,
shift: u8,
fun: u8,
up: void,
down: void,
left: void,
right: void,
esc: void,
delete: void,
// ...
fn NewCtrl(k: u8) @This() {
return @This(){
.ctrl = k,
};
}
// more functions, ex. `format()`
};
What do you think?
Edit: typo
What about Alt key? Shift+Alt is a fairly common combination at least in my workflow.
there is no problem with that, for example, shift + alt + "k" is the same as alt + "K".
alt 6 is not same as alt ^ in my terminal. Another point is combination of alt+ctrl, for example in Emacs it is heavily used for navigating per-sexp in lisps.
hello, I'm french excuse my english it's that of google:
I took over mibu. the term.zig function and upgraded to termios 2021 recommended standards add the stdin flush
in utils / event: I also put on/off mouse
I solved different keyboard key problem
I have developed mouse recovery
I will do a fork and update the fork
are you interested
I developed on https://github.com/AS400JPLPC and I intend to redo a designer
ps: I am retired I have more than 45 years of computer science mdrrrrr ;)
Hi! I've recently discovered the zig-spoon library which seems interesting. The only concern might be that zig-spoon is GPL licensed whereas the current repository is MIT. https://git.sr.ht/~leon_plickat/zig-spoon
Overall I'm still looking at finding the best library for the terminal keys, I will be following your efforts, thank you!
Hi @AS400JPLPC, thank you for your interest in the project. Where do you have the code? so I can check it? It seems that the link only redirects to your github profile.
it would be more explicit to say event.next(stdin.... or event.getKey(...
@AS400JPLPC could you share the code please? Also you opened another issue, is there any reason?
Excuse me I'm not much into github, just for publishing and saving. (I'm from the old school ;) ) You can delete the other incident.
I opened a free github project that you can download and use at your convenience. Of course, I would like to share with you your opinions and improve ...