From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#7702: 24.0.50; doc of select-active-regions, cut/paste/kill/yank Date: Sat, 25 Dec 2010 10:50:24 -0800 Message-ID: <46EF3254CF934EAC88E740273D51EAB1@us.oracle.com> References: <6728B5371A6446B9B4C1CEB95BFF7FF2@us.oracle.com> <83oc8acc1c.fsf@gnu.org> <666BE4469D9F466C87AE36367C3947A0@us.oracle.com> <83ei95d8pd.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1293303206 3279 80.91.229.12 (25 Dec 2010 18:53:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 25 Dec 2010 18:53:26 +0000 (UTC) Cc: 7702@debbugs.gnu.org To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 25 19:53:21 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PWZF1-00016r-2j for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Dec 2010 19:53:19 +0100 Original-Received: from localhost ([127.0.0.1]:34083 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PWZF0-0001ZZ-00 for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Dec 2010 13:53:18 -0500 Original-Received: from [140.186.70.92] (port=40889 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PWZEu-0001ZU-Ka for bug-gnu-emacs@gnu.org; Sat, 25 Dec 2010 13:53:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PWZEt-0006Rg-9U for bug-gnu-emacs@gnu.org; Sat, 25 Dec 2010 13:53:12 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33887) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PWZEt-0006Rc-7t for bug-gnu-emacs@gnu.org; Sat, 25 Dec 2010 13:53:11 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PWZ62-00032f-CY; Sat, 25 Dec 2010 13:44:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Dec 2010 18:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7702 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 7702-submit@debbugs.gnu.org id=B7702.129330263011670 (code B ref 7702); Sat, 25 Dec 2010 18:44:02 +0000 Original-Received: (at 7702) by debbugs.gnu.org; 25 Dec 2010 18:43:50 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PWZ5q-00032B-1L for submit@debbugs.gnu.org; Sat, 25 Dec 2010 13:43:50 -0500 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PWZ5o-00031z-Hn for 7702@debbugs.gnu.org; Sat, 25 Dec 2010 13:43:49 -0500 Original-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 oBPIoTpO002456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 25 Dec 2010 18:50:31 GMT Original-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 oBPEBH9q017876; Sat, 25 Dec 2010 18:50:29 GMT Original-Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 881321921293303027; Sat, 25 Dec 2010 10:50:27 -0800 Original-Received: from dradamslap1 (/10.159.223.139) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 25 Dec 2010 10:50:26 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83ei95d8pd.fsf@gnu.org> Thread-Index: AcukX1qon5JR0fWpTsiLZa91IX3G2QAARDIQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 25 Dec 2010 13:44:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:42853 Archived-At: > This variable has the same meaning and effect on Windows as on X, and > its default value is the same. So I see nothing that should be said > about that. The only difference -- that on Windows the primary > selection exists only within a single Emacs session -- is now in the > manual. What is missing, I think, is some description of what is meant by "primary emulation". I think we need to say explicitly that wherever the manual speaks of the "primary selection" understand that Emacs on Windows uses an internal cache (variable, call it what you like) that acts the same as the primary selection in X Window, with the one exception about sessions. That's all. IOW be clear that on Windows you get the same behavior as on X, even though Windows does not have a primary selection: Emacs in effect creates and uses an (internal) primary selection (emulation). Modulo the one exception wrt sessions. > "As described" in this subsection, and elsewhere in the manual. If > that's not clear, we could say that explicitly. See above. It's enough to make clear once and for all that Emacs emulates the X Window primary selection internally; IOW, it has its own internal pseudo-primary selection. [Personally, as I said from the get-go, I think it would be clearer to just call it the primary selection and have a single footnote/paragraph explaining that since Windows actually has no primary selection Emacs emulates it internally. And mention the session exception for Windows. IOW, aside from such a (single) clarification/footnote, the doc could just speak about primary selection and not mention Windows as being exceptional - not mention emulation etc. IOW2, put the proviso/explanation in a single place, and otherwise just refer to this as the primary selection, making no distinction for Windows.] > > E.g. what does it mean for a var like `select-active-regions'? > > Just what the documentation of that variable says: an active region is > placed into the primary selection, and can be pasted from there by any > command that retrieves text from the primary selection. That works if you take my suggestion and just let Emacs doc speak about the primary selection with no distinction/explanation about Windows except in a single place in the manual. But if you sprinkle mentions of primary emulation here and there users will wonder here and there how much is being emulated, whether this or that piece of doc also applies to Windows, etc. But we can agree to disagree about this. > > I think we should be more specific and say what Emacs on > > Windows does with the > > emulated primary. Does it use the kill-ring? the clipboard? > > Neither. It's an entirely separate store. Why is this important? >From the moment we say that Emacs emulates the primary selection, users need some mental mode of what we mean by that. It's not about describing or even faithfully reflecting the implementation. It's about letting users know what the behavior is on Windows. See above. It is enough to say (explicitly) that in all respects Emacs on Windows behaves as if there were a primary selection (the one exception being session behavior). "Emulation" can mean many things. There are degrees of emulation. Apparently our emulation of the primary is 100% faithful (modulo the sessions thing), so we should say that. IMHO, if that is the case then we should not even speak about emulation, except in one place in the manual, essentially as a footnote to anyone wondering about the behavior on Windows. The rest of the doc can then just refer to the primary, with no mention of Windows. The reason I was asking "What about Windows?" here and there is that our approach is instead to tell users here and there that we do "primary emulation", without saying just what it means (user-visible behavior, not implementation). It is far simpler, IMO, to state the emulation thing once and for all, in one place, in the manual, and otherwise speak as if Emacs has a primary selection - on all platforms. IOW, speak about the _Emacs_ primary selection, which behaves the same as the X Window primary selection (modulo the sessions thing on Windows). That's much easier for users, less wondering what is meant and what the behavior is. > The manual doesn't explain how the primary selection works on X, and > most users will probably never know. So why should we go into these > implementation details for Windows? If the emulation were using one > of the existing facilities, like the kill-ring, then we would need to > tell that, because the effect would be visible to the user. But since > it doesn't, and the place where the selection is stored is entirely > concealed from the user, I see no reason for any further details. You've misunderstood. It's not about describing the implementation; it's always about describing the user-visible behavior; it's always about a user point of view. The description needs only to say that Emacs _always_ behaves as if there is a primary selection, on all platforms - see above. > > > > For example, the description of `select-active-regions' makes it > > > > sound like it has no effect on a system, such as MS > > > > Windows, that has no concept of a primary selection. > > > > If that is so, then say so. > > > > > > It has the same effect on MS-Windows, with the caveat that the > > > primary selection "works" only within the current session. > > > > Then let's say that, including the last part. You've added > > the last part in the manual (above), so that's OK. But the doc > > string should at least give some indication that this var is not > > irrelevant on Windows. > > Given that I modified it to not refer to X, why would a user think > that it is irrelevant? It's unreasonable to ask that we repeat in > each doc string related to selections that these features also work on > Windows. See above. As I see it, there are two possibilities: 1. Speak here and there about "primary selection emulation", without describing the behavior, i.e., without saying how well it's emulated, how the emulated behavior differs etc. 2. Speak everywhere only about the "primary selection" (or, better, the Emacs primary selection). And in only one place in the manual (only), mention that although, technically, Windows has no primary selection, Emacs on Windows does effectively have a primary selection: Emacs emulates the X Window primary selection internally. The Emacs primary selection behaves everywhere exactly the same as an X Window primary selection. One exception: the sessions thing. You've chosen #1; I suggested #2. With choice #1, users can everywhere (e.g. each doc string) wonder just what is involved, how it behaves on Windows. By now I think I've made myself clear. What you choose to do with my feedback is up to you. > > And, as I mentioned, there is the problem of just what the > > relation is between pasting and yanking - see what I wrote > > in the initial bug report. Even just the notion of "pasting" > > is not very clear. When you use `mouse-2' are you pasting? > > Or is "pasting" reserved for something that is pasted from > > the clipboard. Etc. - we need to be clearer about these terms. > > That's a different job, and a much larger one. I would suggest a > separate bug report, or maybe wait until Emacs 24 is near its pretest. OK by me if you want to wait. Yes, it's a big job, but it was part of this bug report - see the Subject and original report. But I'm OK with your waiting. I won't bother to create another report, but you can if that's how you prefer to handle this. > That's because Emacs 23, in whose manual I made the change, makes no > distinction between these two, and in fact mixes them freely (e.g., > mouse-2 does the equivalent of C-y), so explaining the difference is > hopelessly complicated, perhaps even impossible in Emacs 23. > > > As I mentioned, there is even a mismatch between the node > > name and the node title: one refers to cut/paste and the > > other to kill/yank. > > Not anymore. Good; thanks for that. > The manual describes the correct behavior. Bugs which violate that > correctness should be fixed, they don't need to affect the manual. 100% agreement. Bugs and workarounds are not for the manual or doc strings. > What I say above is how Emacs _should_ work on Windows. Any deviation > from that behavior is potentially a bug that should be fixed. Agreed. > > [I] look forward to the new version. If I then notice anything that > > I think is unclear I'll let you know. > > Thanks. > > > If you're comfortable with having responded to my concerns, then > > please go ahead and close this bug. But please first think about > > what I said above, then decide. > > Will do. Thanks again for tackling this.