From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#8384: 24.0.50; Yanking and text properties Date: Tue, 05 Apr 2011 01:16:42 -0400 Message-ID: References: <8762r0utx5.fsf@escher.fritz.box> <4D9A2FD3.5050802@harpegolden.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1301981857 18642 80.91.229.12 (5 Apr 2011 05:37:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 5 Apr 2011 05:37:37 +0000 (UTC) Cc: 8384@debbugs.gnu.org, stephen.berman@gmx.net To: David De La Harpe Golden Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 05 07:37:32 2011 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 1Q6yxH-0002Sl-Ur for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Apr 2011 07:37:32 +0200 Original-Received: from localhost ([127.0.0.1]:34114 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q6yxH-0003Ae-7O for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Apr 2011 01:37:31 -0400 Original-Received: from [140.186.70.92] (port=47310 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q6yx3-00039e-Ix for bug-gnu-emacs@gnu.org; Tue, 05 Apr 2011 01:37:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q6yx1-00026H-Mk for bug-gnu-emacs@gnu.org; Tue, 05 Apr 2011 01:37:17 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55743) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q6yx1-00026D-IN for bug-gnu-emacs@gnu.org; Tue, 05 Apr 2011 01:37:15 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Q6ydS-0006CS-0o; Tue, 05 Apr 2011 01:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Apr 2011 05:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8384 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8384-submit@debbugs.gnu.org id=B8384.130198061023806 (code B ref 8384); Tue, 05 Apr 2011 05:17:01 +0000 Original-Received: (at 8384) by debbugs.gnu.org; 5 Apr 2011 05:16: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 1Q6ydF-0006Bu-QV for submit@debbugs.gnu.org; Tue, 05 Apr 2011 01:16:50 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q6ydE-0006Bf-7w for 8384@debbugs.gnu.org; Tue, 05 Apr 2011 01:16:49 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Q6yd8-0001Cp-Ei; Tue, 05 Apr 2011 01:16:42 -0400 In-reply-to: <4D9A2FD3.5050802@harpegolden.net> (message from David De La Harpe Golden on Mon, 04 Apr 2011 21:53:39 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Tue, 05 Apr 2011 01:17:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 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:45636 Archived-At: > Date: Mon, 04 Apr 2011 21:53:39 +0100 > From: David De La Harpe Golden > Cc: 8384@debbugs.gnu.org > > > Now repeat steps 2 and 3, and instead of repeating step 4, double-click > > on the text with mouse-1 to make it the primary selection, and instead > > of repeating step 5, do `C-x b b RET' to yank that selection. > > => The yanked text in buffer b is not propertized. > > > > Is this difference between the two types of yanking a programming bug or > > a feature (of the primary selection?) that is AFAICS undocumented and > > hence a doc bug? > > Hmm. I'd be inclined to consider the inconsistency a bug, - if C-w/M-y > sequences are property-preserving intraprocess*, so too should be > select/middleclick sequences, really. It could be a bug, or it could be a side effect of the implementation, because the text we select with a mouse is treated very differently from the text we put on the kill ring. However, since we have an internal alist where we store all our selections, we should be able in principle to paste local selections with all their text properties. Would someone please trace through x-own-selection-internal when selecting, and then through x-get-selection-internal when pasting with the mouse, and see why the local selections we store in Vselection_alist lose their text properties? > * properties were always lost AFAIK once the data went "all the way > outside" to other processes, though technically emacs Could Do Better > there on several platforms via the multi-format support in relevant > window system clipboad and selection protocols. Right, but since we keep our local copy of the selection, which in this case should be a string, we don't necessarily _need_ to lose the text properties. > > The comment by Glenn Morris in bug#8376 > > (http://permalink.gmane.org/gmane.emacs.bugs/45480) suggests the former, > > namely, that yanking by C-y should also not preserve text properties. > > Note, however, that mouse-yank-at-click behaves like C-y and not like > > mouse-yank-primary. (Or is it only font-locking, not face and display > > properties, > > I think it's only the font-locking if I'm understanding the arguments > correctly It's only about font-lock, and thus not relevant to this discussion. > I guess it would also be possible to "freeze" font-locking into static > face properties. At first glance, this doesn't make sense to me. If the target buffer has font-lock enabled, it will delete/override such faces on the spot anyway. So to support such a feature, someone should first present a convincing use case. > though consider too the way word processors now tend to offer "paste > special..." options AFAIU, "Paste special" options are for _reformatting_ the selection into an equivalent (for some value of ``equivalent''), but different formatting. E.g., reformat text with colors into the equivalent HTML representation. That includes stripping all the formatting as one of the possibilities. But it does not include _addition_ of formatting, so seems unrelated to converting the fontification properties to hard-coded colors. Anyway, this last issue is not related to this bug report, so it should get its own thread.