You are not logged in.
is there a spec/standard that dictates what shoud happen when you press shift-insert?
I notice some applications paste from primary selection buffer, others from clipboard.
examples:
* primary: urxvt, firefox
* clipboard: luakit, eclipse, chromium
(see also http://luakit.org/issues/121 )
< Daenyth> and he works prolifically
4 8 15 16 23 42
Offline
freedesktop.org has an "X clipboard explanation."
As text – http://standards.freedesktop.org/clipbo … ds-0.1.txt
As wiki – http://www.freedesktop.org/wiki/Specifi … boardsWiki
They provide it with this caveat:
X clipboard explanation is not a formal specification, but explains our consensus on how the X clipboard works. Qt and GTK+ both follow this document.
Offline
examples:
* primary: urxvt, firefox
* clipboard: luakit, eclipse, chromium
Shift-Insert in Firefox by default pastes CLIPBOARD for me. However, with Vimperator it does paste PRIMARY selection.
The spec posted by thisoldman does not say anything about Shift-Insert. Quoting the spec:
The correct behavior can be summarized as follows: CLIPBOARD works just like the clipboard on Mac or Windows; it only changes on explicit cut/copy. PRIMARY is an "easter egg" for expert users, regular users can just ignore it; it's normally pastable only via middle-mouse-click.
<snip>
explicit paste commands should paste CLIPBOARD, not PRIMARY
Can Shift-Insert be considered as an "explicit paste command" like Ctrl-v? I don't think so.
Is Shift-Insert supposed to paste CLIPBOARD on Mac / Windows? If so, maybe applications like Firefox will attempt to stay "consistent" across all platforms, which can be a strong argument... But then Shift-Insert is just a duplicate of Ctrl-v -- how stupid!
My personal preference is to have Shift-Insert to always paste PRIMARY, since middle-mouse-click sucks!
Last edited by lolilolicon (2011-09-24 04:02:01)
This silver ladybug at line 28...
Offline
Dieter@be wrote:examples:
* primary: urxvt, firefox
* clipboard: luakit, eclipse, chromiumShift-Insert in Firefox by default pastes CLIPBOARD for me. However, with Vimperator it does paste PRIMARY selection.
The spec posted by thisoldman does not say anything about Shift-Insert. Quoting the spec:
The correct behavior can be summarized as follows: CLIPBOARD works just like the clipboard on Mac or Windows; it only changes on explicit cut/copy. PRIMARY is an "easter egg" for expert users, regular users can just ignore it; it's normally pastable only via middle-mouse-click.
<snip>
explicit paste commands should paste CLIPBOARD, not PRIMARYCan Shift-Insert be considered as an "explicit paste command" like Ctrl-v? I don't think so.
Is Shift-Insert supposed to paste CLIPBOARD on Mac / Windows? If so, maybe applications like Firefox will attempt to stay "consistent" across all platforms, which can be a strong argument... But then Shift-Insert is just a duplicate of Ctrl-v -- how stupid!My personal preference is to have Shift-Insert to always paste PRIMARY, since middle-mouse-click sucks!
I agree with everything you said. I'm also using vimperator btw, probably that explains.
giving shift-insert the same functionality as ctrl-v would make it utterly pointless. Clipboard is well defined and has well defined shortcuts, all non-standard things - mouse selection for copy, mouse middle click for paste, and IMHO also shift-insert - should operate on primary.
< Daenyth> and he works prolifically
4 8 15 16 23 42
Offline
I too, do have to agree, Shift+Insert should paste PRIMARY.
This discussion has made me fix some minor irritations. I put back the old X behavior so that simultaneous left and right mouse clicks are a middle-click. My wheel push button is so stiff, I never knew how far I'd scroll when I pressed it.
I also bound Shift+Insert to always paste the primary selection, using xdotool and xclip. I suppose I could have used xset instead of xclip.
The Openbox binding:
<!-- paste PRIMARY -->
<keybind key="S-Insert">
<action name="Execute">
<execute>bash -c 'xdotool type --clearmodifiers "$(xclip -o)"'</execute>
</action>
</keybind>
Offline