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 03:46:33 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <1018165593.4269.27.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> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1018165881 15396 127.0.0.1 (7 Apr 2002 07:51:21 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 7 Apr 2002 07:51:21 +0000 (UTC) Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16u7SK-00040D-00 for ; Sun, 07 Apr 2002 09:51:20 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16u7gA-0006xO-00 for ; Sun, 07 Apr 2002 10:05:38 +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 16u7S4-0000bo-00; Sun, 07 Apr 2002 03:51:04 -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 16u7R6-0000Y8-00 for ; Sun, 07 Apr 2002 03:50:04 -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 795FE740009E for ; Sun, 7 Apr 2002 03:50:03 -0400 (EDT) Original-Received: by space-ghost.verbum.private (Postfix (Debian/GNU), from userid 1000) id DD82382D73D; Sun, 7 Apr 2002 03:46:33 -0400 (EDT) Original-To: emacs-devel@gnu.org In-Reply-To: <87bscwc84q.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:2448 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2448 [ No need to CC me, by the way; I read this list ] On Sun, 2002-04-07 at 01:53, Miles Bader wrote: > I don't think the concept of a `primary purpose' is all that useful, > since it's rather objective; the original reason may be different that > current thinking, and one person's view may differ from another's. Fair enough. > >From my point of view, the _most_ important thing about overlays is that > they are distinct objects that are distinct from the text, and interact > with text properties and other overlays. Indeed. But extents provide these same advantages. And it should not be difficult to write a text properties API on top of an extents mechanism. So extents give you the best of all possible worlds, AFAICS. Since I have the feeling that we are at this point arguing by repeated assertion, let me paste here the description of the problem I ran into using overlays for ibuffer, when RMS originally asked me why I thought overlays had a poor interface: > [ RMS asks why the overlay interface is bad ] I don't like it because it forces me to use a completely different API depending on whether or not I want the properties to be specific to the buffer or not, despite the fact that I want the properties to actually be associated with the text, not a specific region of the buffer. As an example, when you define an ibuffer column, you can optionally specify properties along with the text. For example: (define-ibuffer-column mode (:inline t :props ('mouse-face 'highlight 'keymap ibuffer-mode-name-map 'help-echo "mouse-2: filter by this mode")) (format "%s" mode-name)) This macroexpands to code that does: (propertize (format "%s" mode-name) 'mouse-face 'highlight ...) And then the ibuffer display function calls that bit of code, which simply inserts the text, and it will have those associated properties. However, I *do* want those properties to be specific to the ibuffer buffer! To achieve both effects, I could make the code macroexpand to something like (list (format "%s" mode-name) '(mouse-face highlight ...)) And then the ibuffer display algorithm could save the value of point, insert the text, make an overlay between the old value of point, and finally put the properties on that overlay. But that's pretty ugly. And ugly code leads me to conclude that I have the wrong approach.