-
Notifications
You must be signed in to change notification settings - Fork 91
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
Menu to delete clipboard entries #57
Comments
Yeah, this is reasonable (although storage shouldn't be permanent assuming /tmp is tmpfs, but tmpfs can swap). The better way would be to just not record them at all. If I added a way to temporarily disable clipmenud's monitoring for N seconds without stopping the daemon, would that work for you? |
Disabling it for X sec is another good thing. But I think to selectively delete something from the list is a killer feature. FYI: |
It does this by copying the empty string to the clipboard, or storing the value prior to copy and then restoring it (again, through copying). In this case there's nothing to delete since the X buffer only holds one entry. As for auto-clear, we should discuss that in another issue, but I'm not sure what the use case is without an example. |
As deletion would require an additional action, it should be introduced with an explicitly set startup option for the client to not break compatibility with current setup. You could have a double choice then:
Some basic shell stuff to show you what I mean:
|
Here are some ideas for
Now that we have flocking, this should be easy enough |
The list looks good. Can you explain what high entropy entries are. |
ie. "things that look like passwords", which appear random/high entropy |
A |
I wouldn't go with this. It is more or less impossible to judge if something is a password or not. |
For what it's worth, it's not really impossible to detect token-like passwords -- this is something I have actually worked on professionally :-) But yes, it's something that's only a nice to have alongside the others. |
|
At some point, clearing high entropy entries with |
5.3.0 just went out with clipdel. :-) I'll leave this open for clipdelmenu's arrival. |
Why complicate? X maintains three selections ("clipboards"), called PRIMARY, SECONDARY and CLIPBOARD.
If you use
Now what really makes this a sexy approach, is that you can have your password and your username clipped at the same time - username in PRIMARY, password in SECONDARY. Roughly 2 years ago I realized that this project was heading in a direction of unnecessary complexity (no offense). Thus I decided to stay on my own fork, focusing on simplicity and performance. Love |
Even within context, there's no bulletproof way of knowing if something like "call me maybe" is a password or some text you copied. Deleting from the clipboard history does make sense, but I'll just go about it with a quick |
(deleted spam.) |
So, I was thinking of the best way to implement a And then I have two proposals, and I'd like some input on which would be the best implementation (or if it'd make sense to implement both):
Both should be easy to implement and most of the work would be done in |
I guess just a simple Both options seem a little hacky to me. Maybe we could move the entire selection stuff into a separate file and have both |
No, no. The current code works like
I've just pushed an implementation to my branch. Could you please try it and give some feedback?
It is very simple. You can have a look at I hope to open a PR soon. |
Just tried it.
|
Sorry, should be fixed now. I've added some examples too. |
Yep works. Is it intentional that when piping input into |
Well, there's no sense in printing when reading from stdin. If one wants I will change the |
I guess that makes sense. |
A PR is open in #100. It'd be great to have some people testing it, especially the deleting part, as the logic was rewitten. As stated, a menu can be used for deletion with |
I simply use It assumes the password is not a regular expression that will nuke my clipmenu history, but:
|
Yes I think stopping monitoring would be the perfect solution for command line password managers like 'pass'. |
Yes, I think disable/stop monitoring would be great like passmenu --disable-history 45
pass -c secret/pass I don't know if could work the same workaround of https://github.com/erebe/greenclip/issues/5 |
This allows avoiding having to delete after the fact for things like issues #57 and #98. Why have this over just stopping clipmenud? Well: 1. Stopping clipmenud should usually be an init system action, but we are init-system agnostic. If we just exit, we don't have a way of reliably starting again. 2. Even if we *do* do it using the init system, we don't want some things (like a lingering xsel which owns the selection for CM_OWN_CLIPBOARD) being killed as well. 3. This is a nicer interface for things like password managers to stop clipmenu rather than stopping clipmenu entirely.
This allows avoiding having to delete after the fact for things like issues #57 and #98. Why have this over just stopping clipmenud? Well: 1. Stopping clipmenud should usually be an init system action, but we are init-system agnostic. If we just exit, we don't have a way of reliably starting again. 2. Even if we *do* do it using the init system, we don't want some things (like a lingering xsel which owns the selection for CM_OWN_CLIPBOARD) being killed as well. 3. This is a nicer interface for things like password managers to stop clipmenu rather than stopping clipmenu entirely.
Just to update, in the devel branch there is now a way to temporarily disable clipmenu from collecting clips. For example, I run the following when selecting a clip from pass:
Hopefully this helps with some of the cases in this thread. |
Does the current implementation (in the devel branch) allow deleting items from the same menu as selecting an item? If I've understood correctly (from the comments here), I would need to use 2 different commands (with 2 different keybindings):
It would be nice to use a single menu for both, and:
rofi-calc works like that; a single menu with the ability to either select or delete, with |
Unfortunately dmenu exposes nothing like this, so it would have to be a separate menu. I've personally not had the use for it, though, especially with |
Apparently, The However, Rofi also supports custom keybindings (bound to So, one of those custom keybindings could be set to
So, definitely seems possible to implement with Rofi. :) Would you accept a PR for this, if it can only work with Rofi (and not dmenu)? EDIT: To clarify, this wouldn't break anything when using |
This change is related to cdown#57 (comment). If `clipmenu` "preserves" the exit code from the launcher (exits with the same code as the launcher), the exit code's from Rofi's custom keybindings can be used with `clipmenu`. For example, I'm using the following script bound to `Super+v`: ``` #!/bin/bash trap "exit" INT # Run clipmenu CM_LAUNCHER=rofi clipmenu -p "Paste" -mesg "Use Shift+Delete to delete an item" \ -kb-delete-entry "" -kb-custom-1 "Shift+Delete" \ -kb-accept-alt "" -kb-custom-2 "Shift+Return" exit_code=$? case $exit_code in 0) xdotool key "shift+Insert" ;; 10) clipdel -d ^"$(xsel -b)"$; "$0" ;; *) exit $exit_code ;; esac ``` With the above script, I have 3 different options when running `clipmenu`: - if I press `Return`, the selected item is pasted to where my cursor currently is (a bit hackily with `xdotool`) - if I press `Shift+Return`, the selected item is sent to the clipboard ("default" `clipmenu` behavior) - if I press `Shift+Delete`, the selected item is deleted from `clipmenu`, and the script runs itself again (essentially keeps `clipmenu` open) In order for this to work, the only change needed in `clipmenu` is to preserve the exit codes from the custom keybindings.
I've opened #150, which allows using Rofi's custom keybindings with I'm using the following script, which I've bound to #!/bin/bash
trap "exit" INT
# Run clipmenu
CM_LAUNCHER=rofi clipmenu -p "Paste" -mesg "Use Shift+Delete to delete an item" \
-kb-delete-entry "" -kb-custom-1 "Shift+Delete" \
-kb-accept-alt "" -kb-custom-2 "Shift+Return"
exit_code=$?
case $exit_code in
0) xdotool key "shift+Insert" ;;
10) clipdel -d ^"$(xsel -b)"$; "$0" ;;
*) exit $exit_code ;;
esac With the above script, I have 3 different options when running
This requires only the small change in the PR. |
This change is related to #57 (comment). If `clipmenu` "preserves" the exit code from the launcher (exits with the same code as the launcher), the exit code's from Rofi's custom keybindings can be used with `clipmenu`. For example, I'm using the following script bound to `Super+v`: ``` #!/bin/bash trap "exit" INT # Run clipmenu CM_LAUNCHER=rofi clipmenu -p "Paste" -mesg "Use Shift+Delete to delete an item" \ -kb-delete-entry "" -kb-custom-1 "Shift+Delete" \ -kb-accept-alt "" -kb-custom-2 "Shift+Return" exit_code=$? case $exit_code in 0) xdotool key "shift+Insert" ;; 10) clipdel -d ^"$(xsel -b)"$; "$0" ;; *) exit $exit_code ;; esac ``` With the above script, I have 3 different options when running `clipmenu`: - if I press `Return`, the selected item is pasted to where my cursor currently is (a bit hackily with `xdotool`) - if I press `Shift+Return`, the selected item is sent to the clipboard ("default" `clipmenu` behavior) - if I press `Shift+Delete`, the selected item is deleted from `clipmenu`, and the script runs itself again (essentially keeps `clipmenu` open) In order for this to work, the only change needed in `clipmenu` is to preserve the exit codes from the custom keybindings.
Rofi script modi would be more useful - could be possible to operate with menu continuoustly, without restarting after each operation - e.g. remove multiple items, one after one, seeing immediate menu change. |
It is a simple rofi script: #!/usr/bin/bash
# A rofi bash script to delete entries in clipmenu.
if [[ $ROFI_RETV = 1 ]]; then
clipdel -d "^${@}\$"
fi
CM_LAUNCHER='rofi-script' clipmenu
|
clipdel is now in C, it should be very easy to add a menu mode which uses the same logic as clipdel, and the main logic can just be shared between clipdel{,menu}. PRs welcome :-) |
Hi there,
just tried out your tool. Great work 👍
Would it be possible to remove (also via rofi/dmenu) specific entries manually. This is because of the following reasons.
The text was updated successfully, but these errors were encountered: