From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Colin Walters Newsgroups: gmane.emacs.devel Subject: Re: Question about copy-region-as-kill Date: 07 Apr 2002 23:09:48 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <1018235388.4269.38.camel@space-ghost> References: <87ofh09xjq.fsf@alice.dynodns.net> <200204050602.g3562Dl18586@aztec.santafe.edu> <87bscx7rlf.fsf@alice.dynodns.net> <200204061732.g36HWSb19584@aztec.santafe.edu> <87k7rkmuk0.fsf@alice.dynodns.net> <87zo0gbfb2.fsf@emacswiki.org> <1018138376.27236.49.camel@space-ghost> <87bscwe36t.fsf@tc-1-100.kawasaki.gol.ne.jp> <874rio5ide.fsf@alice.dynodns.net> <1018154686.1186.13.camel@space-ghost> <87ofgwcdgm.fsf@tc-1-100.kawasaki.gol.ne.jp> <1018157567.1186.15.camel@space-ghost> <87bscwc84q.fsf@tc-1-100.kawasaki.gol.ne.jp> <1018165593.4269.27.camel@space-ghost> <877knjd7iw.fsf@tc-1-100.kawasaki.gol.ne.jp> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1018240974 18543 127.0.0.1 (8 Apr 2002 04:42:54 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 8 Apr 2002 04:42:54 +0000 (UTC) Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16uQzV-0004oy-00 for ; Mon, 08 Apr 2002 06:42:53 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16uRDj-00016n-00 for ; Mon, 08 Apr 2002 06:57: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 16uQ0X-0000WZ-00; Sun, 07 Apr 2002 23:39:53 -0400 Original-Received: from monk.debian.net ([216.185.54.61] helo=monk.verbum.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16uPXi-0006GD-00 for ; Sun, 07 Apr 2002 23:10:06 -0400 Original-Received: from space-ghost.verbum.private (freedom.cis.ohio-state.edu [164.107.60.183]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "space-ghost.verbum.org", Issuer "monk.verbum.org" (verified OK)) by monk.verbum.org (Postfix (Debian/GNU)) with ESMTP id 320AA740009E for ; Sun, 7 Apr 2002 23:10:06 -0400 (EDT) Original-Received: by space-ghost.verbum.private (Postfix (Debian/GNU), from userid 1000) id 96EF380694C; Sun, 7 Apr 2002 23:09:48 -0400 (EDT) Original-To: emacs-devel@gnu.org In-Reply-To: <877knjd7iw.fsf@tc-1-100.kawasaki.gol.ne.jp> X-Mailer: Evolution/1.0 (Preview Release) 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:2460 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2460 On Sun, 2002-04-07 at 08:20, Miles Bader wrote: > What I'm arguing for is to keep the current interfaces, because I think > they're both useful. Whether or not they use the same underlying > mechanism is an implementation detail (about which others are more > knowledgable than I). No, it's not just an implementation detail! With the current text properties/overlays separation, it is going to be a big pain to change ibuffer to use overlays. Maybe there is a better way to do it, but I really don't see one (if someone does, please speak up!). And it will certainly be slower, as you noted in a different thread. Not only that, but it will generate more garbage: I will have to cons up at least one cell for each string returned, plus bind lots of variables, *and* add properties to the overlay one at a time. If we had extents like mechanism as the underlying implementation of both text properties and overlays, then I could fall back to just using the raw extents interface to solve my problem. > We've already got an implementation that provides both; why change (but > see below)? It provides both, as totally separate things. I want to be able to pick and choose from the features of each. > >From your description, it sounds like you would be happy if [certain] > text-properties could be optionally suppressed from being copied by a > user; true? That would solve this particular problem, yes. > What I'm not sure of why you seem to have come to the conclusion that a > whole-sale reworking of the way text-properties and overlays work is > required. I guess the only thing I can say to this is that extents make a whole lot more sense to me. I agree with you that text properties and overlays cover the majority of cases, but I think there is something more fundamental lying behind both of them.