From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Question about copy-region-as-kill Date: 09 Apr 2002 11:31:25 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <5x3cy5md5e.fsf@kfs2.cua.dk> References: <87ofh09xjq.fsf@alice.dynodns.net> <200204050602.g3562Dl18586@aztec.santafe.edu> <87bscx7rlf.fsf@alice.dynodns.net> <3791-Sat06Apr2002101927+0300-eliz@is.elta.co.il> <873cy9nsom.fsf@alice.dynodns.net> <87wuvk77mc.fsf@wesley.springies.com> <200204081553.g38FrFM10159@rum.cs.yale.edu> <87zo0dc2em.fsf@alice.dynodns.net> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1018341201 21099 127.0.0.1 (9 Apr 2002 08:33:21 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 9 Apr 2002 08:33:21 +0000 (UTC) Cc: emacs-devel@gnu.org Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16ur45-0005UC-00 for ; Tue, 09 Apr 2002 10:33:21 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16urIp-000541-00 for ; Tue, 09 Apr 2002 10:48:35 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16ur3q-0004Dl-00; Tue, 09 Apr 2002 04:33:06 -0400 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16ur1S-0002or-00; Tue, 09 Apr 2002 04:30:38 -0400 Original-Received: from kfs2.cua.dk.cua.dk (kfs2.local.filanet.dk [192.168.1.182]) by mail.filanet.dk (Postfix) with SMTP id A74337C047; Tue, 9 Apr 2002 08:30:32 +0000 (GMT) Original-To: John Wiegley In-Reply-To: <87zo0dc2em.fsf@alice.dynodns.net> Original-Lines: 83 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2477 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2477 John Wiegley writes: > >>>>> On Mon Apr 8, Stefan writes: > > > I think this points to a good compromise: strip any property whose > > value is the same across the whole copied text. > > This still does not solve the problem of copying the read-only > property that's attached to Eshell prompts. Maybe read-only is special...? Does it ever make sense to yank a read-only property into a buffer? If not, it doesn't make sense to ever copy that property. > > Why can't a mode author decide to inhibit property copying in his > buffer? I still haven't seen a convincing argument for denying me a > buffer-local configuration variable. > I agree, but this doesn't solve the problem in general... Consider: - copy text in one major mode buffer and paste it into another major mode buffer. In this case, it sometimes makes sense to copy face properties (e.g. from a C to an RTF file), while it doesn't make sense in other cases, (e.g. from an RTF file to a C file). - copy text into a buffer with font-lock enabled In this case, the font-lock should take care of fontifying the inserted text, ignoring any previous fontification... - copy text from a buffer with font-lock to a buffer without This is similar to the first case, so in some cases with does make sense, but in other cases it doesn't. I don't say that this is a complete solution, but at least two buffer-local variables are needed IMHO: * remove-text-properties-on-copy A list of text-properties to be removed when copying text from this buffer (nil=none, t=all) * remove-text-properties-on-insert A list of text-properties to be removed when inserting text into this buffer (nil=none, t=all) kill-ring-save, copy-region-as-kill, and kill-region should look at these. I also considered having this: * remove-font-lock-properties-on-copy If non-nil, text-properties set by font-lock are automatically removed on copy. But this isn't really needed (or possible); I don't think we really know whether a specific property was added by font-locking or added explicitly by the user. However, IMO it doesn't really seem to make much sense to have both font-locking and the user adding properties as well. So when font-locking is turned on in a buffer, it seems to make sense to set both of these variables to t (remove all). > John > > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > http://mail.gnu.org/mailman/listinfo/emacs-devel > > -- Kim F. Storm http://www.cua.dk