Re: [dev] st: selecting text affects both primary and clipbaord
Greetings. On Sat, 14 Mar 2015 07:39:29 +0100 Alex Pilon a...@alexpilon.ca wrote: On 03/10/2015 10:49 PM, Alex Pilon wrote: Are you thinking of something like the attached? On Wed, Mar 11, 2015 at 01:01:11PM -0400, Greg Reagle wrote: That looks fine to me, looking at it briefly, but I haven't tested it (yet). Sorry about the noise. It *seemed* to work before; serves me right. I completely misunderstood X selection management. Here's what I think is a fixed patch. Also, I removed the selection clear event handler registration. I just didn't like the visual selection being cleared just because I set it in another program. Remove that hunk if you disagree. Thanks for sending in the patch. I applied it with some minor changes: * the clipboard atom has to be requested via XInternAtom * xstrdup instead of strdup * the primary selection could be empty when someone is asking to copy to the clipboard * the SelectionClear X11 event is now a comment so someone too passionate about it can remove the comment Sincerely, Christoph Lohmann
Re: [dev] st: selecting text affects both primary and clipbaord
On March 12, 2015 11:05:10 AM CDT, Wander Nauta i...@wandernauta.nl wrote: Do most numpad-less laptop keyboards even have Insert or a middle mouse button? Macbooks have neither, I believe, and they're fairly popular. They have insert at fn+Enter. Of course, it's not labeled. -- Regards, Samuel Holland sam...@sholland.net
Re: [dev] st: selecting text affects both primary and clipbaord
Greetings. On Fri, 13 Mar 2015 17:49:45 +0100 Kai Hendry hen...@iki.fi wrote: My 2 cents: Suggestions to use 3 keys to copy paste SUCK Can we please have feature parity with MacOSX? cmd-c, cmd-v NEVER. Mac OS X users have to tortured and explictly selected for even more torture than customers. I guess cmd is that Windows key (keycode 133, Super_L?) on non-Apple hardware. Heavens know how to make cmd-c, cmd-v work in Chrome. I don’t support proprietary platforms. BONUS: Keep selection in the clipboard after I close the terminal window. Changing the X11 protocol is not an intention of st. You will have to add your own clipboard manager for this. Before anyone asks _which_ clipboard, my brain can only model one clipboard between any application. I'm sorry. I'm stupid. That’s why you are an Apple user. Sincerely, Christoph Lohmann
Re: [dev] st: selecting text affects both primary and clipbaord
Greetings. On Tue, 10 Mar 2015 22:02:30 +0100 Greg Reagle greg.rea...@umbc.edu wrote: On Mon, Mar 9, 2015, at 04:15 PM, Christoph Lohmann wrote: Can you please elaborate where you use both selections in parallel for different tasks and where st does interfere? [...] But this discussion happened already on this list, and despite the obvious correctness of what I'm saying here, the powers that be preferred to keep the current broken behavior, so the correct behavior is now a patch on the wiki. The text convinced me that st did it wrong. It is now using primary just for the selection. Are there any good suggestions for the shortcut to copy to the clipboard? Ctrl + y does interfere with everything. Sincerely, Christoph Lohmann
Re: [dev] st: selecting text affects both primary and clipbaord
My 2 cents: Suggestions to use 3 keys to copy paste SUCK Can we please have feature parity with MacOSX? cmd-c, cmd-v I guess cmd is that Windows key (keycode 133, Super_L?) on non-Apple hardware. Heavens know how to make cmd-c, cmd-v work in Chrome. BONUS: Keep selection in the clipboard after I close the terminal window. Before anyone asks _which_ clipboard, my brain can only model one clipboard between any application. I'm sorry. I'm stupid. When I want a clipboard history I use https://github.com/cdown/clipmenu Thank you,
Re: [dev] st: selecting text affects both primary and clipbaord
On 03/10/2015 10:49 PM, Alex Pilon wrote: Are you thinking of something like the attached? That looks fine to me, looking at it briefly, but I haven't tested it (yet).
Re: [dev] st: selecting text affects both primary and clipbaord
Le mardi 10 mars 2015 à 10:08:21, Markus Teich a écrit : Christoph Lohmann wrote: The text convinced me that st did it wrong. It is now using primary just for the selection. Are there any good suggestions for the shortcut to copy to the clipboard? Ctrl + y does interfere with everything. Heyho, some other terminal emulators use ctrl-shift-c and ctrl-shift-v. --Markus I agree with Markus, those keys seems to be the combo commonly used by the majority of terminal emulators I've used on GNU/Linux systems. Regards, -- Sébastien Poher www.volted.net Aidez-nous à défendre la liberté du logiciel: http://www.fsf.org/register_form?referrer=11902 signature.asc Description: Digital signature
Re: [dev] st: selecting text affects both primary and clipbaord
I see some people arguing *passionately* about the keybindings, as if they don't know that they can be changed. Yea we can and should have some discussion about reasonable defaults, but you can set the keys however you want in config.h. Just some perspective. Suckless people are passionate. : -- http://www.fastmail.com - Access all of your messages and folders wherever you are
Re: [dev] st: selecting text affects both primary and clipbaord
On Thu, Mar 12, 2015 at 04:35:58PM +0800, Kai Hendry wrote: My 2 cents: Suggestions to use 3 keys to copy paste SUCK Can we please have feature parity with MacOSX? cmd-c, cmd-v On Thu, Mar 12, 2015 at 08:17:22AM -0300, Amadeus Folego wrote: This can be a problem for (I think) many users of st that use this key as the modifier for tiling window managers. Not just tiling ones. The reason being because *almost* no other program uses it… save MPV? Why is that? Portability to BlowD0S? As much as I don't like C-S-C, C-S-V too, the reasons K0ga presented seem very sane as a default keybinding. For clipboard only, for consistency. One should still keep S-Insert for primary. Yes, C-S-whatever uses two weak fingers¹, but still. Also, do most numpad-less laptop keyboards even have Insert or a middle mouse button? ¹: Assuming you rebound caps lock. pgpGYiTaiMbeB.pgp Description: PGP signature
Re: [dev] st: selecting text affects both primary and clipbaord
* Alex Pilon 2015-03-12 15:17 Also, do most numpad-less laptop keyboards even have Insert all I've ever seen do. or a middle mouse button? some do have middle. all i've ever seen have at least 2 buttons. you can emulate middle button as simultaneous left+right. --s
Re: [dev] st: selecting text affects both primary and clipbaord
Do most numpad-less laptop keyboards even have Insert or a middle mouse button? Macbooks have neither, I believe, and they're fairly popular. Cheers, Wander On Thu, Mar 12, 2015 at 4:53 PM, sta...@cs.tu-berlin.de wrote: * Alex Pilon 2015-03-12 15:17 Also, do most numpad-less laptop keyboards even have Insert all I've ever seen do. or a middle mouse button? some do have middle. all i've ever seen have at least 2 buttons. you can emulate middle button as simultaneous left+right. --s
Re: [dev] st: selecting text affects both primary and clipbaord
Quoth Amadeus Folego: On Thu, Mar 12, 2015 at 05:05:10PM +0100, Wander Nauta wrote: Do most numpad-less laptop keyboards even have Insert or a middle mouse button? Macbooks have neither, I believe, and they're fairly popular. I thought there was a gesture to perform middle button, was I wrong? 'synclient TapButton2=2' sets a two finger tap as middle mouse button. It takes a little practise to do, and it sure isn't as comfortable as a proper button would be, but it works.
Re: [dev] st: selecting text affects both primary and clipbaord
On Thu, Mar 12, 2015 at 05:05:10PM +0100, Wander Nauta wrote: Do most numpad-less laptop keyboards even have Insert or a middle mouse button? Macbooks have neither, I believe, and they're fairly popular. I thought there was a gesture to perform middle button, was I wrong?
Re: [dev] st: selecting text affects both primary and clipbaord
On Thu, Mar 12, 2015 at 04:35:58PM +0800, Kai Hendry wrote: My 2 cents: Suggestions to use 3 keys to copy paste SUCK Can we please have feature parity with MacOSX? cmd-c, cmd-v This can be a problem for (I think) many users of st that use this key as the modifier for tiling window managers. As much as I don't like C-S-C, C-S-V too, the reasons K0ga presented seem very sane as a default keybinding. This can be changed later anyway.
Re: [dev] st: selecting text affects both primary and clipbaord
On 03/10/2015 10:49 PM, Alex Pilon wrote:
Are you thinking of something like the attached?
On Wed, Mar 11, 2015 at 01:01:11PM -0400, Greg Reagle wrote:
That looks fine to me, looking at it briefly, but I haven't tested it (yet).
Sorry about the noise. It *seemed* to work before; serves me right. I
completely misunderstood X selection management. Here's what I think is
a fixed patch.
Also, I removed the selection clear event handler registration. I just
didn't like the visual selection being cleared just because I set it in
another program. Remove that hunk if you disagree.
diff --git a/config.def.h b/config.def.h
index cd9292a..667f334 100644
--- a/config.def.h
+++ b/config.def.h
@@ -120,7 +120,8 @@ static Shortcut shortcuts[] = {
{ MODKEY|ShiftMask, XK_Next,xzoom, {.i = -1} },
{ MODKEY|ShiftMask, XK_Home,xzoomreset, {.i = 0} },
{ ShiftMask,XK_Insert, selpaste, {.i = 0} },
- { MODKEY|ShiftMask, XK_Insert, clippaste, {.i = 0} },
+ { ControlMask|ShiftMask,XK_C, clipcopy, {.i = 0} },
+ { ControlMask|ShiftMask,XK_V, clippaste, {.i = 0} },
{ MODKEY, XK_Num_Lock,numlock,{.i = 0} },
};
diff --git a/st.c b/st.c
index 595a955..a429103 100644
--- a/st.c
+++ b/st.c
@@ -290,7 +290,7 @@ typedef struct {
int x, y;
} nb, ne, ob, oe;
- char *clip;
+ char *primary, *clipboard;
Atom xtarget;
bool alt;
struct timespec tclick1;
@@ -312,6 +312,7 @@ typedef struct {
} Shortcut;
/* function definitions used in config.h */
+static void clipcopy(const Arg *);
static void clippaste(const Arg *);
static void numlock(const Arg *);
static void selpaste(const Arg *);
@@ -479,7 +480,6 @@ static void (*handler[LASTEvent])(XEvent *) = {
[MotionNotify] = bmotion,
[ButtonPress] = bpress,
[ButtonRelease] = brelease,
- [SelectionClear] = selclear,
[SelectionNotify] = selnotify,
[SelectionRequest] = selrequest,
};
@@ -493,6 +493,7 @@ static STREscape strescseq;
static int cmdfd;
static pid_t pid;
static Selection sel;
+static Atom XA_CLIPBOARD;
static int iofd = STDOUT_FILENO;
static char **opt_cmd = NULL;
static char *opt_io = NULL;
@@ -640,10 +641,12 @@ selinit(void) {
memset(sel.tclick2, 0, sizeof(sel.tclick2));
sel.mode = 0;
sel.ob.x = -1;
- sel.clip = NULL;
+ sel.primary = NULL;
+ sel.clipboard = NULL;
sel.xtarget = XInternAtom(xw.dpy, UTF8_STRING, 0);
if(sel.xtarget == None)
sel.xtarget = XA_STRING;
+ XA_CLIPBOARD = XInternAtom(xw.dpy, CLIPBOARD, 0);
}
static int
@@ -985,10 +988,12 @@ selnotify(XEvent *e) {
int format;
uchar *data, *last, *repl;
Atom type;
+ XSelectionEvent *xsev;
ofs = 0;
+ xsev = (XSelectionEvent*) e;
do {
- if(XGetWindowProperty(xw.dpy, xw.win, XA_PRIMARY, ofs, BUFSIZ/4,
+ if(XGetWindowProperty(xw.dpy, xw.win, xsev-property, ofs, BUFSIZ/4,
False, AnyPropertyType, type, format,
nitems, rem, data)) {
fprintf(stderr, Clipboard allocation failed\n);
@@ -1027,10 +1032,7 @@ selpaste(const Arg *dummy) {
void
clippaste(const Arg *dummy) {
- Atom clipboard;
-
- clipboard = XInternAtom(xw.dpy, CLIPBOARD, 0);
- XConvertSelection(xw.dpy, clipboard, sel.xtarget, XA_PRIMARY,
+ XConvertSelection(xw.dpy, XA_CLIPBOARD, sel.xtarget, XA_CLIPBOARD,
xw.win, CurrentTime);
}
@@ -1047,6 +1049,7 @@ selrequest(XEvent *e) {
XSelectionRequestEvent *xsre;
XSelectionEvent xev;
Atom xa_targets, string;
+ char* seltext;
xsre = (XSelectionRequestEvent *) e;
xev.type = SelectionNotify;
@@ -1065,11 +1068,23 @@ selrequest(XEvent *e) {
XA_ATOM, 32, PropModeReplace,
(uchar *) string, 1);
xev.property = xsre-property;
- } else if(xsre-target == sel.xtarget sel.clip != NULL) {
- XChangeProperty(xsre-display, xsre-requestor, xsre-property,
-xsre-target, 8, PropModeReplace,
-(uchar *) sel.clip, strlen(sel.clip));
- xev.property = xsre-property;
+ } else if(xsre-target == sel.xtarget) {
+ if (xsre-selection == XA_PRIMARY) {
+ seltext = sel.primary;
+ } else if (xsre-selection == XA_CLIPBOARD) {
+ seltext = sel.clipboard;
+ } else {
+ fprintf(stderr,
+ Unhandled clipboard selection 0x%lx\n,
+ xsre-selection);
+ return;
+ }
+ if (seltext != NULL) {
+ XChangeProperty(xsre-display, xsre-requestor, xsre-property,
+ xsre-target, 8, PropModeReplace,
+ (uchar *) seltext, strlen(seltext));
+ xev.property = xsre-property;
+ }
}
/* all done, send a notification to the listener */
@@ -1079,16 +1094,18 @@ selrequest(XEvent *e) {
void
xsetsel(char *str) {
- /* register the selection for both the clipboard and the primary */
- Atom clipboard;
-
- free(sel.clip);
- sel.clip = str;
+ free(sel.primary);
+ sel.primary = str;
XSetSelectionOwner(xw.dpy, XA_PRIMARY, xw.win, CurrentTime);
+}
- clipboard = XInternAtom(xw.dpy, CLIPBOARD, 0);
- XSetSelectionOwner(xw.dpy, clipboard, xw.win, CurrentTime);
+void
+clipcopy(const Arg *arg) {
+ if
Re: [dev] st: selecting text affects both primary and clipbaord
I really don't like the idea of C-S-C or M3-C as these are really basic keybinds and may be used for applications. Also the proximity with C-C makes it easier to terminate a running application when you just wanted to copy some text. It is impossible to use ctrl + shift combinations in the terminal world. Shift makes an or with 0x20 and ctrl makes an and with 0x1f, so if you press them at the same time you are going to have something like (c | 0x20) ^ 0x1f == c 0x1f. C-Ins looked like a nice suggestion, even though we are not inserting text into the application. I prefer the ctrl + shift for the reason I posted (they cannot be used in a terminal application) and because I would like to use ctrl + insert for an ascii mode sequence. Regards,
Re: [dev] st: selecting text affects both primary and clipbaord
On Wed, Mar 11, 2015 at 08:05:37AM +0100, Roberto E. Vargas Caballero wrote: I really don't like the idea of C-S-C or M3-C as these are really basic keybinds and may be used for applications. Also the proximity with C-C makes it easier to terminate a running application when you just wanted to copy some text. It is impossible to use ctrl + shift combinations in the terminal world. Shift makes an or with 0x20 and ctrl makes an and with 0x1f, so if you press them at the same time you are going to have something like (c | 0x20) ^ 0x1f == c 0x1f. This is news for me, thanks for the detailed explanation.
Re: [dev] st: selecting text affects both primary and clipbaord
On Tue, Mar 10, 2015 at 05:18:49PM -0400, Greg Reagle wrote:
It could go the other way and do a variant of Ctrl+C for copy and Ctrl+V
for paste. I wouldn't use them directly because the programs running in
st probably need those keys. So Alt+Ctrl+C/V or Shitf+Ctrl+C/V or
Alt+C/V.
Also, it could provide key bindings for both CUA and the other way. I
don't think that would complicate the code much.
Are you thinking of something like the attached?
diff --git a/config.def.h b/config.def.h
index cd9292a..667f334 100644
--- a/config.def.h
+++ b/config.def.h
@@ -120,7 +120,8 @@ static Shortcut shortcuts[] = {
{ MODKEY|ShiftMask, XK_Next,xzoom, {.i = -1} },
{ MODKEY|ShiftMask, XK_Home,xzoomreset, {.i = 0} },
{ ShiftMask,XK_Insert, selpaste, {.i = 0} },
- { MODKEY|ShiftMask, XK_Insert, clippaste, {.i = 0} },
+ { ControlMask|ShiftMask,XK_C, clipcopy, {.i = 0} },
+ { ControlMask|ShiftMask,XK_V, clippaste, {.i = 0} },
{ MODKEY, XK_Num_Lock,numlock,{.i = 0} },
};
diff --git a/st.c b/st.c
index 595a955..b969fc3 100644
--- a/st.c
+++ b/st.c
@@ -312,6 +312,7 @@ typedef struct {
} Shortcut;
/* function definitions used in config.h */
+static void clipcopy(const Arg *);
static void clippaste(const Arg *);
static void numlock(const Arg *);
static void selpaste(const Arg *);
@@ -479,7 +480,6 @@ static void (*handler[LASTEvent])(XEvent *) = {
[MotionNotify] = bmotion,
[ButtonPress] = bpress,
[ButtonRelease] = brelease,
- [SelectionClear] = selclear,
[SelectionNotify] = selnotify,
[SelectionRequest] = selrequest,
};
@@ -1027,10 +1027,8 @@ selpaste(const Arg *dummy) {
void
clippaste(const Arg *dummy) {
- Atom clipboard;
-
- clipboard = XInternAtom(xw.dpy, CLIPBOARD, 0);
- XConvertSelection(xw.dpy, clipboard, sel.xtarget, XA_PRIMARY,
+ Atom clipboard = XInternAtom(xw.dpy, CLIPBOARD, 0);
+ XConvertSelection(xw.dpy, clipboard, sel.xtarget, clipboard,
xw.win, CurrentTime);
}
@@ -1079,15 +1077,16 @@ selrequest(XEvent *e) {
void
xsetsel(char *str) {
- /* register the selection for both the clipboard and the primary */
- Atom clipboard;
-
free(sel.clip);
sel.clip = str;
XSetSelectionOwner(xw.dpy, XA_PRIMARY, xw.win, CurrentTime);
+}
- clipboard = XInternAtom(xw.dpy, CLIPBOARD, 0);
+void
+clipcopy(const Arg *arg) {
+ /* sel.clip already set by xsetsel---can't copy without selecting. */
+ Atom clipboard = XInternAtom(xw.dpy, CLIPBOARD, 0);
XSetSelectionOwner(xw.dpy, clipboard, xw.win, CurrentTime);
}
@@ -4051,4 +4050,3 @@ run:
return 0;
}
-
pgpVLyFCGCbPD.pgp
Description: PGP signature
Re: [dev] st: selecting text affects both primary and clipbaord
On Tue, Mar 10, 2015 at 05:18:49PM -0400, Greg Reagle wrote: It could go the other way and do a variant of Ctrl+C for copy and Ctrl+V for paste. I wouldn't use them directly because the programs running in st probably need those keys. So Alt+Ctrl+C/V or Shitf+Ctrl+C/V or Alt+C/V. Also, it could provide key bindings for both CUA and the other way. I don't think that would complicate the code much. I really don't like the idea of C-S-C or M3-C as these are really basic keybinds and may be used for applications. Also the proximity with C-C makes it easier to terminate a running application when you just wanted to copy some text. C-Ins looked like a nice suggestion, even though we are not inserting text into the application. So I am not really suggesting anything, I just wanted to point out these factors.
Re: [dev] st: selecting text affects both primary and clipbaord
Christoph Lohmann wrote: The text convinced me that st did it wrong. It is now using primary just for the selection. Are there any good suggestions for the shortcut to copy to the clipboard? Ctrl + y does interfere with everything. Heyho, some other terminal emulators use ctrl-shift-c and ctrl-shift-v. --Markus
Re: [dev] st: selecting text affects both primary and clipbaord
On Tue, Mar 10, 2015, at 05:02 PM, Christoph Lohmann wrote: The text convinced me that st did it wrong. It is now using primary just for the selection. Are there any good suggestions for the shortcut to copy to the clipboard? Ctrl + y does interfere with everything. My two cents . . . It could go the CUA route and do Shift+Insert for paste (from clipboard) and Control+Insert for copy (to clipboard). It could go the other way and do a variant of Ctrl+C for copy and Ctrl+V for paste. I wouldn't use them directly because the programs running in st probably need those keys. So Alt+Ctrl+C/V or Shitf+Ctrl+C/V or Alt+C/V. Also, it could provide key bindings for both CUA and the other way. I don't think that would complicate the code much. I don't think ther *needs* to be a key for paste from primary selection since that is what the middle button does, but it wouldn't hurt to provide a key. Maybe we have some X users who hate touching their mouse. -- http://www.fastmail.com - The professional email service
Re: [dev] st: selecting text affects both primary and clipbaord
On Mon, Mar 9, 2015, at 04:15 PM, Christoph Lohmann wrote: Can you please elaborate where you use both selections in parallel for different tasks and where st does interfere? Hi Christoph. Well actually yes I do use both selections independently. I use clipboard selection when I explicitly command cut/copy/paste, and I use primary selection when I implicitly copy/paste (i.e. when selecting with mouse-button-1 and pasting with mouse-button-2). I keep track of them separately in my mind and they have different contents and I use them for different purposes. I find this feature quite useful. Having st set both selections when I'm just selecting with the mouse destroys my clipboard selection data. It is all explained in the web page that I've referred to several times already. But this discussion happened already on this list, and despite the obvious correctness of what I'm saying here, the powers that be preferred to keep the current broken behavior, so the correct behavior is now a patch on the wiki. -- http://www.fastmail.com - Email service worth paying for. Try it for free
Re: [dev] st: selecting text affects both primary and clipbaord
I know this isn't a democracy, but I agree with Greg, it makes more sense to only set PRIMARY, not CLIPBOARD, in selcopy. Removing the clipboard-related lines from xsetsel seems to do the trick. I've attached a patch that does just that. I agree here, it shouldn't modiy the CLIPBOARD seletction. Sometime is good to have different things in both selections. If nobady claims about it I will apply your patch. You can see that a lot of people sent good reasons to don't apply it. If the suckless powers that be don't want to apply this patch to the main branch, can we get it listed on http://st.suckless.org/patches/? You can do it by yourself. Clone the wiki repository and push the change. Regards,
Re: [dev] st: selecting text affects both primary and clipbaord
On Sat, Feb 21, 2015 at 09:26:50AM +0100, k...@shike2.com wrote: You can do it by yourself. Clone the wiki repository and push the change. Oh, I did not know that the wiki was in a git repository. Thank you for informing me. I don't think I have permission to push (I have limited experience with and understanding of git), but I'll work on a patch to include the patch for st.
Re: [dev] st: selecting text affects both primary and clipbaord
On Thu, Feb 19, 2015, at 06:46 PM, Wander Nauta wrote: I know this isn't a democracy, but I agree with Greg, it makes more sense to only set PRIMARY, not CLIPBOARD, in selcopy. Removing the clipboard-related lines from xsetsel seems to do the trick. I've attached a patch that does just that. If the suckless powers that be don't want to apply this patch to the main branch, can we get it listed on http://st.suckless.org/patches/? -- http://www.fastmail.com - IMAP accessible web-mail
Re: [dev] st: selecting text affects both primary and clipbaord
Hello list, I know this isn't a democracy, but I agree with Greg, it makes more sense to only set PRIMARY, not CLIPBOARD, in selcopy. Removing the clipboard-related lines from xsetsel seems to do the trick. I've attached a patch that does just that. I agree here, it shouldn't modiy the CLIPBOARD seletction. Sometime is good to have different things in both selections. If nobady claims about it I will apply your patch. Regards,
Re: [dev] st: selecting text affects both primary and clipbaord
* k...@shike2.com 2015-02-20 17:39 I agree here, it shouldn't modiy the CLIPBOARD seletction. Sometime is good to have different things in both selections. If nobady claims about it I will apply your patch. I'd leave it as is, in order not to break scrips which expect to read something from CLIPBOARD. In other programms, you might have the choice to send something to selection or CLIPBOARD by different means. In st, however, you don't. Thus, the current behaviour seems to me more consistent and intuitive. --s
Re: [dev] st: selecting text affects both primary and clipbaord
Just allow user to set the behavior with some foot switch.
Re: [dev] st: selecting text affects both primary and clipbaord
On Fri, Feb 20, 2015, at 12:38, sta...@cs.tu-berlin.de wrote: * k...@shike2.com 2015-02-20 17:39 I agree here, it shouldn't modiy the CLIPBOARD seletction. Sometime is good to have different things in both selections. If nobady claims about it I will apply your patch. I'd leave it as is, in order not to break scrips which expect to read something from CLIPBOARD. In other programms, you might have the choice to send something to selection or CLIPBOARD by different means. In st, however, you don't. Thus, the current behaviour seems to me more consistent and intuitive. Another reason to leave it as-is is that, while in other applications it is reasonable to select text for some purpose other than copying it (e.g. to delete it or replace it), people will not want their clipboard obliterated in this case. However, in a terminal emulator, the only thing you can do with selected text is copy it. PuTTY on MS Windows puts selected text immediately in the clipboard and apparently no-one has ever objected to this behavior - if anyone had I'm sure they would have added it to the dozens of configurable options it already has.
Re: [dev] st: selecting text affects both primary and clipbaord
* Greg Reagle 2015-02-20 20:07 It is true that the only reason I select text in st is to copy it, but I still don't want it clobbering my clipboard. does the current behaviour break some scripts or habits of yours and how?
Re: [dev] st: selecting text affects both primary and clipbaord
On Fri, Feb 20, 2015, at 01:50 PM, random...@fastmail.us wrote: Another reason to leave it as-is is that, while in other applications it is reasonable to select text for some purpose other than copying it (e.g. to delete it or replace it), people will not want their clipboard obliterated in this case. However, in a terminal emulator, the only thing you can do with selected text is copy it. It is true that the only reason I select text in st is to copy it, but I still don't want it clobbering my clipboard. The only reason I select text in xterm is to copy it, and I appreciate that doing so only affects the primary selection. That is the way well behaved X applications are supposed to work. PuTTY on MS Windows puts selected text immediately in the clipboard and apparently no-one has ever objected to this behavior - if anyone had I'm sure they would have added it to the dozens of configurable options it already has. Putty on MS Windows is not an X application. As far as I know, Windows has only one selection (to use the X terminology): the clipboard. So I don't see the point of comparing it. -- http://www.fastmail.com - Access all of your messages and folders wherever you are
Re: [dev] st: selecting text affects both primary and clipbaord
having more than one buffer is just annoying, and there are no well behaved X applications anyways.
Re: [dev] st: selecting text affects both primary and clipbaord
On Fri, Feb 20, 2015, at 02:18 PM, sta...@cs.tu-berlin.de wrote: * Greg Reagle 2015-02-20 20:07 It is true that the only reason I select text in st is to copy it, but I still don't want it clobbering my clipboard. does the current behaviour break some scripts or habits of yours and how? No scripts, but habit--yes. I am in the habit of using the clipboard and primary selections independently, carrying different data in them. I moved from xterm to st. But it's not just xterm, *no other program* I use sets the clipboard from merely selecting text, and there is good reason for this. I have applied the patch posted to the list recently, so that st behaves in the way that I like. It is no longer causing me any trouble. It is still my opinion that the default behavior of st should change, but that's just my opinion. It would be nice to at least to have the patch included at http://st.suckless.org/patches/. -- http://www.fastmail.com - Access all of your messages and folders wherever you are
[dev] st: selecting text affects both primary and clipbaord
When I select text in st using the mouse, it sets both the primary selection and the clipboard selection. It should only set the primary selection. The clipboard is supposed to be only for explicitly requested copying. From http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt: Application authors should follow the following guidelines to get correct behavior: - selecting but with no explicit copy should only set PRIMARY, never CLIPBOARD -- http://www.fastmail.com - IMAP accessible web-mail
Re: [dev] st: selecting text affects both primary and clipbaord
On Fri, Feb 20, 2015 at 12:46:20AM +0100, Wander Nauta wrote: Hello list, I know this isn't a democracy, but I agree with Greg, it makes more sense to only set PRIMARY, not CLIPBOARD, in selcopy. Removing the clipboard-related lines from xsetsel seems to do the trick. I've attached a patch that does just that. Huh? I always used S-Insert when pasting something selected on st so I never noticed that it also sent to CLIPBOARD, got pretty surprised by this behaviour.
Re: [dev] st: selecting text affects both primary and clipbaord
Hello list,
I know this isn't a democracy, but I agree with Greg, it makes more
sense to only set PRIMARY, not CLIPBOARD, in selcopy. Removing the
clipboard-related lines from xsetsel seems to do the trick. I've
attached a patch that does just that.
Cheers,
Wander
On Thu, Feb 19, 2015 at 10:30 PM, Greg Reagle greg.rea...@umbc.edu wrote:
When I select text in st using the mouse, it sets both the primary
selection and the clipboard selection. It should only set the primary
selection. The clipboard is supposed to be only for explicitly
requested copying.
From
http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt:
Application authors should follow the following guidelines to get
correct behavior:
- selecting but with no explicit copy should only set PRIMARY,
never CLIPBOARD
--
http://www.fastmail.com - IMAP accessible web-mail
From 7552a9358aecd38006cdbcff61491ae8e713aa13 Mon Sep 17 00:00:00 2001
From: Wander Nauta i...@wandernauta.nl
Date: Fri, 20 Feb 2015 00:36:48 +0100
Subject: [PATCH] Don't clobber CLIPBOARD
---
st.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/st.c b/st.c
index b9d30a7..5af4dc2 100644
--- a/st.c
+++ b/st.c
@@ -1080,16 +1080,9 @@ selrequest(XEvent *e) {
void
xsetsel(char *str) {
- /* register the selection for both the clipboard and the primary */
- Atom clipboard;
-
free(sel.clip);
sel.clip = str;
-
XSetSelectionOwner(xw.dpy, XA_PRIMARY, xw.win, CurrentTime);
-
- clipboard = XInternAtom(xw.dpy, CLIPBOARD, 0);
- XSetSelectionOwner(xw.dpy, clipboard, xw.win, CurrentTime);
}
void
--
2.3.0
Re: [dev] st: selecting text affects both primary and clipbaord
Greg Reagle said: - selecting but with no explicit copy should only set PRIMARY, never CLIPBOARD FWIW in suckless context selecting _is_ explicit copy. -- Dmitrij D. Czarkoff
