select-active-regions

select-active-regions

[Eli Zaretskii]

When making changes like these:

    2009-07-17  David De La Harpe Golden  <david@harpegolden.net>

	    * w32-fns.el (x-selection-owner-p): New function.

	    * mouse.el (mouse-drag-track): Call deactivate-mark earlier.
	    (mouse-yank-at-click, mouse-yank-primary): If
	    select-active-regions is non-nil, deactivate the mark before
	    insertion.

	    * simple.el (deactivate-mark, set-mark): Only save selection if we
	    own it.

please do not forget that the MS-DOS port of Emacs also supports the
mouse and the clipboard.  These changes broke it because
x-selection-owner-p was not defined.

By the way, I don't think x-selection-owner-p, as defined on
w32-fns.el, is correct: If I set select-active-regions non-nil on
Windows, the active region does not get put into the clipboard.  Isn't
that the intent of this feature?

Re: select-active-regions

[David De La Harpe Golden]

Eli Zaretskii wrote:


> please do not forget that the MS-DOS port of Emacs also supports the
> mouse and the clipboard.  These changes broke it because
> x-selection-owner-p was not defined.
> 

Apologies.  Chong Yidong had already had to point out to me that it 
broke w32, but w32 was already internally faking a primary:
In general, enabling select-active-regions at all on platforms that 
don't have a true primary selection may not make an immense amount of 
sense, but if they're internally emulating as w32 was it does make some 
sense.

I see your fix to lisp/term/pc-win.el , but it is not doing the right 
thing as far as I can see (no way for me to test. Well
I suppose I could install FreeDOS, but I'm not aware of a free w16 layer 
for it).  If w16 has no OS-level concept of primary (I very much doubt 
it does, though I can't say I'm familiar with it), then:

(x-set-selection 'PRIMARY value)
;should just stash value somewhere, w32 was putting it as a property
; on a symbol x-selections.  Aside: w32 could maybe do something
; sensible for (x-set-selection 'CLIPBOARD value)

(x-get-selection 'PRIMARY)
; should just return the stashed value.

(x-selection-owner-p 'PRIMARY)
;should just return true once value has been set.

Your pc-win.el x-selection-owner-p code would be more appropriate for 
'CLIPBOARD code paths, I think, since apparently w16 has a clipboard.


> By the way, I don't think x-selection-owner-p, as defined on
> w32-fns.el, is correct: If I set select-active-regions non-nil on
> Windows, the active region does not get put into the clipboard.  Isn't
> that the intent of this feature?

No, definitely not! It was intended to be put on _primary_, which is 
distinct from clipboard and doesn't have an analogue on windows (well, I 
speculate that it might be now possible to partially fake it with w32 
accessibility APIs).

It would _possible_ to offer a customization option to say where to put 
it, one of the early rejected iterations of the patchset in fact did so 
IIRC, but that was not the original idea of select-active-regions and 
would very probably confuse most people - would be an unusual and 
nonstandard use of a clipboard, whereas mirroring the active region in 
primary is a pretty normal thing to want to do.

Re: select-active-regions

[David De La Harpe Golden]

David De La Harpe Golden wrote:

> Apologies.  Chong Yidong had already had to point out to me that it 
> broke w32, but w32 was already internally faking a primary:
> In general, enabling select-active-regions at all on platforms that 
> don't have a true primary selection may not make an immense amount of 
> sense, but if they're internally emulating as w32 was it does make some 
> sense.
> 

argh. every instance of w32 above should read "w32 emacs" for clarity.

"
Apologies.  Chong Yidong had already had to point out to me that it
broke w32 emacs, but w32 emacs was already internally faking a primary:

In general, enabling select-active-regions at all on platforms that
don't have a true primary selection may not make an immense amount of
sense, but if they're internally emulating as w32 emacs was it does make 
some sense.
"

Re: select-active-regions

[Eli Zaretskii]

> Date: Sat, 18 Jul 2009 14:41:10 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: emacs-devel@gnu.org
> 
> In general, enabling select-active-regions at all on platforms that 
> don't have a true primary selection may not make an immense amount of 
> sense

Why not? they should put the region text into the clipboard instead,
IMO.

> I see your fix to lisp/term/pc-win.el , but it is not doing the right 
> thing as far as I can see (no way for me to test. Well
> I suppose I could install FreeDOS, but I'm not aware of a free w16 layer 
> for it).  If w16 has no OS-level concept of primary (I very much doubt 
> it does, though I can't say I'm familiar with it), then:
> 
> (x-set-selection 'PRIMARY value)
> ;should just stash value somewhere

What would be the purpose of stashing the value ``somewhere''?  The
NEWS entry says:

    *** If `select-active-regions' is t, setting the mark automatically
    makes the new region into the primary selection (for interaction with
    other window applications).

How can Emacs interact with other applications, if we just stash the
value in some internal variable?

How about if you explain (in more detail than available in the current
documentation) what this feature is supposed to do, and which
use-cases it is supposed to support?  Maybe then I will be able to see
why my code in pc-win.el is wrong.

Re: select-active-regions

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> How about if you explain (in more detail than available in the current
> documentation) what this feature is supposed to do, and which
> use-cases it is supposed to support?  Maybe then I will be able to see
> why my code in pc-win.el is wrong.

In most applications on X, if you shift-select a stretch of text, that
text is copied into PRIMARY, and you can paste it into other
applications with a middle click.  That's what select-active-regions is
supposed to do, except it covers all cases where the text is highlighted
and not just shift selection (e.g., with transient mark mode enabled, if
you do C-SPC and move the cursor to create an active region, the region
should be available as PRIMARY).

Re: select-active-regions

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: David De La Harpe Golden <david@harpegolden.net>,  emacs-devel@gnu.org
> Date: Sat, 18 Jul 2009 10:19:04 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How about if you explain (in more detail than available in the current
> > documentation) what this feature is supposed to do, and which
> > use-cases it is supposed to support?  Maybe then I will be able to see
> > why my code in pc-win.el is wrong.
> 
> In most applications on X, if you shift-select a stretch of text, that
> text is copied into PRIMARY, and you can paste it into other
> applications with a middle click.  That's what select-active-regions is
> supposed to do, except it covers all cases where the text is highlighted
> and not just shift selection (e.g., with transient mark mode enabled, if
> you do C-SPC and move the cursor to create an active region, the region
> should be available as PRIMARY).

That's what I thought it should do.

Now, why would it be wrong to translate this to mean that the
shift-selected stretch of text be copied to the Windows clipboard?

And why would it be TRT to translate this to the emulation of PRIMARY
we have on w32-fns.el?  The latter, AFAICS, only emulates PRIMARY for
Emacs itself, not for the other applications.

TIA

Re: select-active-regions

[David De La Harpe Golden]

[-- Attachment #1: Type: text/plain, Size: 2630 bytes --]

Eli Zaretskii wrote:

>> (x-set-selection 'PRIMARY value)
>> ;should just stash value somewhere
> 
> What would be the purpose of stashing the value ``somewhere''? 

The purpose is to emulate internally to emacs a primary selection 
facility otherwise missing from the platform in question. w32 emacs 
looks to have been treating the primary selection that way for the past 
13 years or so.
http://cvs.savannah.gnu.org/viewvc/emacs/lisp/w32-fns.el?revision=1.14&root=emacs&view=markup

On recent w32 it might now be possible to use an accessibility API (at 
least with sufficient privileges) to record  selections in some other 
applications, which might allow a closer to complete emulation of at 
least incoming primary, though it might be tricksy to actually implement 
and not especially worth it.

> The
> NEWS entry says:
> 
>     *** If `select-active-regions' is t, setting the mark automatically
>     makes the new region into the primary selection (for interaction with
>     other window applications).
>

Uh-huh. Note how it also says "makes the new region into the primary 
selection"  ?

> How can Emacs interact with other applications, if we just stash the
> value in some internal variable?
> 

Not all platforms have a primary selection as an OS-level entity in the 
first place, they only have a clipboard (well, the amiga actually had 
hundreds of distinct clipboards, but I'm not sure amiga support is worth 
worrying about even though AROS now exists), so emacs just has to 
interact with them via means other than a primary selection.  But mixing 
up primary and clipboard within 
x-set-selection/x-get-selection/x-selection-owner-p is wrong not
to mention phenomenally confusing.

Waht's more, I suspect it also Just Won't Work Anyway, because on w32 
AFAIK you set the system clipboard, on x11 you acquire the clipboard 
selection and applications ask you for the clipboard contents.  Perhaps 
just regard select-active-regions as a feature aimed mostly at X11 users...

If you do want select-active-regions to be able to affect the clipboard, 
a relatively sane way to do it would be to introduce customization 
variables:

x-select-active-regions-enable-clipboard 
x-select-active-regions-enable-primary

by analogy with x-select-enable-primary and x-select-enable-clipboard,
that would allow customization of which selections to actually affect 
during select-active-regions.   Note that x-select-enable-primary and 
x-select-enable-clipboard would be completely UNsuitable for reuse 
there, if you don't see why you probably haven't quite understood the issue.

See attached (illstrative) patch.





[-- Attachment #2: select-active-regions_allowclip_r1.diff --]
[-- Type: text/x-patch, Size: 5511 bytes --]

Index: lisp/simple.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/simple.el,v
retrieving revision 1.995
diff -U 8 -r1.995 simple.el
--- lisp/simple.el	18 Jul 2009 04:37:56 -0000	1.995
+++ lisp/simple.el	18 Jul 2009 18:43:58 -0000
@@ -3468,35 +3468,55 @@
 
 If you are using this in an editing command, you are most likely making
 a mistake; see the documentation of `set-mark'."
   (if (or force (not transient-mark-mode) mark-active mark-even-if-inactive)
       (marker-position (mark-marker))
     (signal 'mark-inactive nil)))
 
 (defcustom select-active-regions nil
-  "If non-nil, an active region automatically becomes the window selection."
+  "If non-nil, an active region automatically becomes the window selection.
+Which selections are actually affected is determined by the
+`x-select-active-regions-enable-primary' and
+`x-select-active-regions-enable-clipboard' variables -
+if unbound or nil, that selection will be unaffected.
+may be poorly supported on windowing systems other than X11
+due to basic windowing system architectural differences."
   :type 'boolean
   :group 'killing
   :version "23.1")
 
+(defsubst select-active-regions--start ()
+  (and (bound-and-true-p x-select-active-regions-enable-primary)
+       (x-set-selection 'PRIMARY (current-buffer)))
+  (and (bound-and-true-p x-select-active-regions-enable-clipboard)
+       (x-set-selection 'CLIPBOARD (current-buffer))))
+
+(defsubst select-active-regions--end ()
+  (and (bound-and-true-p x-select-active-regions-enable-primary)
+       (x-selection-owner-p 'PRIMARY)
+       (x-set-selection 'PRIMARY (buffer-substring-no-properties
+				  (region-beginning) (region-end))))
+  (and (bound-and-true-p x-select-active-regions-enable-clipboard)
+       (x-selection-owner-p 'CLIPBOARD)
+       (x-set-selection 'CLIPBOARD (buffer-substring-no-properties
+				    (region-beginning) (region-end)))))
+
 ;; Many places set mark-active directly, and several of them failed to also
 ;; run deactivate-mark-hook.  This shorthand should simplify.
 (defsubst deactivate-mark (&optional force)
   "Deactivate the mark by setting `mark-active' to nil.
 Unless FORCE is non-nil, this function does nothing if Transient
 Mark mode is disabled.
 This function also runs `deactivate-mark-hook'."
   (when (or transient-mark-mode force)
     ;; Copy the latest region into the primary selection, if desired.
     (and select-active-regions
 	 mark-active
-	 (x-selection-owner-p 'PRIMARY)
-	 (x-set-selection 'PRIMARY (buffer-substring-no-properties
-				    (region-beginning) (region-end))))
+	 (select-active-regions--end))
     (if (and (null force)
 	     (or (eq transient-mark-mode 'lambda)
 		 (and (eq (car-safe transient-mark-mode) 'only)
 		      (null (cdr transient-mark-mode)))))
 	;; When deactivating a temporary region, don't change
 	;; `mark-active' or run `deactivate-mark-hook'.
 	(setq transient-mark-mode nil)
       (if (eq (car-safe transient-mark-mode) 'only)
@@ -3506,17 +3526,17 @@
 
 (defun activate-mark ()
   "Activate the mark."
   (when (mark t)
     (setq mark-active t)
     (unless transient-mark-mode
       (setq transient-mark-mode 'lambda))
     (when select-active-regions
-      (x-set-selection 'PRIMARY (current-buffer)))))
+      (select-active-regions--start))))
 
 (defun set-mark (pos)
   "Set this buffer's mark to POS.  Don't use this function!
 That is to say, don't use this function unless you want
 the user to see that the mark has moved, and you want the previous
 mark position to be lost.
 
 Normally, when a new mark is set, the old one should go on the stack.
@@ -3530,17 +3550,17 @@
 
    (let ((beg (point))) (forward-line 1) (delete-region beg (point)))."
 
   (if pos
       (progn
 	(setq mark-active t)
 	(run-hooks 'activate-mark-hook)
 	(when select-active-regions
-	  (x-set-selection 'PRIMARY (current-buffer)))
+	  (select-active-regions--start))
 	(set-marker (mark-marker) pos (current-buffer)))
     ;; Normally we never clear mark-active except in Transient Mark mode.
     ;; But when we actually clear out the mark value too, we must
     ;; clear mark-active in any mode.
     (deactivate-mark t)
     (set-marker (mark-marker) nil)))
 
 (defcustom use-empty-active-region nil
Index: lisp/term/x-win.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/term/x-win.el,v
retrieving revision 1.240
diff -U 8 -r1.240 x-win.el
--- lisp/term/x-win.el	19 Mar 2009 00:56:52 -0000	1.240
+++ lisp/term/x-win.el	18 Jul 2009 18:43:58 -0000
@@ -1243,16 +1243,26 @@
   :type 'boolean
   :group 'killing)
 
 (defcustom x-select-enable-primary t
   "Non-nil means cutting and pasting uses the primary selection."
   :type 'boolean
   :group 'killing)
 
+(defcustom x-select-active-regions-enable-clipboard nil
+  "Non-nil means `select-active-regions' uses the clipboard"
+  :type 'boolean
+  :group 'killing)
+
+(defcustom x-select-active-regions-enable-primary t
+  "Non-nil means `select-active-regions' uses the primary selection."
+  :type 'boolean
+  :group 'killing)
+
 (defun x-select-text (text &optional push)
   "Make TEXT, a string, the primary X selection.
 Also, set the value of X cut buffer 0, for backward compatibility
 with older X applications.
 gildea@stop.mail-abuse.org says it's not desirable to put kills
 in the clipboard."
   ;; With multi-tty, this function may be called from a tty frame.
   (when (eq (framep (selected-frame)) 'x)

Re: select-active-regions

[David De La Harpe Golden]

Eli Zaretskii wrote:

> Now, why would it be wrong to translate this to mean that the
> shift-selected stretch of text be copied to the Windows clipboard?
> 

Because the windows clipboard is analogous to the X11 clipboard, not
the X11 primary.

Re: select-active-regions

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> Now, why would it be wrong to translate this to mean that the
> shift-selected stretch of text be copied to the Windows clipboard?

In Windows applications, shift-selecting a stretch of text does not copy
it to the clipboard.  (Nor does it do so on X.)

Re: select-active-regions

[Eli Zaretskii]

> Date: Sat, 18 Jul 2009 14:41:10 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> 
> 
> > please do not forget that the MS-DOS port of Emacs also supports the
> > mouse and the clipboard.  These changes broke it because
> > x-selection-owner-p was not defined.
> > 
> 
> Apologies.  Chong Yidong had already had to point out to me that it 
> broke w32

It also broke the text terminal configuration.  (I think I fixed it.)
The general rule is: never invoke any selection-related operations
without testing first what display-selections-p returns.

Re: select-active-regions

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: david@harpegolden.net, emacs-devel@gnu.org
> Date: Sat, 18 Jul 2009 14:51:19 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Now, why would it be wrong to translate this to mean that the
> > shift-selected stretch of text be copied to the Windows clipboard?
> 
> In Windows applications, shift-selecting a stretch of text does not copy
> it to the clipboard.

Some application do, and I like it.  PuTTY (the Windows SSH client) is
one example.

Re: select-active-regions

[Eli Zaretskii]

> Date: Sat, 18 Jul 2009 19:48:14 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> Cc: Chong Yidong <cyd@stupidchicken.com>, emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> 
> > Now, why would it be wrong to translate this to mean that the
> > shift-selected stretch of text be copied to the Windows clipboard?
> > 
> 
> Because the windows clipboard is analogous to the X11 clipboard, not
> the X11 primary.

The Windows clipboard is also analogous to the X11 primary selection,
in that copy/paste work on Windows through the clipboard.

In other words, when there's only one interprogram buffer to put
selected text, it is analogous to all the X selection facilities.

Anyway, I'm unconvinced.  The MS-DOS port will copy to the clipboard
under select-active-regions.  For the w32 build, I'd like to hear
other maintainers who work on the w32 build, but my opinion is that it
should do that as well.

Re: select-active-regions

[Eli Zaretskii]

> Date: Sat, 18 Jul 2009 19:45:54 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: emacs-devel@gnu.org
> 
> w32 emacs looks to have been treating the primary selection that way
> for the past 13 years or so.
> http://cvs.savannah.gnu.org/viewvc/emacs/lisp/w32-fns.el?revision=1.14&root=emacs&view=markup

Only because, up until now, it was sufficient: the default (on w32) of
copy/paste through the clipboard made Emacs behave as it does on X,
more or less.

Re: select-active-regions

[David De La Harpe Golden]

Eli Zaretskii wrote:

> It also broke the text terminal configuration.  (I think I fixed it.)

Thanks.

> The general rule is: never invoke any selection-related operations
> without testing first what display-selections-p returns.
> 

Yup, should have been doing that all along.

Re: select-active-regions

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Now, why would it be wrong to translate this to mean that the
>> > shift-selected stretch of text be copied to the Windows clipboard?
>>
>> In Windows applications, shift-selecting a stretch of text does not copy
>> it to the clipboard.
>
> Some application do, and I like it.  PuTTY (the Windows SSH client) is
> one example.

That's surely wildly non-standard behavior.  My impression is that the
clipboard, on both X and Windows, is meant to have a certain amount of
"stability".  Text selection can occur very frequently---in Windows, for
instance, just left-clicking on the Firefox address bar selects the text
in the bar---and you don't want to clobber the clipboard for that.

Re: select-active-regions

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: david@harpegolden.net, emacs-devel@gnu.org
> Date: Sat, 18 Jul 2009 15:37:15 -0400
> 
> My impression is that the clipboard, on both X and Windows, is meant
> to have a certain amount of "stability".

Not when you use Emacs, which puts text into clipboard on every kill.

> Text selection can occur very frequently---in Windows, for
> instance, just left-clicking on the Firefox address bar selects the text
> in the bar---and you don't want to clobber the clipboard for that.

This is an optional feature; if the user enables it, she ought to know
what she is doing.

The alternative (what the current code does on w32) is to disable this
feature on DOS and Windows entirely, with no user-level way of having
it, even as an approximation to what we have on X.  This alternative
sounds much worse to me.

Re: select-active-regions

[David De La Harpe Golden]

Eli Zaretskii wrote:

> The Windows clipboard is also analogous to the X11 primary selection,
> in that copy/paste work on Windows through the clipboard.


copy/paste doesn't work on X11 through the primary selection.

> In other words, when there's only one interprogram buffer to put
> selected text, it is analogous to all the X selection facilities.
> 
> Anyway, I'm unconvinced.  The MS-DOS port will copy to the clipboard
> under select-active-regions. 

Shrug. I then strongly recommend the approach taken is to create the
x-select-active-regions-enable-primary and
x-select-active-regions-enable-clipboard variable I just proposed
elsepost, and set ..-enable-clipboard  to t on msdos, rather than 
mysteriously conflating primary and clipboard within 
x-set-selection/x-get-selection/x-selection-owner-p
for no good reason.

> For the w32 build, I'd like to hear
> other maintainers who work on the w32 build, but my opinion is that it
> should do that as well.


w32 doesn't change the meaning of passing 'PRIMARY vs. 'CLIPBOARD to
x-set-selection/x-get-selection/x-selection-owner-p , it
just sets x-select-enable-clipboard to t  so that killing and yanking
uses the clipboard.

Similarly, it could set the proposed 
x-select-active-regions-enable-clipboard
to t by default if you wanted select-active-regions to affect the
clipboard by default.

Re: select-active-regions

[David De La Harpe Golden]

Eli Zaretskii wrote:


> Not when you use Emacs, which puts text into clipboard on every kill.
> 

Select-active-regions is essentially not intended to be such an 
operation though, it quite deliberately avoids placing text on the 
kill-ring or clipboard on x11 and ONLY sets primary.

You're muddling mouse-drag-copy-region and select-active-regions I 
think. The former affects the kill ring, and typically though not 
necessarily, x11 select-active-regions users would actually turn off 
mouse-drag-copy-region as what they probably want is:

* keyboard and mouse selection and mouse middle click involves ONLY primary

* keyboard/menu/toolbar kill/kill-ring-save/yank (... cut/copy/paste),
involves ONLY kill-ring_and_clipboard.

Why do they want that? Because it's how quite a lot of other X11 apps 
work nowadays, if you assume the kill-ring is analogous to an extended 
clipboard (as e.g. cua-mode clearly assumes when it does its binding 
trickery).  The point was for emacs to optionally (optionally!) support 
such behaviour, with the following:

(setq x-select-enable-clipboard t)
(setq x-select-enable-primary nil)
(setq mouse-drag-copy-region nil)
(setq select-active-regions t)
(global-set-key [mouse-2] 'mouse-yank-primary)

If you also want C-x/C-c/C-v bindings, you of course also turn on cua-mode.

Re: select-active-regions

[Jason Rumney]

Eli Zaretskii wrote:
> The Windows clipboard is also analogous to the X11 primary selection,
> in that copy/paste work on Windows through the clipboard.
>   
No, it is not analogous to the X11 primary selection, as the X11 primary 
selection does not clobber the clipboard as any emulation of primary 
selections using the clipboard necessarily would.


> Anyway, I'm unconvinced.  The MS-DOS port will copy to the clipboard
> under select-active-regions.  For the w32 build, I'd like to hear
> other maintainers who work on the w32 build, but my opinion is that it
> should do that as well.
>   

IIRC, Emacs on w32 used to emulate primary selections in the way you 
describe, but it triggered many bug reports about Emacs destroying 
clipboard contents when the user selected text in Emacs for reasons 
other than killing or copying the region.

Re: select-active-regions

[Eli Zaretskii]

> Date: Sun, 19 Jul 2009 22:41:34 +0800
> From: Jason Rumney <jasonr@gnu.org>
> CC: David De La Harpe Golden <david@harpegolden.net>, 
>  cyd@stupidchicken.com, emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > The Windows clipboard is also analogous to the X11 primary selection,
> > in that copy/paste work on Windows through the clipboard.
> >   
> No, it is not analogous to the X11 primary selection, as the X11 primary 
> selection does not clobber the clipboard as any emulation of primary 
> selections using the clipboard necessarily would.

It's analogous in the sense that killing puts text there and yanking
gets text from there.

> IIRC, Emacs on w32 used to emulate primary selections in the way you 
> describe, but it triggered many bug reports about Emacs destroying 
> clipboard contents when the user selected text in Emacs for reasons 
> other than killing or copying the region.

Any pointers to these bug reports?  I'm just curious what got people
annoyed.

Anyway, do you think it is better to have this feature effectively
disabled on Windows, than copy into the clipboard?

Re: select-active-regions

[David De La Harpe Golden]

Eli Zaretskii wrote:

> It's analogous in the sense that killing puts text there and yanking
> gets text from there.
> 


When killing, emacs on X11 places text in
primary if x-select-enable-primary is t
clipboard if x-select-enable-clipboard is t

When yanking, emacs on x11 gets text from
primary if x-select-enable-primary is t
clipboard if x-select-enable-clipboard is t

(They could maybe be decoupled into incoming and outgoing settings, but 
that's another story...)

So on X11, I:
set x-select-enable-primary to nil
set x-select-enable-clipboard to t
set select-active-regions to t, so that the active region is sent to 
primary.

Now, not all x11 emacs users like that convention, but that's why x11 
emacs supports several. I can set things to my liking as above, and all 
without screwing up things for other emacs users.

I don't see why, if for some reason I was using msdos/w16 or w32 emacs 
(not especially likely for me personally, yay for windows' near total 
lack of penetration into HPC, but anyway), the native port there 
shouldn't be able to emulate the convention I like as best it can.

i.e. If I'm used to select-active-regions working without clobbering the 
clipboard on X11, why the holy hell should it clobber the clipboard on 
Windows? Presumably only self-self primary interactions will work on 
Windows since emacs emulates primary internally, but they do constitute 
a distinctly nonzero proportion of my primary interactions.


 > Anyway, do you think it is better to have this feature effectively
 > disabled on Windows, than copy into the clipboard?

You've missed the option of having it work as on x11 for emacs-emacs 
interactions (that is _not_ "effectively disabled") but not copying to 
the clipboard.  I don't know why, other than the possibility you've 
misunderstood some or all of X11 clipboard, X11 primary, or the purpose 
of select-active-regions.

I'm not sure if emacs w32 works under wine, but if it does I can try to 
look at:

(a) making it customizable whether select-active-regions hits the 
clipboard and/or primary (already sent a patch that does that...)

(b) look at using an idle timer hack or something on w32 to make it in 
fact work right all if told to hit the w32 clipboard (I presently think 
it will break or at best correspond to pre-bug-#902-fix incorrect 
behaviour without attention there). (not quite trivial)

(c) do so in a manner that _doesn't_ preclude w32's primary emulation 
being improved in future.

Re: select-active-regions

[Eli Zaretskii]

> Date: Sun, 19 Jul 2009 20:36:21 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: Jason Rumney <jasonr@gnu.org>, cyd@stupidchicken.com, 
>  emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> 
> > It's analogous in the sense that killing puts text there and yanking
> > gets text from there.
> > 
> 
> 
> When killing, emacs on X11 places text in
> primary if x-select-enable-primary is t
> clipboard if x-select-enable-clipboard is t
> 
> When yanking, emacs on x11 gets text from
> primary if x-select-enable-primary is t
> clipboard if x-select-enable-clipboard is t

Since Windows only has the clipboard, putting and getting text from
there is the best it can do to emulate X in this regard.

> i.e. If I'm used to select-active-regions working without clobbering the 
> clipboard on X11, why the holy hell should it clobber the clipboard on 
> Windows?

As I explained elsewhere in this thread, Emacs on DOS and Windows
thrashes the clipboard all the time anyway.  So anyone using Emacs on
Windows ought to be accustomed to that already.  I know I am.

> You've missed the option of having it work as on x11 for emacs-emacs 
> interactions (that is _not_ "effectively disabled") but not copying to 
> the clipboard.

If we want such an option to be available to non-X platforms, we
should let users customize it in ways that are not specific to X.
What we have now in that area is horribly system-dependent.  Introduce
a portable customizable option for separating these two features, and
I'm with you.

> I don't know why, other than the possibility you've 
> misunderstood some or all of X11 clipboard, X11 primary, or the purpose 
> of select-active-regions.

Well, I did ask for a detailed explanation.

Re: select-active-regions

[Lennart Borgman]

On Sun, Jul 19, 2009 at 10:20 PM, Eli Zaretskii<eliz@gnu.org> wrote:
>
> As I explained elsewhere in this thread, Emacs on DOS and Windows
> thrashes the clipboard all the time anyway.  So anyone using Emacs on
> Windows ought to be accustomed to that already.  I know I am.

I have never noticed that problem. It might be because I use Viper and
the vi cut, copy and paste operations are structured like the CUA
dito. Everyone expect CUA operations to use the clipboard and Viper/vi
uses it the same way. It would be quite annoying if that was broken.

Re: select-active-regions

[David De La Harpe Golden]

Eli Zaretskii wrote:

 > > When killing, emacs on X11 places text in
 > > primary if x-select-enable-primary is t
 > > clipboard if x-select-enable-clipboard is t
 > >
 > > When yanking, emacs on x11 gets text from
 > > primary if x-select-enable-primary is t
 > > clipboard if x-select-enable-clipboard is t

> Since Windows only has the clipboard, putting and getting text from
> there is the best it can do to emulate X in this regard.
>

For emulating an X11 clipboard, sure, that makes sense. Not for 
emulating an X11 primary.  They are different things.  And "in this 
regard" in the above is really in regard to killing and yanking, not
select-active-regions...

 > As I explained elsewhere in this thread, Emacs on DOS and Windows
 > thrashes the clipboard all the time anyway.  So anyone using Emacs on
 > Windows ought to be accustomed to that already.  I know I am.

? Surely it only updates the system clipboard if you:
  * explicitly kill
  * {mouse-select text with mouse-drag-copy-region non-nil}

Normally though not necessarily, people who (setq select-active-regions 
t) would  (setq mouse-drag-copy-region nil).

A basic point of select-active-regions is to allow, when selecting text 
with either the mouse or keyboard:
  * don't affect kill-ring_and_clipboard
  * affect primary

Why?
http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt
( x11 emacs users: you may or may  not agree with that spec. Please note
this is all carefully-kept-optional stuff.)

> If we want such an option to be available to non-X platforms, we
> should let users customize it in ways that are not specific to X.
> What we have now in that area is horribly system-dependent.

There's some truth in that. Funny enough, I did in fact propose various 
revised schemes in 2007/2008 era which were less x11-y but were
not eventually adopted.  IMO they tried a bit too hard to be all things 
to all people, so became quite complex, eventually a big list of sources 
and a big list of destinations for each possible interaction that you 
could plumb together with a big matrix of boolean customizations. 
Sticking to things people definitely want might keep things simpler if 
less symmetrical.

Anyway - You apparently want a select-active-regions that clobbers the 
clipboard on w32 just like it quite deliberately avoids doing on x11. 
It sounds quite horrible, but it's doable.   It's doable in a couple of 
ways:

1. the way that means it appears and works much the same on all platforms:

  1.1.  If the platform has a clipboard, allow turning on and off 
select-active-regions affecting the clipboard.
This is like the way you can turn on and off kill and yank affecting the 
clipboard on both x11 and w32.

  1.2.  If the platform has  a primary, allow turning on and off 
select-active-regions affecting the primary
This is like the way you can turn on and off kill and yank affecting
the primary on x11.

2. and the way that makes an unnecessary mess
  2.1. confuse clipboards and primaries at a deep level.

I recommend 1.

w32 presently uses x-select-enable-clipboard to control clipboard use 
AFAICS with much the same meaning as on x11.  Yes it says "x-select-", 
but it probably should really be called 
"kill-and-yank-both-use-clipboard" given what it actually does on both 
platforms (AFAICS in the w32 case, since I haven't run it yet)

Anyway, an x-select-active-regions-enable-clipboard boolean 
customization could similarly control use of clipboard, only for 
select-active-regions not kill-and-yank, on w32 or x11.  Can call it 
select-active-regions-enable-clipboard if you want to avoid "x-"

 > Introduce  a portable customizable option for separating these
 > two features, and I'm with you.

It might take a few days for me at least to come up with something
that actually works on w32, because of "lazy vs. eager" (not me,
the clipboard semantics).

> Well, I did ask for a detailed explanation.

select-active-regions arranges to make primary correspond to the 
contents of the active region while the region is active. That's
what it's for.

Re: select-active-regions

[Eli Zaretskii]

> Date: Mon, 20 Jul 2009 01:22:20 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: jasonr@gnu.org, cyd@stupidchicken.com, emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> 
>  > > When killing, emacs on X11 places text in
>  > > primary if x-select-enable-primary is t
>  > > clipboard if x-select-enable-clipboard is t
>  > >
>  > > When yanking, emacs on x11 gets text from
>  > > primary if x-select-enable-primary is t
>  > > clipboard if x-select-enable-clipboard is t
> 
> > Since Windows only has the clipboard, putting and getting text from
> > there is the best it can do to emulate X in this regard.
> >
> 
> For emulating an X11 clipboard, sure, that makes sense. Not for 
> emulating an X11 primary.  They are different things.

But Emacs has no other way but emulate both with the clipboard on
Windows, because that's the only interprogram buffer there is.

>  > As I explained elsewhere in this thread, Emacs on DOS and Windows
>  > thrashes the clipboard all the time anyway.  So anyone using Emacs on
>  > Windows ought to be accustomed to that already.  I know I am.
> 
> ? Surely it only updates the system clipboard if you:
>   * explicitly kill
>   * {mouse-select text with mouse-drag-copy-region non-nil}

Aha, and did you pay attention how many times you kill something while
editing?

> A basic point of select-active-regions is to allow, when selecting text 
> with either the mouse or keyboard:
>   * don't affect kill-ring_and_clipboard
>   * affect primary

That's fine, but you cannot do that on Windows and let other programs
get at the selected text unless you use the clipboard.

But we are going in circles.  The same arguments get said time and
again, ad nauseam.  I think we should agree to disagree on this one,
and let it be.

> w32 presently uses x-select-enable-clipboard to control clipboard use 
> AFAICS with much the same meaning as on x11.

Not really: x-select-enable-clipboard is t by default on Windows,
because it won't make much sense otherwise.

Re: select-active-regions

[Eli Zaretskii]

> Date: Sun, 19 Jul 2009 23:52:20 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: David De La Harpe Golden <david@harpegolden.net>, cyd@stupidchicken.com, emacs-devel@gnu.org, 
> 	jasonr@gnu.org
> 
> On Sun, Jul 19, 2009 at 10:20 PM, Eli Zaretskii<eliz@gnu.org> wrote:
> >
> > As I explained elsewhere in this thread, Emacs on DOS and Windows
> > thrashes the clipboard all the time anyway.  So anyone using Emacs on
> > Windows ought to be accustomed to that already.  I know I am.
> 
> I have never noticed that problem. It might be because I use Viper and
> the vi cut, copy and paste operations are structured like the CUA
> dito. Everyone expect CUA operations to use the clipboard and Viper/vi
> uses it the same way. It would be quite annoying if that was broken.

This is a misunderstanding: I didn't say copying to clipboard was
broken.  I said that Emacs on Windows copies text to the clipboard
very often, and so its (the clipboard's) contents is quite volatile
when Emacs is around.

Re: select-active-regions

[Lennart Borgman]

On Mon, Jul 20, 2009 at 5:15 AM, Eli Zaretskii<eliz@gnu.org> wrote:
>> Date: Sun, 19 Jul 2009 23:52:20 +0200
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Cc: David De La Harpe Golden <david@harpegolden.net>, cyd@stupidchicken.com, emacs-devel@gnu.org,
>>       jasonr@gnu.org
>>
>> On Sun, Jul 19, 2009 at 10:20 PM, Eli Zaretskii<eliz@gnu.org> wrote:
>> >
>> > As I explained elsewhere in this thread, Emacs on DOS and Windows
>> > thrashes the clipboard all the time anyway.  So anyone using Emacs on
>> > Windows ought to be accustomed to that already.  I know I am.
>>
>> I have never noticed that problem. It might be because I use Viper and
>> the vi cut, copy and paste operations are structured like the CUA
>> dito. Everyone expect CUA operations to use the clipboard and Viper/vi
>> uses it the same way. It would be quite annoying if that was broken.
>
> This is a misunderstanding: I didn't say copying to clipboard was
> broken.  I said that Emacs on Windows copies text to the clipboard
> very often, and so its (the clipboard's) contents is quite volatile
> when Emacs is around.

Yes, I thought you said that, but I have not noticed it. Maybe because
I am using a subset of the commands for those types of operation.

But then, if it is very volatile because a lot of commands are copying
to it, why not fix that?

Re: select-active-regions

[Eli Zaretskii]

> Date: Mon, 20 Jul 2009 05:20:01 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: david@harpegolden.net, cyd@stupidchicken.com, emacs-devel@gnu.org, 
> 	jasonr@gnu.org
> 
> But then, if it is very volatile because a lot of commands are copying
> to it, why not fix that?

I don't think there's anything broken here that needs to be fixed.