Closed Zireael07 closed 1 month ago
I just tried your example and it works on windows 11 What OS are you on? Post full config please
Manjaro Linux
Shift >> Shift
Control >> Control
AltLeft >> AltLeft
# AltLeft >> Shift
# Space as Enter
# output Enter when is held for a while
Space{500ms} >> Enter
# 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'
Layer = Virtual1
CapsLock >> Layer
#Tab >> Layer
[modifier="Layer"]
# map to easily accessible keys (left hand | right hand)
# oiu seem the most obvious choice but then they block N, and using B+V for thumb means we don't have a key left for left-hand side since C is blocked there
a = Q | P
r = W | O
t = E | I
# 2nd row (shifted right, see above)
e = A | Semicolon
y = S | L
i = D | K
# thumb keys
s = M | V
o = N | V # N is often blocked on my keyboard if iou/jkl are pressed; C has the same problem on left-hand side
# 4
(a r t s ) >> Z
(a r t o) >> Tab
(a y i o) >> Virtual1
( e y i o) >> Space
# 3
(a r t ) >> D
(a r o) >> Escape
(a t s ) >> Q
( r t s ) >> X
( r i o) >> Virtual5
( e y i ) >> L
( e i o) >> P
( y i o) >> M
# 2
(a r ) >> F
(a s ) >> W
(a e ) >> Enter
(a y ) >> Comma
(a i ) >> Period
(a o) >> Slash
( r t ) >> G
( r s ) >> V
( r e ) >> Backspace
( r y ) >> Quote
( r i ) >> Delete
( t s ) >> J
( t i ) >> Shift{1}
( s e ) >> Virtual2
( s y ) >> Virtual3
( s i ) >> Virtual4
( s o) >> Shift{Slash}
( e y ) >> C
( e i ) >> H
( e o) >> B
( y i ) >> U
( y o) >> K
( i o) >> N
Virtual5{a} >> End
Virtual5{r} >> ArrowUp
Virtual5{s} >> PageUp
Virtual5{t} >> Home
Virtual5{y} >> ArrowDown
Virtual5{e} >> ArrowRight
Virtual5{i} >> ArrowLeft
Virtual5{o} >> PageDown
# 1
(a ) >> A
( r ) >> R
( t ) >> T
( s ) >> S
( e ) >> E
( y ) >> Y
( i ) >> I
( o) >> O
# ( e y i o) >> Space
# ( e1 y1 i1 o1) >> Space
# ( e1 y1 i o) >> Space
# ( e y i1 o1) >> Space
# e y >> $(echo "E+Y" >> ~\keymapper.txt)
#e y >> log["e y"]
#e1 y1 >> log['ey']
#i o >> log['oi']
# i1 o1 >> 'io'
# e y i >> "eyiii"
# test arpeggio
# order matters
# e !250ms y !250ms i !250ms o >> $(echo "Four letter arpeggio" >> ~\keymapper.txt)
# e1 !250ms y1 !250ms i1 !250ms o1 >> $(echo "Four letter arpeggio II" >> ~\keymapper.txt)
# e1 !250ms y1 !250ms i1 >> $(echo "Three letter" >> ~\keymapper.txt)
# e1 !250ms y1 >> $(echo "E1+Y1 arpg" >> ~\keymapper.txt)
#e !5ms y >> $(echo "E+Y Test" >> ~\keymapper.txt)
#e !5ms y >> ^"Test"
# e !250ms y >> $(echo "E+Y Arpg" >> ~\keymapper.txt)
#e !50ms y !50ms >> "Arpg"
#e !5ms y !5ms i !5ms o >> Space
# e y i >> $(echo \"E Y I\" >> ~\keymapper.txt)
# e1 y1 i1 o1 >> $(echo "Space" >> ~\keymapper.txt)
# e1 y1 i1 >> $(echo \"E1 Y1 I1\" >> ~\keymapper.txt)
#
# e y >> $(echo "E Y" >> ~\keymapper.txt)
# e1 y1 >> $(echo \"E1 Y1\" >> ~\keymapper.txt)
# i o >> $(echo "I O" >> ~\keymapper.txt)
a >> A
r >> R
t >> T
s >> S
e >> E
y >> Y
i >> I
o >> O
I cannot reproduce it on Linux either. Could you please create a minimal configuration which leads to this message?
Both git from roughly a year ago and 4.0.0 have the same issue.
The character typing feature was added more recently (in November). Before that strings were only allowed in terminal commands.
Try just with AltRight{A} >> 'ae'
The character typing feature was added more recently (in November).
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
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
$ wc -l *
97 keymapper.conf
156 keymapper.orig.conf
Are you referering to a specific lines of the config as the files are obviously different? 🙂
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:
$ xinput list | grep SINO
⎜ ↳ SINO WEALTH Gaming KB Consumer Control id=11 [slave pointer (2)]
⎜ ↳ SINO WEALTH Gaming KB Mouse id=32 [slave pointer (2)]
↳ SINO WEALTH Gaming KB id=9 [slave keyboard (3)]
↳ SINO WEALTH Gaming KB System Control id=10 [slave keyboard (3)]
↳ SINO WEALTH Gaming KB Consumer Control id=12 [slave keyboard (3)]
↳ SINO WEALTH Gaming KB Keyboard id=13 [slave keyboard (3)]
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 xinput
listing again, I realized the Any
was grabbing other devices as well. I don't know what actually causes this, but it seemed odd* that the numpad registers also as a pointer device. The issue got fixed when I then changed the device matcher to match only the keyboard devices:
NumpadApayado = /SINO WEALTH Gaming (KB |KB Keyboard)$/i
*) 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:
$ xinput | grep Keychron
⎜ ↳ Keychron Keychron K15 Pro Consumer Control id=21 [slave pointer (2)]
⎜ ↳ Keychron Keychron K15 Pro Mouse id=24 [slave pointer (2)]
↳ Keychron Keychron K15 Pro id=19 [slave keyboard (3)]
↳ Keychron Keychron K15 Pro Keyboard id=20 [slave keyboard (3)]
↳ Keychron Keychron K15 Pro Consumer Control id=22 [slave keyboard (3)]
↳ Keychron Keychron K15 Pro System Control id=23 [slave keyboard (3)]
The Any >> O is a debugging leftover (and worked properly)
The lines causing the problem are those two:
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 F1
when testing? You can only have one mapping per key in a section (or the implicit default section in the start).
@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 F1
prints pressed the key F1
into a file named ~\keymapper.txt
.
Is the prefix ~\
intententional or did you mean to put ~/
. It might be your system is more sensitive to odd file names than mine(?)
Edit: Forgot to add: AltRight{A}
outputs ae
as the config defines.
@Zireael07 I am thinking about closing this again. I can not reproduce it without a configuration which triggers the
Key name expected at ''' in line XY
message.
@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