From unknown Sat Sep 06 02:03:51 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#7196 <7196@debbugs.gnu.org> To: bug#7196 <7196@debbugs.gnu.org> Subject: Status: 24.0.50; NEWS item "Selection changes" Reply-To: bug#7196 <7196@debbugs.gnu.org> Date: Sat, 06 Sep 2025 09:03:51 +0000 retitle 7196 24.0.50; NEWS item "Selection changes" reassign 7196 emacs submitter 7196 "Drew Adams" severity 7196 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 12 10:53:33 2010 Received: (at submit) by debbugs.gnu.org; 12 Oct 2010 14:53:33 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P5gEO-0001hv-PT for submit@debbugs.gnu.org; Tue, 12 Oct 2010 10:53:32 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P5gEN-0001hq-I2 for submit@debbugs.gnu.org; Tue, 12 Oct 2010 10:53:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P5gHi-0000AK-7I for submit@debbugs.gnu.org; Tue, 12 Oct 2010 10:56:58 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:59834) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P5gHi-0000AF-3G for submit@debbugs.gnu.org; Tue, 12 Oct 2010 10:56:58 -0400 Received: from [140.186.70.92] (port=54599 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P5gHg-0005bV-Qv for bug-gnu-emacs@gnu.org; Tue, 12 Oct 2010 10:56:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P5gHf-00009j-KB for bug-gnu-emacs@gnu.org; Tue, 12 Oct 2010 10:56:56 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]:25421) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P5gHf-00009T-EX for bug-gnu-emacs@gnu.org; Tue, 12 Oct 2010 10:56:55 -0400 Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9CEuqn7025112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Oct 2010 14:56:54 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9C2YpPQ023183 for ; Tue, 12 Oct 2010 14:56:52 GMT Received: from abhmt012.oracle.com by acsmt353.oracle.com with ESMTP id 676056091286895404; Tue, 12 Oct 2010 07:56:44 -0700 Received: from dradamslap1 (/10.159.216.47) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Oct 2010 07:56:42 -0700 From: "Drew Adams" To: Subject: 24.0.50; NEWS item "Selection changes" Date: Tue, 12 Oct 2010 07:56:40 -0700 Message-ID: <861FD1851FD742E4A821C8ECDDB11A55@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: ActqHa12S7HETJ/LROiA44OIO7tY7Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) The NEWS item is woefully incomplete. It doesn't explain much of anything about the selection changes for Emacs 24 - and they are radical changes. Among other things, NEWS should detail the differences from the previous behavior, and explain clearly how to return to the previous behavior (exactly, completely). It is not enough to just give one-liners for a few variables, such as "`x-select-enable-primary' now defaults to nil." This should be obvious. Users and user-level descriptions should come first, before implementation changes are made. In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2010-09-20 on 3249CTO Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.4) --no-opt --cflags -Ic:/imagesupport/include' From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 12 11:50:00 2010 Received: (at 7196) by debbugs.gnu.org; 12 Oct 2010 15:50:00 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P5h71-000241-WE for submit@debbugs.gnu.org; Tue, 12 Oct 2010 11:50:00 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P5h6z-00023u-Ml for 7196@debbugs.gnu.org; Tue, 12 Oct 2010 11:49:58 -0400 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9CFrMh9006083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <7196@debbugs.gnu.org>; Tue, 12 Oct 2010 15:53:24 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9CC2IwT010454 for <7196@debbugs.gnu.org>; Tue, 12 Oct 2010 15:53:21 GMT Received: from abhmt018.oracle.com by acsmt354.oracle.com with ESMTP id 676274511286898774; Tue, 12 Oct 2010 08:52:54 -0700 Received: from dradamslap1 (/10.159.229.52) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Oct 2010 08:52:53 -0700 From: "Drew Adams" To: <7196@debbugs.gnu.org> References: <861FD1851FD742E4A821C8ECDDB11A55@us.oracle.com> Subject: RE: bug#7196: 24.0.50; NEWS item "Selection changes" Date: Tue, 12 Oct 2010 08:52:52 -0700 Message-ID: <0B1CE31D4CBF4000AAC8548BF74A3CE8@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <861FD1851FD742E4A821C8ECDDB11A55@us.oracle.com> Thread-Index: ActqHa12S7HETJ/LROiA44OIO7tY7QABYGdA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: 7196 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) 1. Also, the NEWS item should make clear just what has changed for which platforms. What it says currently is incomplete and inaccurate. For example: * "`x-select-enable-clipboard' now defaults to t." That is _not_ a change for Windows - nothing new. * "`x-select-enable-primary' now defaults to nil." That variable does not even exist on Windows. Clarify that this is specific to platforms ___. 2. When saying that the new value of something is ___, you need to also say what the old value was. That's what describing a change means: saying what is new includes saying what the difference is from what was old. Users or libraries might have done something conditionally based on the old value. They need to know about the change so they can decide what to do about the new value. This is especially true for key bindings - for example, "`mouse-2' is now bound to `mouse-yank-primary'". Yes, but what was `mouse-2' bound to before? Imagine that a user or a library remapped `mouse-yank-at-click', the old default binding for `mouse-2'. If `mouse-yank-primary' is now the default binding, then the remapping is longer effective. At least make the user aware of the change, so s?he can decide whether to remap the new default command just as s?he remapped the old default command. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 07:32:34 2010 Received: (at 7196) by debbugs.gnu.org; 15 Oct 2010 11:32:34 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P6iWX-0004Xy-NE for submit@debbugs.gnu.org; Fri, 15 Oct 2010 07:32:34 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P6iWV-0004Xr-NQ for 7196@debbugs.gnu.org; Fri, 15 Oct 2010 07:32:32 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LAB00700XJDWH00@a-mtaout22.012.net.il> for 7196@debbugs.gnu.org; Fri, 15 Oct 2010 13:36:05 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.93.189]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LAB006MKXK3MLD0@a-mtaout22.012.net.il>; Fri, 15 Oct 2010 13:36:05 +0200 (IST) Date: Fri, 15 Oct 2010 13:36:04 +0200 From: Eli Zaretskii Subject: Re: bug#7196: 24.0.50; NEWS item "Selection changes" In-reply-to: <861FD1851FD742E4A821C8ECDDB11A55@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <834ocnd6xn.fsf@gnu.org> References: <861FD1851FD742E4A821C8ECDDB11A55@us.oracle.com> X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 7196 Cc: 7196@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) > From: "Drew Adams" > Date: Tue, 12 Oct 2010 07:56:40 -0700 > Cc: > > The NEWS item is woefully incomplete. It doesn't explain much of > anything about the selection changes for Emacs 24 - and they are > radical changes. > > Among other things, NEWS should detail the differences from the > previous behavior, and explain clearly how to return to the > previous behavior (exactly, completely). The new text is reproduced below. If it is good enough, this bug report can be closed. ** Selection changes. The default handling of clipboard and primary selections has been changed to conform with other X applications. The new behavior is that by default Emacs does not put text into the clipboard, and does not add it to kill-ring, merely because the text was selected. Only commands that kill text or copy it to the kill-ring (C-w, M-w, C-k, etc.) put the killed text into the clipboard. Selected text is put into the primary selection (on systems, such as X, that support the primary selection separately from the clipboard). Similarly, Emacs by default does not retrieve text from the clipboard when the mouse (e.g., mouse-2) is used for pasting text selected in another application. Text from the clipboard is retrieved only by C-y, M-y and other commands that yank text from the kill-ring. Mouse commands that paste text retrieve text from the primary selection, on systems that support it separately from the clipboard. In other words, the default behavior is that mouse gestures that select and paste text work with the primary selection, while keyboard commands that kill/copy and paste text work with the clipboard. This change also means that the "Copy", "Cut", and "Paste" items of the menu-bar "Edit" menu are now exactly equivalent to, respectively M-w, C-w, and C-y. To get back the previous behavior, whereby mouse gestures set the clipboard and retrieve text from there, customize the variables `mouse-drag-copy-region' and (on X only) `x-select-enable-primary'. If you don't want Emacs to put the text into the clipboard, only to the primary selection, additionally customize `x-select-enable-clipboard' to nil. These changes in the default behavior are reflected in the default values of several variables: *** `select-active-regions' now defaults to t, so active regions set the primary selection. It was nil in previous versions. It also accepts a new value, `only', which means to only set the primary selection for temporarily active regions (usually made by mouse-dragging or shift-selection). *** `mouse-2' is now bound to `mouse-yank-primary'. Previously, it was bound to `mouse-yank-at-click' (which is now unbound by default. *** `x-select-enable-clipboard' now defaults to t on all platforms. Thus, killing and yanking now use the clipboard (in addition to the kill ring). Note that this variable was already non-nil by default on MS-Windows, which does not support the primary selection between applications. *** `x-select-enable-primary' now defaults to nil. This variable exists only on X; its default value was t in previous versions. *** `mouse-drag-copy-region' now defaults to nil. Its previous default value was t. *** Support for X cut buffers has been removed. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 11:47:07 2010 Received: (at 7196) by debbugs.gnu.org; 15 Oct 2010 15:47:07 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P6mUs-0007Ht-D0 for submit@debbugs.gnu.org; Fri, 15 Oct 2010 11:47:06 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P6mUp-0007HW-36 for 7196@debbugs.gnu.org; Fri, 15 Oct 2010 11:47:04 -0400 Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9FFoZxR001406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Oct 2010 15:50:36 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9FFoWGX007495; Fri, 15 Oct 2010 15:50:34 GMT Received: from abhmt019.oracle.com by acsmt354.oracle.com with ESMTP id 693953721287157750; Fri, 15 Oct 2010 08:49:10 -0700 Received: from dradamslap1 (/10.159.220.39) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Oct 2010 08:49:09 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <861FD1851FD742E4A821C8ECDDB11A55@us.oracle.com> <834ocnd6xn.fsf@gnu.org> Subject: RE: bug#7196: 24.0.50; NEWS item "Selection changes" Date: Fri, 15 Oct 2010 08:49:06 -0700 Message-ID: <2875E7FCA91F426A937B145EB538F89D@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: ActsXSintqx5gMSXT2K137cn5OPFEQAGld3g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 In-Reply-To: <834ocnd6xn.fsf@gnu.org> X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 7196 Cc: 7196@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > > The NEWS item is woefully incomplete. It doesn't explain much of > > anything about the selection changes for Emacs 24 - and they are > > radical changes. > > > > Among other things, NEWS should detail the differences from the > > previous behavior, and explain clearly how to return to the > > previous behavior (exactly, completely). > > The new text is reproduced below. If it is good enough, this bug > report can be closed. Thanks for taking a stab at it. Some suggestions and questions below. For info, are the following statements correct? 1. Anything you select becomes the primary selection (on systems that support...). 2. Everything that is put on the kill ring is also put on the clipboard. 3. Everything put on the clipboard by Emacs was also first put on the kill ring. 4. Other apps may put additional stuff on the clipboard. The kill ring is Emacs-specific, but the clipboard is not. 5. Not everything that is selected is put on the kill ring or the clipboard. If so, consider saying this explicitly. There seems to be a gap between #1 and #2. What's the relation between the primary and the clipboard? What do users need to know about it? #1 needs to also say something about the other systems, which do not support a separate primary: e.g. do they put the selection on the clipboard? the kill ring? Where do they put it? > ** Selection changes. > > The default handling of clipboard and primary selections has been > changed to conform with other X applications. > > The new behavior is that by default Emacs does not put text you select > into the clipboard, and does not add it to kill-ring . > Only commands that kill text or copy it to the > kill-ring (C-w, M-w, C-k, etc.) put the killed text into the > clipboard. Selected text is put into the primary selection (on > systems, such as X, that support the primary selection > separately from the clipboard). Is it (a) "put into the primary selection" or (b) "becomes the primary selection"? I.e., does it replace the existing primary or is it added (prepended/appended) to it? I'm guessing (b), and that this is different from the kill ring. I don't know about the clipboard - is it a list or ring, like the kill ring? Anyway, if in some cases we replace what was in some location and in other cases we add to it, those cases need to be distinguished. "Put into" implies a container of a collection. What happens to selected text on systems that do _not_ support a primary selection separate from the clipboard? Please add that info - don't just say what happens for X. This is important for understanding the rest of what you write, below. It's not clear where mouse-selected text is put on non-X and it's not clear, when you paste with the mouse, where the pasted text comes from (on non-X). It's not enough to keep saying that the primary is used for this on X - what's used on non-X? If it doesn't have a name, then give it one - something that you can refer to for the non-X case. At least make it clear, however you do it. And when you say "for systems that support the primary selection separate from the clipboard" one can get the impression (but be unsure) that the other systems use the clipboard here, since they have no separate primary. We need to state what happens for each scenario/system. > Similarly, Emacs by default does not retrieve text from the > clipboard when the mouse (e.g., mouse-2) is used for pasting text > selected in another application. Say here where it _is_ retrieved from for the mouse, before going on to talk about retrieval from the clipboard. Why "in another application"? If not also true for text selected in Emacs, then state also what the case for that text is. > Text from the clipboard is retrieved only by C-y, M-y and other > commands that yank text from the kill-ring. > Mouse commands that paste text retrieve text from the primary > selection, on systems that support it separately from the clipboard. And retrieved from where on other systems? This is confusing, especially since we've said that mouse-selected text does not get sent to the clipboard/kill ring by default. > In other words, the default behavior is that mouse gestures that Mouse actions - mouse gestures are typically thought of as something different. > select and paste text work with the primary selection, On X (you said). But you haven't said what they work with on non-X. > while keyboard commands that kill/copy and paste text work with the clipboard. I wouldn't say "copy", since there are different kinds of copy. The kind you mean here is copy to the kill ring. > This change also means that the "Copy", "Cut", and "Paste" items of > the menu-bar "Edit" menu are now exactly equivalent to, respectively > M-w, C-w, and C-y. I didn't realize that BTW. That means that on Windows they are _not_ equivalent to the Windows menus of the same names. Is that the right thing (dunno)? It's worth pointing that out, in any case. > To get back the previous behavior, whereby mouse gestures Just mouse _selection_, no? Not also mouse-2 (paste). > set the clipboard Does it set the clipboard or add to it (I don't know). The vocabulary needs to be consistent, whatever the case might be: replacement or addition. When you say "put into" it implies adding, not replacemnt. "Put onto" is ambiguous, but it also suggests that more than one thing can be put onto (so can be on) the clipboard at a time. > and retrieve text from there, customize the variables > `mouse-drag-copy-region' and (on X only) `x-select-enable-primary'. Be clear - to get back the previous behavior, _set them to_ t (or whatever the value is). Don't just say customize them; say what to customize them to. > If you don't want Emacs to put the text into the clipboard, only to > the primary selection, additionally customize > `x-select-enable-clipboard' to nil. I'm lost now. You just said that selection does not now, by default, put text on the clipboard. And you can restore "the previous behavior", which presumably was putting the selection on the clipboard, by setting "`mouse-drag-copy-region' and (on X only) `x-select-enable-primary'" to t. It's not clear, to start out with, what "the previous behavior" was. You made it clear that now selecting with the mouse sets the primary but not also the clipboard or the kill ring. What's not clear is what the previous behavior was (all its aspects) and therefore what each of the options is for - which part(s) of the previous behavior each restores. I'm hoping that this helps you. Im not trying to confuse you, though it might seem like that. This is not clear to a reader, IMO. It's not completely clear even to me. > These changes in the default behavior are reflected in the default > values of several variables: Maybe it would help to start with that. If the variables and their previous values express the previous behavior, and if their new values express the new behavior, then their descriptions should provide a clear way to say what you were trying to say above (where you left out certain info/cases). > *** `select-active-regions' now defaults to t, so active regions set > the primary selection. It was nil in previous versions. Good. (Nit: there is only one active region.) > It also accepts a new value, `only', which means to only set the > primary selection for temporarily active regions (usually made by > mouse-dragging or shift-selection). BTW, why `only' and not `temporarily' or `immediate' or `on-the-fly' or some such? Only what? (I know, this is not primarily a doc problem.) > *** `mouse-2' is now bound to `mouse-yank-primary'. > Previously, it was bound to `mouse-yank-at-click' (which is now > unbound by default. ^ ) What's the difference in _behavior_? Why make readers look up each of those commands in order to understand what's changed? Why not state all of the options together, before describing any binding changes? > *** `x-select-enable-clipboard' now defaults to t on all platforms. > Thus, killing and yanking now use the clipboard (in addition to the > kill ring). Note that this variable was already non-nil by > default on MS-Windows, which does not support the primary selection > between applications. Speaking about the "primary selection between applications" is maybe a good way to characterize some of the missing info above: we could call the place where a mouse selection is saved the "primary within Emacs" or some such, as opposed to the real primary, which is between apps. Dunno; maybe it would be confusing to reuse "primary" that way. But some way needs to be found to talk clearly about this - about each: the real primary, which can be between apps, and the other, unnamed holding place, which is Emacs-specific (for non-X). > *** `x-select-enable-primary' now defaults to nil. > This variable exists only on X; its default value was t in previous > versions. What does it do? > *** `mouse-drag-copy-region' now defaults to nil. > Its previous default value was t. What does it do? > *** Support for X cut buffers has been removed. What's the consequence for user-visible behavior? HTH - Drew From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 13:00:06 2010 Received: (at 7196-done) by debbugs.gnu.org; 15 Oct 2010 17:00:06 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P6ndV-0007o9-2G for submit@debbugs.gnu.org; Fri, 15 Oct 2010 13:00:05 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P6ndS-0007nT-Dw for 7196-done@debbugs.gnu.org; Fri, 15 Oct 2010 13:00:04 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LAC00900CK16V00@a-mtaout20.012.net.il> for 7196-done@debbugs.gnu.org; Fri, 15 Oct 2010 19:02:56 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.93.189]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LAC008XKCOT3JE0@a-mtaout20.012.net.il>; Fri, 15 Oct 2010 19:02:55 +0200 (IST) Date: Fri, 15 Oct 2010 19:02:54 +0200 From: Eli Zaretskii Subject: Re: bug#7196: 24.0.50; NEWS item "Selection changes" In-reply-to: <2875E7FCA91F426A937B145EB538F89D@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83tyknbd8h.fsf@gnu.org> References: <861FD1851FD742E4A821C8ECDDB11A55@us.oracle.com> <834ocnd6xn.fsf@gnu.org> <2875E7FCA91F426A937B145EB538F89D@us.oracle.com> X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 7196-done Cc: 7196-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > From: "Drew Adams" > Cc: <7196@debbugs.gnu.org> > Date: Fri, 15 Oct 2010 08:49:06 -0700 > > > > The NEWS item is woefully incomplete. It doesn't explain much of > > > anything about the selection changes for Emacs 24 - and they are > > > radical changes. > > > > > > Among other things, NEWS should detail the differences from the > > > previous behavior, and explain clearly how to return to the > > > previous behavior (exactly, completely). > > > > The new text is reproduced below. If it is good enough, this bug > > report can be closed. > > Thanks for taking a stab at it. Some suggestions and questions below. > > For info, are the following statements correct? Most of the time, but not always, depending on customizations. Why is that important? > #1 needs to also say something about the other systems, which do not support a > separate primary: e.g. do they put the selection on the clipboard? the kill > ring? Where do they put it? They do nothing and don't put the text anywhere outside Emacs. > > Only commands that kill text or copy it to the > > kill-ring (C-w, M-w, C-k, etc.) put the killed text into the > > clipboard. Selected text is put into the primary selection (on > > systems, such as X, that support the primary selection > > separately from the clipboard). > > Is it (a) "put into the primary selection" or (b) "becomes the primary > selection"? We use "put text into primary" and "set the primary with the text" interchangeably. > I.e., does it replace the existing primary or is it added > (prepended/appended) to it? I'm guessing (b), and that this is different from > the kill ring. It replaces the old content. > I don't know about the clipboard - is it a list or ring, like the > kill ring? It's a single buffer. > Anyway, if in some cases we replace what was in some location > and in other cases we add to it, those cases need to be distinguished. "Put > into" implies a container of a collection. I believe every user nowadays knows what happens with text that is put into the clipboard or the primary selection. Anyway, NEWS entries are not for explaining these issues. > What happens to selected text on systems that do _not_ support a primary > selection separate from the clipboard? Nothing. They stay Emacs selections. > Please add that info - don't just say what happens for X. There's nothing to tell. This functionality does not exist on non-X systems, so whatever happens on X does not happen elsewhere. > > Similarly, Emacs by default does not retrieve text from the > > clipboard when the mouse (e.g., mouse-2) is used for pasting text > > selected in another application. > > Say here where it _is_ retrieved from for the mouse, before going on to talk > about retrieval from the clipboard. I transposed the two sentences, although I don't think a distance of one sentence obfuscates the meaning enough to be confusing. > Why "in another application"? If not also true for text selected in Emacs, then > state also what the case for that text is. I set out to describe changes wrt exchange of text between Emacs and other applications. This is what this NEWS entry is about; it is not about selected text in Emacs in general. > > Mouse commands that paste text retrieve text from the primary > > selection, on systems that support it separately from the clipboard. > > And retrieved from where on other systems? Not retrieved at all. > > In other words, the default behavior is that mouse gestures that > > Mouse actions - mouse gestures are typically thought of as something different. "Mouse gestures" is frequently used terminology. > > while keyboard commands that kill/copy and paste text work with the > clipboard. > > I wouldn't say "copy", since there are different kinds of copy. The "text" part in "kill/copy text" should disambiguate that. > > This change also means that the "Copy", "Cut", and "Paste" items of > > the menu-bar "Edit" menu are now exactly equivalent to, respectively > > M-w, C-w, and C-y. > > I didn't realize that BTW. That means that on Windows they are _not_ equivalent > to the Windows menus of the same names. Why not? I think they are. > > To get back the previous behavior, whereby mouse gestures > > Just mouse _selection_, no? Not also mouse-2 (paste). The part after "whereby" describes what behavior I had in mind. > Be clear - to get back the previous behavior, _set them to_ t (or whatever the > value is). Don't just say customize them; say what to customize them to. I added non-nil. > > If you don't want Emacs to put the text into the clipboard, only to > > the primary selection, additionally customize > > `x-select-enable-clipboard' to nil. > > I'm lost now. Not clear why. > It's not clear, to start out with, what "the previous behavior" was. The "whereby..." part says what it was. > You made > it clear that now selecting with the mouse sets the primary but not also the > clipboard or the kill ring. What's not clear is what the previous behavior was > (all its aspects) and therefore what each of the options is for - which part(s) > of the previous behavior each restores. Detailed description of the previous behavior is outside the scope of NEWS entries. Especially since the previous behavior was confusingly inconsistent on X. > > These changes in the default behavior are reflected in the default > > values of several variables: > > Maybe it would help to start with that. We will risk losing the reader before she gets to the important parts. > > It also accepts a new value, `only', which means to only set the > > primary selection for temporarily active regions (usually made by > > mouse-dragging or shift-selection). > > BTW, why `only' and not `temporarily' or `immediate' or `on-the-fly' or some > such? I don't know why, I just documented it. > > *** `mouse-2' is now bound to `mouse-yank-primary'. > > Previously, it was bound to `mouse-yank-at-click' (which is now > > unbound by default. > ^ > ) > > What's the difference in _behavior_? Why make readers look up each of those > commands in order to understand what's changed? Because that's what we do in general in NEWS: give the reader enough info to go and find the details by using documentation commands. Anything else would bloat NEWS to unreasonable proportions. > > *** `x-select-enable-primary' now defaults to nil. > > This variable exists only on X; its default value was t in previous > > versions. > > What does it do? The doc string tells the whole story. > > *** Support for X cut buffers has been removed. > > What's the consequence for user-visible behavior? I don't know. And neither do others, I think -- this functionality is long obsolete and unused. I fixed the typos you pointed out, thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 14:44:18 2010 Received: (at 7196-done) by debbugs.gnu.org; 15 Oct 2010 18:44:18 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P6pGL-00006K-Te for submit@debbugs.gnu.org; Fri, 15 Oct 2010 14:44:18 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P6pGI-00006E-QL for 7196-done@debbugs.gnu.org; Fri, 15 Oct 2010 14:44:16 -0400 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9FIlllb020653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Oct 2010 18:47:49 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9F3Wu7C027781; Fri, 15 Oct 2010 18:47:45 GMT Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 688780081287168354; Fri, 15 Oct 2010 11:45:54 -0700 Received: from dradamslap1 (/10.159.220.39) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Oct 2010 11:45:53 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <861FD1851FD742E4A821C8ECDDB11A55@us.oracle.com> <834ocnd6xn.fsf@gnu.org> <2875E7FCA91F426A937B145EB538F89D@us.oracle.com> <83tyknbd8h.fsf@gnu.org> Subject: RE: bug#7196: 24.0.50; NEWS item "Selection changes" Date: Fri, 15 Oct 2010 11:45:51 -0700 Message-ID: <2AFC643BFD954766B7A93F67663AEC61@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: ActsiuooK3JNeT2wRV6zl/nEBUndcAAAPSzw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 In-Reply-To: <83tyknbd8h.fsf@gnu.org> X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 7196-done Cc: 7196-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > > For info, are the following statements correct? > > Most of the time, but not always, depending on customizations. > > Why is that important? They are clear statements of things that users need to understand. They make your explanation clearer. If they are not correct, then please correct them. IOW, summarize the change by making some similar straightforward statements (which are correct). > > #1 needs to also say something about the other systems, > > which do not support a separate primary: e.g. do they put > > the selection on the clipboard? the kill > > ring? Where do they put it? > > They do nothing and don't put the text anywhere outside Emacs. Who said anything about outside Emacs? When you select text on such a system, where is it saved (conceptually), since there is no primary selection? We're talking about the case where it is not automatically sent to the kill ring and clipboard. Think of the user's mental model. The selection is what s?he sees: selected text. When the region is no longer active, there is no visible selection. But the text that was selected is saved somewhere and it will be pasted using `mouse-2'. That conceptual "somewhere" is given a name in the case of each type of selection in Emacs - except for this one. We could call it the "primary selection" except that it doesn't act as such outside Emacs on systems that don't have a primary. > > > Only commands that kill text or copy it to the > > > kill-ring (C-w, M-w, C-k, etc.) put the killed text into the > > > clipboard. Selected text is put into the primary selection (on > > > systems, such as X, that support the primary selection > > > separately from the clipboard). > > > > Is it (a) "put into the primary selection" or (b) "becomes > > the primary selection"? > > We use "put text into primary" and "set the primary with the text" > interchangeably. Then you are using English incorrectly. "Put into" suggests a container, and that suggests that multiple things can be put there. If you are allowed to use them interchangeably, then use the latter, as it is unambiguous. > > I.e., does it replace the existing primary or is it added > > (prepended/appended) to it? I'm guessing (b), and that > > this is different from the kill ring. > > It replaces the old content. Then say so unambiguously. "Set" says that. "Put into" does not. > > I don't know about the clipboard - is it a list or ring, like the > > kill ring? > > It's a single buffer. That doesn't tell me the answer. Can you put more than one piece of selected text there? Can you access those pieces separately, as you can with the kill ring? Or is it a single piece of text, so that "putting into" the clipboard is actually setting its value, replacing the previous value? > > Anyway, if in some cases we replace what was in some location > > and in other cases we add to it, those cases need to be > > distinguished. "Put into" implies a container of a collection. > > I believe every user nowadays knows what happens with text that is put > into the clipboard or the primary selection. Well, you are wrong. I'm a user, and I did not know that. Even as a Windows user I am sometimes confused about the clipboard: you can have multiple items on the Windows clipboard, but (AFAIK) that works only in some contexts - in other contexts the clipboard seems to have only one item. > Anyway, NEWS entries are not for explaining these issues. It's up to you to decide how much you explain in NEWS and how much in the doc. My point is that the NEWS text is not yet very clear. NEWS should not need to explain more than what has changed. But if in order to do that you need to describe the behavior (before and after change), then at least the behavior description should be clear. There is nothing wrong with explaining it completely in the doc and then giving a summary of what's changed in NEWS and point there to the doc section for more info. > > What happens to selected text on systems that do _not_ > > support a primary selection separate from the clipboard? > > Nothing. They stay Emacs selections. But they are not just any old selections. When you speak later about using them, you need to distinguish selections that were made a certain way, or at least the selections that were not copied to the kill ring or some such. IOW, you talk about these things, so you need to either give them a name or unambiguously describe them each time. > > Please add that info - don't just say what happens for X. > > There's nothing to tell. This functionality does not exist on non-X > systems, so whatever happens on X does not happen elsewhere. The functionality exists of selecting with the mouse and pasting that text, without copying it to the kill ring. > > > Similarly, Emacs by default does not retrieve text from the > > > clipboard when the mouse (e.g., mouse-2) is used for > > > pasting text selected in another application. > > > Why "in another application"? If not also true for text > > selected in Emacs, then state also what the case for that text is. > > I set out to describe changes wrt exchange of text between Emacs and > other applications. This is what this NEWS entry is about; it is not > about selected text in Emacs in general. I think it's about both, or should be. If mouse-selecting text used to add it to the kill ring (as an example) or whatever and it no longer does that, then that's about use within Emacs. The default behavior has changed not only between Emacs and other apps. It has also changed within Emacs. In fact, nearly all of the questions, discussions, and bugs I (one user) have filed have been about the change in behavior within Emacs itself. This is not just about interactions between Emacs and other apps. If you want to divide the behavior changes between those affecting interactions with other apps and those affecting Emacs-only behavior, because you think that will make the explanation clearer or simpler, fine. But all behavior changes need to be described. Even a user who never leaves Emacs experiences important changes wrt selection in Emacs 24. To _not_ experience such changes, a user will need to change option values (`mouse-drag-copy-region' on Windows, for instance). > > > Mouse commands that paste text retrieve text from the primary > > > selection, on systems that support it separately from > > > the clipboard. > > > > And retrieved from where on other systems? > > Not retrieved at all. That's obviously not true. If you select text with the mouse, then click mouse-1 somewhere or hit C-g, so the region is no longer active, then you do some stuff - move the cursor around and call a few commands or whatever, move to another buffer etc. - and then you hit `mouse-2', the selection is pasted. The selection you made was saved somewhere, and then it was retrieved. And this saved selection probably should be called some name: "Emacs-only primary selection" "mouse selection" (but I think this applies also to Shift selection), or maybe just "selection". I'd suggest calling it the "primary selection" anyway and just explain that Emacs copies the notion of a primary selection from systems such as X Window for systems that don't have such a notion. The behavior needs to be described, and that means either descibing this critter each time, umambiguously, or describing it once and giving a name. Other selections have names and definitions outside Emacs: secondary, primary, clipboard. Emacs uses those same names as appropriate, and Emacs adds the kill ring (and kills, or kill-ring entries), which is Emacs-specific. This mouse/Shift selection is another kind of selection, which needs to be distinguished. It's like the primary, but it is Emacs-specific for systems that do not have a notion of primary. > > > In other words, the default behavior is that mouse gestures that > > > > Mouse actions - mouse gestures are typically thought of as > something different. > > "Mouse gestures" is frequently used terminology. Yes, but typically for something different. It is most often used to stand for specific mouse movements traced out, which act as distinguishable UI symbols. Here you mean just any action you can perform with a mouse. That is sometimes called a mouse gesture, but that term usually has a narrower connotation. You apparently just want to argue and defend your existing text. Use what you want (you will anyway). I'm just trying to help you. If you don't want to hear about things that are not very clear, fine. > > > while keyboard commands that kill/copy and paste text > > > work with the clipboard. > > > > I wouldn't say "copy", since there are different kinds of copy. > > The "text" part in "kill/copy text" should disambiguate that. I don't see how. A user can easily think s?he is copying text by selecting it with the mouse. And in a sense s?he is copying it. > > > This change also means that the "Copy", "Cut", and > > > "Paste" items of the menu-bar "Edit" menu are now exactly > > > equivalent to, respectively M-w, C-w, and C-y. > > > > I didn't realize that BTW. That means that on Windows they > > are _not_ equivalent to the Windows menus of the same names. > > Why not? I think they are. My bad. Dunno what I was thinking. > > > To get back the previous behavior, whereby mouse gestures > > > > Just mouse _selection_, no? Not also mouse-2 (paste). > > The part after "whereby" describes what behavior I had in mind. Then you don't want a comma after "behavior". Without a comma, what follows is an essential, or defining clause - it narrows the meaning of what precedes. With a comma, what follows is an inessential, or non-defining clause - it gives independent info. It's similar to the use of "that" and "which" (where "which" takes a comma). IOW, if you are narrowing the topic to only the part of the previous behavior that involves setting the clipboard, then do not use a comma. If you use a comma you are suggesting that the second clause stands for the same thing as the first: the previous behavior (all of it) involves setting the clipboard. And because many readers are not masters at such subtleties, it's best to not make the meaning depend on the simple presence/absence of a comma. Instead, rephrase it to make clear that you are only talking about that part of the previous behavior that involves setting the clipboard. > > > If you don't want Emacs to put the text into the > > > clipboard, only to the primary selection, additionally customize > > > `x-select-enable-clipboard' to nil. > > > > I'm lost now. > > Not clear why. > > > It's not clear, to start out with, what "the previous behavior" was. > > The "whereby..." part says what it was. Sorry, but I'm lost. Perhaps your next version will seem clearer. > > You made it clear that now selecting with the mouse sets the primary > > but not also the clipboard or the kill ring. What's not clear is > > what the previous behavior was (all its aspects) and therefore what > > each of the options is for - which part(s) of the previous behavior > > each restores. > > Detailed description of the previous behavior is outside the scope of > NEWS entries. Especially since the previous behavior was confusingly > inconsistent on X. How much detail you give is up to you. But NEWS needs to let users know what has changed in the user-visible behavior. If you want to give just a summary that refers to complete descriptions in the doc, that's OK, but then the doc needs to cover it completely. One way or the other, users should get complete info on what the behavior is, how it has changed, and how to get back the previous behavior. > > > These changes in the default behavior are reflected in > > > the default values of several variables: > > > > Maybe it would help to start with that. > > We will risk losing the reader before she gets to the important parts. Suit yourself, but I think you are already losing readers in the important parts. > > > It also accepts a new value, `only', which means to only set the > > > primary selection for temporarily active regions > > > (usually made by mouse-dragging or shift-selection). > > > > BTW, why `only' and not `temporarily' or `immediate' or > > `on-the-fly' or some such? Only what? > > I don't know why, I just documented it. That's why I said "BTW" and "(I know, this is not primarily a doc problem.)" But if the name were improved then the doc could be simpler. That's the connection to doc. > > What's the difference in _behavior_? Why make readers look > > up each of those commands in order to understand what's changed? > > Because that's what we do in general in NEWS: give the reader enough > info to go and find the details by using documentation commands. > Anything else would bloat NEWS to unreasonable proportions. `mouse-yank-primary' is NEW. NEWS is the place to describe such a change (including why it was made). NEWS is not just a code change log. The point here - for users - is not so much which command is bound to `mouse-2' but what the difference is between the commands. One yanks the primary and the other yanks the last kill. Stating that (one sentence) does not bloat NEWS. Users can easily determine on their own that `mouse-2' is bound to `mouse-yank-primary', and they need not necessarily know what the previously bound command was - because if they want `mouse-2' to yank a kill then they should customize that using options, not key bindings. So telling them the behavior change instead of what the current binding is would actually reduce the size of NEWS. > > > *** `x-select-enable-primary' now defaults to nil. > > > This variable exists only on X; its default value was t > > > in previous versions. > > > > What does it do? > > The doc string tells the whole story. > > > > *** Support for X cut buffers has been removed. > > > > What's the consequence for user-visible behavior? > > I don't know. And neither do others, I think -- this functionality is > long obsolete and unused. Maybe say that, so people don't wonder what behavior change they might be missing. > I fixed the typos you pointed out, thanks. Thanks for working on this bug. This change is confusing and involves lots of pieces. It might be clear to the Emacs developers but it will not necessarily be clear to a user without some help. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 15:41:20 2010 Received: (at 7196-done) by debbugs.gnu.org; 15 Oct 2010 19:41:20 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P6q9Y-0000Vk-AP for submit@debbugs.gnu.org; Fri, 15 Oct 2010 15:41:20 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P6q9V-0000Vf-Ba for 7196-done@debbugs.gnu.org; Fri, 15 Oct 2010 15:41:18 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LAC00B00K1HBJ00@a-mtaout21.012.net.il> for 7196-done@debbugs.gnu.org; Fri, 15 Oct 2010 21:44:52 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.93.189]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LAC00BHFK6Q3470@a-mtaout21.012.net.il>; Fri, 15 Oct 2010 21:44:52 +0200 (IST) Date: Fri, 15 Oct 2010 21:44:51 +0200 From: Eli Zaretskii Subject: Re: bug#7196: 24.0.50; NEWS item "Selection changes" In-reply-to: <2AFC643BFD954766B7A93F67663AEC61@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83pqvbb5qk.fsf@gnu.org> References: <861FD1851FD742E4A821C8ECDDB11A55@us.oracle.com> <834ocnd6xn.fsf@gnu.org> <2875E7FCA91F426A937B145EB538F89D@us.oracle.com> <83tyknbd8h.fsf@gnu.org> <2AFC643BFD954766B7A93F67663AEC61@us.oracle.com> X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 7196-done Cc: 7196-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > From: "Drew Adams" > Cc: <7196-done@debbugs.gnu.org> > Date: Fri, 15 Oct 2010 11:45:51 -0700 > > > > #1 needs to also say something about the other systems, > > > which do not support a separate primary: e.g. do they put > > > the selection on the clipboard? the kill > > > ring? Where do they put it? > > > > They do nothing and don't put the text anywhere outside Emacs. > > Who said anything about outside Emacs? This NEWS entry is about changes wrt exchanging selected/cut text with other applications. Anything else that pertains to selections, but not to other applications, belongs elsewhere. > When you select text on such a system, where is it saved > (conceptually), since there is no primary selection? We're talking > about the case where it is not automatically sent to the kill ring > and clipboard. That's for the manual to describe, and if there are any changes in behavior regarding that, they should be elsewhere in NEWS. NEWS does not present a coherent complete description of each topic it touches. That is not its purpose. NEWS is a series of short notes about changes the user would like to study in detail. The study itself should use the manual and the doc strings. > > > I don't know about the clipboard - is it a list or ring, like the > > > kill ring? > > > > It's a single buffer. > > That doesn't tell me the answer. Can you put more than one piece of selected > text there? Can you access those pieces separately, as you can with the kill > ring? Or is it a single piece of text, so that "putting into" the clipboard is > actually setting its value, replacing the previous value? Putting text into the clipboard or a selection sets their values. > > I believe every user nowadays knows what happens with text that is put > > into the clipboard or the primary selection. > > Well, you are wrong. I'm a user, and I did not know that. Then you will have to learn about that somewhere else, sorry. NEWS is not the place to teach such things. The manual could be a better place, if we really need to explain that (and I'm still unconvinced). > > > Please add that info - don't just say what happens for X. > > > > There's nothing to tell. This functionality does not exist on non-X > > systems, so whatever happens on X does not happen elsewhere. > > The functionality exists of selecting with the mouse and pasting that text, > without copying it to the kill ring. Again, this entry is about copy/paste between Emacs and other applications. It is not about text selections in general. > If you want to divide the behavior changes between those affecting interactions > with other apps and those affecting Emacs-only behavior, because you think that > will make the explanation clearer or simpler, fine. But all behavior changes > need to be described. I don't think anything's changed wrt selections inside Emacs. > You apparently just want to argue and defend your existing text. Use what you > want (you will anyway). I'm just trying to help you. If you don't want to hear > about things that are not very clear, fine. I simply think my job here is done, and bikeshedding over it any further is not an efficient use of my limited time. If people think they can improve what I wrote, they are welcome to it. > How much detail you give is up to you. But NEWS needs to let users know what > has changed in the user-visible behavior. If you want to give just a summary > that refers to complete descriptions in the doc, that's OK, but then the doc > needs to cover it completely. Please submit separate bug reports if you find the manuals incomplete or incorrect on these issues. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 16:22:16 2010 Received: (at 7196-done) by debbugs.gnu.org; 15 Oct 2010 20:22:17 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P6qnA-0000oN-HG for submit@debbugs.gnu.org; Fri, 15 Oct 2010 16:22:16 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P6qn9-0000oH-06 for 7196-done@debbugs.gnu.org; Fri, 15 Oct 2010 16:22:15 -0400 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9FKPk4x008717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Oct 2010 20:25:48 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9FBaClC008286; Fri, 15 Oct 2010 20:25:45 GMT Received: from abhmt010.oracle.com by acsmt355.oracle.com with ESMTP id 689056071287174229; Fri, 15 Oct 2010 13:23:49 -0700 Received: from dradamslap1 (/10.159.229.233) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Oct 2010 13:23:49 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <861FD1851FD742E4A821C8ECDDB11A55@us.oracle.com> <834ocnd6xn.fsf@gnu.org> <2875E7FCA91F426A937B145EB538F89D@us.oracle.com> <83tyknbd8h.fsf@gnu.org> <2AFC643BFD954766B7A93F67663AEC61@us.oracle.com> <83pqvbb5qk.fsf@gnu.org> Subject: RE: bug#7196: 24.0.50; NEWS item "Selection changes" Date: Fri, 15 Oct 2010 13:23:46 -0700 Message-ID: <10DF73C88842443480A7AC176D045128@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83pqvbb5qk.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: ActsoXDo3/fKv9JER7mGjDhJ5maxswAA0/sA X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: 7196-done Cc: 7196-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > I don't think anything's changed wrt selections inside Emacs. If you really think that, then maybe that's part of the problem. It is simply not true that an Emacs user will notice no difference in behavior as long as s?he doesn't interact with other apps. And you know it. One example that you're very familiar with: mouse-select (drag or mouse-3) in Emacs on Windows, then use `C-y' - the default behavior has changed. Please don't tell me what this bug report is about - I filed the report. The is `NEWS item "Selection changes"'. The NEWS item is not entitled "Selection changes when interacting with other apps". This NEWS item (or another; I don't really care) needs to also describe the selection changes that do not depend on interaction with other apps. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 16:35:08 2010 Received: (at 7196-done) by debbugs.gnu.org; 15 Oct 2010 20:35:08 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P6qzc-0000vK-D1 for submit@debbugs.gnu.org; Fri, 15 Oct 2010 16:35:08 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P6qzZ-0000uy-Kt for 7196-done@debbugs.gnu.org; Fri, 15 Oct 2010 16:35:06 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LAC00B00MLYB600@a-mtaout20.012.net.il> for 7196-done@debbugs.gnu.org; Fri, 15 Oct 2010 22:38:14 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.93.189]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LAC00AM3MNPYQ40@a-mtaout20.012.net.il>; Fri, 15 Oct 2010 22:38:14 +0200 (IST) Date: Fri, 15 Oct 2010 22:38:14 +0200 From: Eli Zaretskii Subject: Re: bug#7196: 24.0.50; NEWS item "Selection changes" In-reply-to: <10DF73C88842443480A7AC176D045128@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83lj5zb39l.fsf@gnu.org> References: <861FD1851FD742E4A821C8ECDDB11A55@us.oracle.com> <834ocnd6xn.fsf@gnu.org> <2875E7FCA91F426A937B145EB538F89D@us.oracle.com> <83tyknbd8h.fsf@gnu.org> <2AFC643BFD954766B7A93F67663AEC61@us.oracle.com> <83pqvbb5qk.fsf@gnu.org> <10DF73C88842443480A7AC176D045128@us.oracle.com> X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 7196-done Cc: 7196-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > From: "Drew Adams" > Cc: <7196-done@debbugs.gnu.org> > Date: Fri, 15 Oct 2010 13:23:46 -0700 > > It is simply not true that an Emacs user will notice no difference in behavior > as long as s?he doesn't interact with other apps. And you know it. One example > that you're very familiar with: mouse-select (drag or mouse-3) in Emacs on > Windows, then use `C-y' - the default behavior has changed. This change _is_ described in the entry I've modified. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 19:09:22 2010 Received: (at 7196-done) by debbugs.gnu.org; 15 Oct 2010 23:09:22 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P6tOr-0001z8-Cd for submit@debbugs.gnu.org; Fri, 15 Oct 2010 19:09:21 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P6tOq-0001z3-79 for 7196-done@debbugs.gnu.org; Fri, 15 Oct 2010 19:09:20 -0400 Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9FNCsfD027810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Oct 2010 23:12:55 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9FFRFDv001037; Fri, 15 Oct 2010 23:12:54 GMT Received: from abhmt006.oracle.com by acsmt355.oracle.com with ESMTP id 689445471287184261; Fri, 15 Oct 2010 16:11:01 -0700 Received: from dradamslap1 (/10.159.243.190) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Oct 2010 16:11:00 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <861FD1851FD742E4A821C8ECDDB11A55@us.oracle.com> <834ocnd6xn.fsf@gnu.org> <2875E7FCA91F426A937B145EB538F89D@us.oracle.com> <83tyknbd8h.fsf@gnu.org> <2AFC643BFD954766B7A93F67663AEC61@us.oracle.com> <83pqvbb5qk.fsf@gnu.org> <10DF73C88842443480A7AC176D045128@us.oracle.com> <83lj5zb39l.fsf@gnu.org> Subject: RE: bug#7196: 24.0.50; NEWS item "Selection changes" Date: Fri, 15 Oct 2010 16:11:01 -0700 Message-ID: <49859D9B0D3049DA9866606236C2D627@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: ActsqPYjd62szCrVTbSd1ec0416STQAFTNqw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 In-Reply-To: <83lj5zb39l.fsf@gnu.org> X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: 7196-done Cc: 7196-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > This change _is_ described in the entry I've modified. Good. Hopefully the end result will be what users need. Thanks. From unknown Sat Sep 06 02:03:51 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 13 Nov 2010 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator