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: 09 Apr 2002 18:04:17 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <1018389857.3342.6.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> <1018235388.4269.38.camel@space-ghost> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1018393415 16557 127.0.0.1 (9 Apr 2002 23:03:35 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 9 Apr 2002 23:03:35 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16v4eF-0004Iw-00 for ; Wed, 10 Apr 2002 01:03:35 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16v4tG-00080u-00 for ; Wed, 10 Apr 2002 01:19:06 +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 16v4dl-0004KP-00; Tue, 09 Apr 2002 19:03:05 -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 16v4b1-0004D4-00 for ; Tue, 09 Apr 2002 19:00:15 -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 87A70740025C for ; Tue, 9 Apr 2002 19:00:03 -0400 (EDT) Original-Received: by space-ghost.verbum.private (Postfix (Debian/GNU), from userid 1000) id EB9AF806C64; Tue, 9 Apr 2002 18:04:17 -0400 (EDT) Original-To: emacs-devel@gnu.org In-Reply-To: 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.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2497 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2497 On Mon, 2002-04-08 at 02:18, Miles Bader wrote: > 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. If text properties were implemented in terms of a super-overlay (i.e. extent), then I could manually use however they were implemented to achieve "text properties" which are specific to a buffer. In other words, presumably text properties would be implemented entirely in Lisp over extents, so I could just modify that code. Presumably though, we would already have library code that does this. > 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. In this specific case, yes. You are right that I am arguing for two separate things. 1) buffer-specific text properties at the very minimum 2) the ability to fall back to a more general, and more powerful interface to properties and text; i.e. something like XEmacs' extents. This would give the Lisp-level Emacs programmer a lot more freedom and power. > If there are text-property features that you think overlays should > have, state them, and give some practical justification why they would > be good. I think an "overlay" should be able to optionally be associated with text, or at least attempt to follow it around. Like the XEmacs duplicable property. We'd like this for the case where an "object-type" interface would be good, but we *do* want the properties to conceptually be associated with the text. > If there are overlay features that you think text-properties should > have, state them, and give practical justification why they would > be good. I think text properties should optionally be able to be specific to the current buffer. This would solve the ibuffer problem. > 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. I'm curious what the disadvantages you see are. I don't claim to be an expert in this area, so there certainly exists the possibility that there are major disadvantages. But the existence of the XEmacs extent mechanism seems to argue strongly that even if such disadvantages exist, they are outweighed by the advantages.