Clipman has an option to preserve the stack order but the pointer to the active register changes which effectively means that the system paste command (e.g., ctrl-v) pastes from the active register not from the top of the stack as one might expect. For example: - paste something from clipman in the middle of the stack (thus marking that register active) - copy something - paste without calling clipman directly Result: the active register is pasted, not the most recently copied item. It seems useful to mark an active register but I think the system paste command should always paste the last copied item (as one would expect of a LIFO stack). I guess this interferes with your implementation of automatic pasting but I hope you can see a way to make it work. At the very least, it seems reasonable to set the active register to the top of the stack every time a new item is added (i.e., reset pointer on copy). On further testing, I notice this behaviour seems to only affect selections; i.e., the pointer does get reset on clipboard copy. In any case, I still think it's important to bind the system paste command to the top of the stack (i.e., the last copied item).
Can you give more precision on the clipman settings? Output of command: xfconf-query -c xfce4-panel -p /plugins/clipman -lv Can you make a screencast? I tried to reproduce the example you gave, everything is ok... (In reply to comment #0) > It seems useful to mark an active register but I think the system paste > command > should always paste the last copied item (as one would expect of a LIFO > stack). What do you call an active register? The system paste command? Is that when you right click and paste? Which LIFO stack? > I guess this interferes with your implementation of automatic pasting but I > hope you can see a way to make it work. At the very least, it seems > reasonable > to set the active register to the top of the stack every time a new item is > added (i.e., reset pointer on copy). You have an option to keep the stack order unchanged or always put the last copied content to the top of the history. Settings > Tweaks > Reorder history items. The 'automatic pasting' does nothing more than putting the selected item in the default and primary clipboards, and sends a sort of fake key to the system. > On further testing, I notice this behaviour seems to only affect selections; > i.e., the pointer does get reset on clipboard copy. In any case, I still > think it's important to bind the system paste command to the top of the > stack (i.e., the last copied item). You have in Xorg two clipboards, the default clipboard when you copy manually text, and the primary clibpoard when you select text with the mouse. The primary clipboard is the one that gets pasted with middle click for example. Thanks for clarifying me. Mike
> I tried to reproduce the example you gave, everything is ok... I'm not seeing it at the moment either > What do you call an active register? the menu item which is marked (in my case, with an arrow) > The system paste command? Is that when you right click and paste? yes (and ctrl-v, shift-insert, the "paste" menu item, &c.) > The 'automatic pasting' does nothing more than putting the selected item in > the default and primary clipboards and that wipes out the existing contents which is not good it seems reasonable to expect both primary and clipboard to remain unchanged after selecting an item from the history (even with automatic pasting enabled) indeed it is destructive to modify primary and clipboard why do you also copy to primary instead of just to clipboard? > You have in Xorg two clipboards we still have three, even if secondary is neglected this document[1] states possibly contradicting the ICCCM, clients don't need to support SECONDARY, though if anyone can figure out what it's good for they should feel free to use it for that yet the same document also states: The selection named by the atom SECONDARY is used: o As the second argument to commands taking two arguments (for example, "exchange primary and secondary selec- tions") o As a means of obtaining data when there is a primary selection and the user does not want to disturb it [1]: http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt
(In reply to comment #2) > > The 'automatic pasting' does nothing more than putting the selected item in > > the default and primary clipboards > > and that wipes out the existing contents > which is not good > > it seems reasonable to expect both primary and clipboard > to remain unchanged after selecting an item from the history > (even with automatic pasting enabled) > indeed it is destructive to modify primary and clipboard > > why do you also copy to primary > instead of just to clipboard? This has always been the expected behavior when cliking an item in the history -> it replaces the clipboards with a new content so that you can use it. Now that there is a possibility to paste instantly as you select an item, the clipboard content is also adjusted like it used to be. Are you suggesting there should be an option to not adjust the clipboard content when the option to paste instantly is used? I'm not yet sure what such an option should be called.
> This has always been the expected behavior when cliking an item in the > history -> it replaces the clipboards with a new content so that you can use > it. do you happen to know the origin of this pattern? > to paste instantly as you select an item this has always been the expected behaviour with the clipboard software I've used previously > Are you suggesting there should be an option to not adjust the clipboard > content when the option to paste instantly is used? I'm not yet sure what > such an option should be called. yes I'd call it "modify system clipboards" (and leave it off by default) with a tooltip that explains "replace CLIPBOARD and PRIMARY when selecting and item from the history"
(In reply to comment #4) > > This has always been the expected behavior when cliking an item in the > > history -> it replaces the clipboards with a new content so that you can use > > it. > > do you happen to know the origin of this pattern? Since the first version of clipman. That's also the behavior of gpaste, parcellite, glipper, and klipper. The purpose of this small plugin is to remember old clipboard contents, and reuse them as needed. And by reusing them, it is expected to be able to paste what you just selected in the history. > > Are you suggesting there should be an option to not adjust the clipboard > > content when the option to paste instantly is used? I'm not yet sure what > > such an option should be called. > > yes > I'd call it "modify system clipboards" > (and leave it off by default) > with a tooltip that explains > "replace CLIPBOARD and PRIMARY when > selecting and item from the history" Is feasible.
(In reply to comment #5) > > do you happen to know the origin of this pattern? > > Since the first version of clipman. That's also the behavior of gpaste, > parcellite, glipper, and klipper. The purpose of this small plugin is to > remember old clipboard contents, and reuse them as needed. And by reusing > them, it is expected to be able to paste what you just selected in the > history. more specifically I'm wondering why these programs do not simply paste directly from the history stack (without writing to the system clipboard) the Windows clipboard extensions I looked at also write to the clipboard (so perhaps it's merely imitation) by contrast, clipboard extensions for OS X and previous versions of Mac OS generally do not write to the clipboard