From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.bugs Subject: bug#8384: 24.0.50; Yanking and text properties Date: Mon, 04 Apr 2011 21:53:39 +0100 Message-ID: <4D9A2FD3.5050802@harpegolden.net> References: <8762r0utx5.fsf@escher.fritz.box> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1301951250 10217 80.91.229.12 (4 Apr 2011 21:07:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 4 Apr 2011 21:07:30 +0000 (UTC) Cc: 8384@debbugs.gnu.org To: Stephen Berman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 04 23:07:26 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 1Q6qzd-0001nS-K1 for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Apr 2011 23:07:25 +0200 Original-Received: from localhost ([127.0.0.1]:37630 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q6qzd-0000j1-1P for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Apr 2011 17:07:25 -0400 Original-Received: from [140.186.70.92] (port=55692 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q6qzV-0000ZD-2E for bug-gnu-emacs@gnu.org; Mon, 04 Apr 2011 17:07:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q6qzT-0004p8-Be for bug-gnu-emacs@gnu.org; Mon, 04 Apr 2011 17:07:16 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56058) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q6qzT-0004p4-8w for bug-gnu-emacs@gnu.org; Mon, 04 Apr 2011 17:07:15 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Q6qmg-0003pm-8p; Mon, 04 Apr 2011 16:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: David De La Harpe Golden Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Apr 2011 20:54:02 +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.130195043514725 (code B ref 8384); Mon, 04 Apr 2011 20:54:02 +0000 Original-Received: (at 8384) by debbugs.gnu.org; 4 Apr 2011 20:53:55 +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 1Q6qmY-0003pS-JD for submit@debbugs.gnu.org; Mon, 04 Apr 2011 16:53:54 -0400 Original-Received: from harpegolden.net ([65.99.215.13]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q6qmU-0003pC-Ss for 8384@debbugs.gnu.org; Mon, 04 Apr 2011 16:53:52 -0400 Original-Received: from [87.198.55.209] (87-198-55-209.ptr.magnet.ie [87.198.55.209]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA rev 3" (verified OK)) by harpegolden.net (Postfix) with ESMTPSA id 02085683D9; Mon, 4 Apr 2011 21:53:40 +0100 (IST) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 In-Reply-To: <8762r0utx5.fsf@escher.fritz.box> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 04 Apr 2011 16:54: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:45630 Archived-At: On 30/03/11 23:26, Stephen Berman wrote: > 1. emacs -Q > 2. Enter text in a buffer and select it, e.g.: `C-x b a RET test C-SPC C-a' > 3. Put a face or display text property on the selected text, e.g.: `M-o b' > 4. Put the propertized text on the kill ring: `C-SPC C-e M-w'. > 5. Yank it in another buffer: `C-x b b RET C-y' > => The yanked text in buffer b is propertized as in buffer a. > > 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. * 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. > 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 (which I may presently not), the font-locking properties are after all dynamic things, not something the user sets - i.e. if you yanked some python code into a python docstring (or some entirely separate sphinx rst file) you presumably wouldn't want them preserved, the correct thing to do is let the inserted text be rehighlighted according to the locally applicable rules if any. I guess it would also be possible to "freeze" font-locking into static face properties. Not something I'd personally want to happen unless I asked for it - though consider too the way word processors now tend to offer "paste special..." options (related to the aforementioned multi format support), i.e. there are nowadays established ways for apps to offer both formatted and unformatted variants of text to paste in on our three major window systems. The development work involved is nontrivial though, at least in my estimation.