-
Notifications
You must be signed in to change notification settings - Fork 24
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
Can't parse config with output characters #123
Comments
I just tried your example and it works on windows 11 |
Manjaro Linux
|
I cannot reproduce it on Linux either. Could you please create a minimal configuration which leads to this message?
The character typing feature was added more recently (in November). Before that strings were only allowed in terminal commands. |
Try just with |
If the case is that the feature isn't available in 4.0.0, it should be made clear in README. |
It is supported. Try a config with just that one line and make sure to store as ascii I'm not sure weird utf formats are supported |
Very good point! I have not thought about that. Only UTF-8 is supported. I should add that to the README and see if I can detect mojibake. |
I am trying to create a steno/artsey hybrid, so a config with just that one line won't cut it. It needs to work as part of a larger setup |
@Zireael07 Trust the process. You are the one reaching out. We are trying to debug your problem. Cut down the problem till we isolate the issue. |
Ideally you could attach a minimal configuration which raises this error message as a file. So a potentially problematic encoding is preserved. |
Gotcha. I tried remaking step by step and now it works? Both files are attached in case you find the difference somehow - orig is the one that didn't work. My text editors (Kate and open source version of VS Code) agree that both files are UTF-8 |
The obviously different part was all commented out in the original so shouldn't matter. As you see the beginning is the same except the problematic lines were commented out in the original and are NOT in the new one |
So this problem is currently not reproducible? Then I would close the issue for now. |
Yeah I'll do it, since the most likely culprit is some hidden character or something. Leaving this comment as a request for such an enhancement |
Bug struck again as soon as I edited the copied (working) config to introduce a change. Kate insists the file is normal UTF-8, BOM off. |
So now you have a config where this problem is reproducible? Can you please upload it? |
Uploaded, although it won't probably be of much use since the changes consisted of: adding config for my new numpad (that's what the "SZH usb keyboard" really is) AND commenting out the lines that caused the bug to appear |
Do you mean a bug in how the mappings behave or Keymapper saying the config is not valid? I spotted only a couple of commented out lines and none of them caused an error. Was this by any chance the line you were referring to? [device="SZH usb keyboard"]
#Any >> O If it's this and you're on Linux, I bumped into an issue with something very similar. A big portion of my mappings stopped working but I got it fixed. The issue you're having might be completely different but I'll describe what I ran across in case it happens to be the same. In my case, this is how the device shows up:
Initially I had it set up like this: NumpadApayado = /SINO WEALTH Gaming KB/i
# ... lots of other config
[device = NumpadApayado]
# ... a few mappings
Any >> Any
# ... lots of other config, some of them not working anymore After looking at the
*) The reason is likely not that odd. I'm guessing it just contains some chip that also supports that. The listing looks awfully similar to how my Keychron keyboard shows up in the listing:
|
The Any >> O is a debugging leftover (and worked properly) The lines causing the problem are those two: #F1 >> print["pressed the key", F1] #AltRight{A} >> 'ae' if I uncomment them, I get Key name expected at... error Yes I'm on Linux |
Did you comment out the other line that starts with |
@ristomatti I don't remember - anyway if you can only have one mapping per key the error message should say that and not "Key name expected at..." |
If I edit this range like so: # test chorded things
#log = $(echo "$0" >> ~/tmp/keymapper.log)
print = $(echo $0 $1 >> ~\keymapper.txt)
# F1 >> $(echo F1 >> ~\keymapper.txt)
F1 >> print["pressed the key", F1]
AltRight{A} >> 'ae' Config updates. Pressing Is the prefix Edit: Forgot to add: |
@Zireael07 I am thinking about closing this again. I can not reproduce it without a configuration which triggers the |
@houmain One vote from me. No activity tends to either means the issue went away, the OP found a different app that felt better suited or gave up altogether. |
I missed the updates here somehow even though I'm watching the repo. Currently, as ristomatti correctly guessed, I am using a different app for my personal computer. |
Both git from roughly a year ago and 4.0.0 have the same issue.
AltRight{A} >> 'ae'
Results in Key name expected at ''' in line 56
EDIT: Same problem with the print = $(echo $0 $1 >> ~\keymapper.txt)
F1 >> print["pressed the key", F1]
example from README.
surprisingly, e y >> $(echo e y >> ~\keymapper.txt) works
The text was updated successfully, but these errors were encountered: