You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Nowadays, because xdotool type --delay 0 "$string" mangles non-ASCII characters, I do this:
clipctl disable
Putting $string in the clipboard.
Pasting the clipboard in the target window.
Restoring the content of the clipboard. (By the way, shouldn’t clipctl enable restore itself the content of the clipboard to whatever is first in the list shown by clipmenu? Now I’m doing it by finding the most recently modified directory in $XDG_RUNTIME_DIR/clipmenu.7.$UID and putting the content of its file 1 in the clipboard.)
clipctl enable
But since I updated to the unreleased (I think) clipmenu 7, to take advantage of the fact that it doesn’t overwrite clips with the same first line, Steps 1 and 5 take a bit more than 100 ms each, which leads to a sensible delay when ‘typing’ in this way.
By looking at the code, I see this is due to a sleep command:
I understand it is needed to ensure clipmenu is really disabled/enabled before quitting, but isn’t 100 ms too much? Are there circumstances where it takes that long to disable itself?
As a workaround, I tried just backgrounding it in step 1 above: clipctl disable &, but this doesn’t leave enough time for clipmenud to disable itself and the $string is recorded by clipmenud.
Now I’m using another workaround: when launching clipmenud in xinitrc, I cache its PID in $XDG_RUNTIME_DIR/clipmenu.7.$UID/pid and in step 1 above, I just do kill -USR1 "$(<"$XDG_RUNTIME_DIR/clipmenu.7.$UID/pid")" as the old Bash clipctl did (without the caching of the PID). With that, I didn’t have a leak of $string in any of my tests.
So I’m wondering if it would not be possible to check every 1 ms or so rather than every 100 ms, or first every 1 ms and then every 100 ms for the exceptionally slow cases?
The text was updated successfully, but these errors were encountered:
Nowadays, because
xdotool type --delay 0 "$string"
mangles non-ASCII characters, I do this:clipctl disable
$string
in the clipboard.clipctl enable
restore itself the content of the clipboard to whatever is first in the list shown byclipmenu
? Now I’m doing it by finding the most recently modified directory in$XDG_RUNTIME_DIR/clipmenu.7.$UID
and putting the content of its file1
in the clipboard.)clipctl enable
But since I updated to the unreleased (I think) clipmenu 7, to take advantage of the fact that it doesn’t overwrite clips with the same first line, Steps 1 and 5 take a bit more than 100 ms each, which leads to a sensible delay when ‘typing’ in this way.
By looking at the code, I see this is due to a sleep command:
clipmenu/src/clipctl.c
Line 96 in 1113ca8
I understand it is needed to ensure clipmenu is really disabled/enabled before quitting, but isn’t 100 ms too much? Are there circumstances where it takes that long to disable itself?
As a workaround, I tried just backgrounding it in step 1 above:
clipctl disable &
, but this doesn’t leave enough time for clipmenud to disable itself and the$string
is recorded by clipmenud.Now I’m using another workaround: when launching clipmenud in xinitrc, I cache its PID in
$XDG_RUNTIME_DIR/clipmenu.7.$UID/pid
and in step 1 above, I just dokill -USR1 "$(<"$XDG_RUNTIME_DIR/clipmenu.7.$UID/pid")"
as the old Bash clipctl did (without the caching of the PID). With that, I didn’t have a leak of$string
in any of my tests.So I’m wondering if it would not be possible to check every 1 ms or so rather than every 100 ms, or first every 1 ms and then every 100 ms for the exceptionally slow cases?
The text was updated successfully, but these errors were encountered: