From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: Question about copy-region-as-kill Date: 08 Apr 2002 15:18:24 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: 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> <1018235388.4269.38.camel@space-ghost> Reply-To: Miles Bader NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1018253376 29164 127.0.0.1 (8 Apr 2002 08:09:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 8 Apr 2002 08:09:36 +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 16uUDY-0007aH-00 for ; Mon, 08 Apr 2002 10:09:36 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16uURp-0005iu-00 for ; Mon, 08 Apr 2002 10:24:22 +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 16uTBG-0000bQ-00; Mon, 08 Apr 2002 03:03:10 -0400 Original-Received: from tyo202.gate.nec.co.jp ([210.143.35.52]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16uSUU-0004Na-00; Mon, 08 Apr 2002 02:19:03 -0400 Original-Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g386IdQ19418; Mon, 8 Apr 2002 15:18:40 +0900 (JST) Original-Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g386IdY07887; Mon, 8 Apr 2002 15:18:39 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp ([10.30.114.133]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id g386IYi19395; Mon, 8 Apr 2002 15:18:37 +0900 (JST) Original-Received: from mcspd15.ucom.lsi.nec.co.jp (mcspd15 [10.30.114.174]) by mcsss2.ucom.lsi.nec.co.jp (8.10.2+Sun/3.7Wlsi_mx_6.0) with ESMTP id g386ITg21013; Mon, 8 Apr 2002 15:18:29 +0900 (JST) Original-Received: by mcspd15.ucom.lsi.nec.co.jp (Postfix, from userid 31295) id DB01E36F6; Mon, 8 Apr 2002 15:18:24 +0900 (JST) Original-To: Colin Walters System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: <1018235388.4269.38.camel@space-ghost> Original-Lines: 99 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:2463 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2463 Colin Walters writes: > > 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. I am claiming that text-properties and overlays are desirable _interfaces_ to certain bits of functionality. If you `change ibuffer to use overlays' you're changing which _interface_ you use. This interface change wouldn't be any easier if text-properties were implemented in terms of some sort of super-overlay. What you _really_ seem want (though you never seem to come right out and say it; or at least I missed it) is to be able to have buffer-specific text-properties without changing the interface you use. That is, to extend the functionality of text-properties to include something that overlays do. I happen to think this would be a great change to text-properties -- but that doesn't mean that the existing implementations are fatally flawed! Maybe they are, but this isn't the evidence that shows that. > 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. I think the right answer is to extend text-properties so that you can control which ones are copied out of a buffer. Note that this solution has _none_ of the drawbacks you list above. [well, I think, anyway, since some of them were a bit vague] > 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. Since the `raw extents' interface is (I think!) overlay-like, it sounds like you'd have all the same pain, actually. > > 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. Please be more specific. One reason why I don't think having two separate implementations is bad, is that I don't think the separation is as arbitrary as you do. So: If there are text-property features that you think overlays should have, state them, and give some practical justification why they would be good. If there are overlay features that you think text-properties should have, state them, and give practical justification why they would be good. You've already given example of the latter -- you want buffer-specific text properties. Now, as it happens this particular feature would be pretty trivial to implement using the existing text-property implementation. However, if there's a long list of such (well justified!) features, then maybe you're right, and a merged implementation would be better. There are a lot of disadvantages to such a merged implementation, so there has to be a lot of justification too. > > 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. Good. > 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. I've been very happy with TPs and overlays -- except for the issue of unwanted copying of text properties. In previous discussions about how to handle that problem, the main stumbling block was what policy to use to copy, and a merged implementation wouldn't help that at all. Cheers, -Miles -- `...the Soviet Union was sliding in to an economic collapse so comprehensive that in the end its factories produced not goods but bads: finished products less valuable than the raw materials they were made from.' [The Economist]