-
Notifications
You must be signed in to change notification settings - Fork 15
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
Using with Kinto v1.2-13 #36
Comments
I believe I'm now using the I'm on the latest pull of main as of last night. |
It's in |
Yes, I have seen the newer structures in This exact syntax was not self-explanatory (to me), but it seems to finally work:
|
They are just functions, like all the other functions (keymap, K, etc)... all invoked with |
I get that they are just functions, but what to put inside the So Is that even close to correct? |
Yes, I see the confusion - we need docs, but the functions inside API do show the input type expected (via
Any other types are silently ignored. (should probably raise an error instead)
Well, not really the name of a key (and
It's not just Python, uppercase classes are common in MANY languages.
Well it doesn't "set" anything really, but as an expression it evaluates to that, yes. Though I'm not fully sure "member object" is the right wording, but I think you have the overall idea. |
I see. Now things like:
Make a bit more sense to me.
Do most languages let you use "key", "Key", "kEy", "keY", "KEy", "KeY", and "kEY", all for different purposes, with the only difference being the capitalization? The capitalization of the class name specifically was not really my issue. That's fine, even helpful, if it's a generally understood styling standard.
You know, I have wondered in the past whether the Instead of (completely random shortcuts example):
Shouldn't it be possible to just do:
|
Many language are case-sensitive like this, yes. The difference between
Technically it could, but I'm not sure its a good idea because then you lose the ability to let a string be a string in the future... like right now one might possibly write:
And we could treat |
BUT if you learned Python it would be pretty trivial to write your own |
No, that would be bad. I'm perfectly fine with being required to call a function or variable with exact case. I just don't like how case sensitivity without enforcing case INsensitive uniqueness lets the programmer use the, quote, "same" word (or what we would normally consider the same word in everyday life) for completely different purposes. Shell scripts don't allow that, if I remember right. But you still have to call the variable with the right case. I have no issue with that at all. I just think it's much more clear if the language makes you use a slightly different name for every object, rather than letting you rely only on case. Heaven forbid things get named a bit more verbosely like "KeyClass" instead of just "Key" with a capital letter.
If by "a few" you mean around a dozen lines, that seems possible. I am working on a Still working my way through video tutorials like the one you linked to (which I actually found independently, and it's not a bad starter). But at the moment I'm still very much not getting how to do what you're describing. Or at least, all the variations I've tried so far have not worked.
Hmm. I don't immediately see the benefit. For the use case of a keymapper like this it feels like the more appropriate thing would be to get rid of |
Of course good syntax highlighting helps a lot with this as well.
I don't necessarily disagree, but I was pointing out the downside... I very much like using "implicit" classes when one can to simplify APIs, and giving up string for ALL potential future uses is a pretty big loss. Just because you can't think of a use other than
Seeing some specific code might help.
You don't need to worry about the textual form, you need to worry about the object form... you aren't trying to make a string (or that's the hard way IMHO)... you're literally trying to make a chain of objects... for example a very naive and overly simplistic def S(s):
keys = []
for letter in s.upper():
keys.append(Key[letter])
return keys >>> print(S("test"))
[<Key.T: 20>, <Key.E: 18>, <Key.S: 31>, <Key.T: 20>] Boom, turning a string into keys... Now you should still be able to |
Quick question. I have a line that prints the incoming string right at the top of the |
Yes. |
Hey I've been attempting to use this project with Kinto and every time I try to install it I end up having to reset my Kinto config so I'm coming here for help. I am using Kubuntu LTS. The first issue I run into is whenever I remove the imports from my kinto.py file, it lights up my editor due to all the functions not being defined. Is this normal? My editor tells me to import the functions from Keyszer but the docs say no import statements are needed. This also happens when I remove the re module as some of the items in the config require Regex in their names, but the docs say to just remove it... I don't understand how that's supposed to happen. Another issue I have is I'm failing to understand how everything is going to work together. Will Keyszer be replacing XKeysnail entirely? Or will Kinto, Keyszer, and XKeysnail all be running together at the same time? If anyone just has a config or clear instructions for this that would be really appreciated. I thought this would be a quick and easy fix like it was described on the Kinto issues page but I've sunk about 2 afternoons into this just to get modifier selections working 😭 |
Technically If what you want is a Mac-like config like Kinto, but using https://github.com/RedBearAK/toshy (shorter redirect URL: https://toshy.app) This project has a config that is based on Kinto's config, but has gone a bit beyond it in features (like automatically adapting itself to different desktop environments and keyboard types). I'm also using a customized branch of If you look at the default Toshy config file you'll see there are quite a few imports to get VSCode to calm down and highlight everything properly. Imports are technically not necessary because of the way the keymapper executes the config file. But as you've seen it makes it very difficult to work on the config in an editor like VSCode if you don't do the imports. And it's not harmful to do the imports. They are just kind of redundant outside the context of VSCode or some similar editor. The main |
Or I just turn off the linter. :-)
The config file is loaded and run dynamically by Keyszer - so it auto-adds some imports and other needed housekeeping before the Python is ever executed. We honestly should probably just rename it and stop telling everyone it's Python - then the editor would shut up and stop trying to figure it out. |
I would find that extremely unhelpful. I've done a lot of custom work in the config file and having the editor being completely incapable of helping me out with syntax highlighting and proper references would make it pretty unpleasant to work with the config. With the imports that I do, everything works just fine. |
Making an issue thread for discussion of early beta testers. This should be limited to getting your Kinto.sh config working with
keyszer
, any actual issues should be reported separately.Please see:
The text was updated successfully, but these errors were encountered: