fix: don't type character "0" to check if wtype works #10
Conversation
|
Maybe we could do Another solution could be to let the user override the command explicitly (e.g. |
|
@gilbsgilbs I can't even test it because wtype doesn't work for me at all. 😕
That would work well for me 👍 |
01c206b to
a820a75
Compare
|
I had another idea that should be feature-even with #9 and just fix my issue with "wtype 0". Rather than testing if wtype works in an preliminary step, I just try to wtype the emoji directly and if it doesn't work fallback to wl-copy. If I understood the problem correctly, this should also work for you @PotHix . AFAIAC, wofi-emoji shouldn't bother copying or typing the emoji at all and should just print it to standard output (letting the user pick the tool they want to consume it with). This would better embrace the unix philosophy and be easier to maintain. Otherwise, providing a "mode" as I suggested previously could still turn out handy: even users for whom wtype works fine might not want wofi-emoji to wtype it. |
87e5582 (dln#9) added a fallback to wl-clipboard when wtype isn't supported in the current environment. To do so, they invoked "wtype 0" to check whether wtype works. Unfortunately, this leads to inconsistent and buggy behaviors: sometimes the character "0" gets typed, and sometimes the current window loses focus (at least on my config). As there doesn't seem to be a way to know in advance if wtype will work without invoking it, this commit workarounds this issue by adopting the "EAFP" principle, trying to use wtype with the emoji directly, and only if it didn't work, invoke wl-copy.
|
That's a great idea, @gilbsgilbs! Just tried it and it works for me too. Let's wait for @dln to merge this in. :) |
|
I would rather have an explicit way to decide between type or copy, but for now this change is very much welcome. |
|
Copy is working for me, but not typing. |
Seems the original creator doesn't have time, so i'm gonna do it myself. Fixes bug when copy pasting emojis.
87e5582 (#9) added a fallback to
wl-clipboard when wtype isn't supported in the current environment. To
do so, they invoked "wtype 0" to check whether wtype works.
Unfortunately, this leads to inconsistent and buggy behaviors: sometimes
the character "0" gets typed, and sometimes the current window loses
focus (at least on my config).
As there doesn't seem to be a way to know in advance if wtype will work
without invoking it, this commit workarounds this issue by adopting the
"EAFP" principle, trying to use wtype with the emoji directly, and only
if it didn't work, invoke wl-copy.