Configurable polling?

[kingcody]

I was wondering if allowing the polling interval of clipmenud to be configured was within the scope of this project?
Currently I have:

--- clipmenu/clipmenud
+++ clipmenu/clipmenud.new
@@ -1,11 +1,29 @@
 #!/bin/bash

+wait=1
+
+while getopts ":w:" opt; do
+  case $opt in
+    w)
+      wait="$OPTARG"
+      ;;
+    \?)
+      echo "Invalid option: -$OPTARG" >&2
+      exit 1
+      ;;
+    :)
+      echo "Option -$OPTARG requires an argument." >&2
+      exit 1
+      ;;
+  esac
+done
+
 cache_dir=/tmp/clipmenu.$USER/
 mkdir -p -m0700 "$cache_dir"

 declare -A last_data

-while sleep 1; do
+while sleep "$wait"; do
     for selection in clipboard primary; do
         if type -p xsel >/dev/null 2>&1; then
             data=$(xsel --"$selection"; printf x)

Your thoughts?

[cdown]

1 second was chosen as a balance between catching everything (if you copy two things within 1 second, probably the first one was a mistake) and keeping wakeups low.

If you can convince me that there's some legitimate reason to change it, then sure. I'm not sure what that would be, though.

[kaihendry]

Isn't there an inotifywait equivalent for clipboard changes? That would be the sane way forward. :)

[cdown]

If you think the X spec is sane and would include such a thing, you'd be sadly mistaken. As far as I know the X clipboard provides no notify interface (which would be required for that), hence the sleep.

[kingcody]

Well my personal use case was that I needed/wanted to reduce the sleep to .5 since I was copying and switching windows pretty quickly with key bindings and several times my selection hadn't made it to /tmp yet. Not a huge deal, but @ .5 it hasn't happened since. Obviously that would be too much for some people; hence, the configuration (with a default of 1).

[cdown]

Let me do some profiling and see what the performance impact of reducing the sleep would be.

[kingcody]

@cdown thanks