From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David.Kastrup@t-online.de (David Kastrup) Newsgroups: gmane.emacs.devel Subject: Re: Should invisible imply intangible? Date: 19 Mar 2002 00:36:19 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200202232019.g1NKJoG14638@aztec.santafe.edu> <200202250510.g1P5A3714156@rum.cs.yale.edu> <200202262013.g1QKDef16683@aztec.santafe.edu> <200203010130.g211UDG05790@rum.cs.yale.edu> <200203031440.g23EeN200619@aztec.santafe.edu> <200203031711.g23HBI623254@rum.cs.yale.edu> <200203042341.g24NfiH00596@aztec.santafe.edu> <200203052158.g25Lw7A01243@wijiji.santafe.edu> <200203052304.g25N4pI03908@rum.cs.yale.edu> <200203092003.g29K3b303868@wijiji.santafe.edu> <200203092237.g29MbGf29464@rum.cs.yale.edu> <200203102132.g2ALWPK04119@wijiji.santafe.edu> <200203102202.g2AM26q06798@rum.cs.yale.edu> <200203111906.g2BJ6BY04591@wijiji.santafe.edu> <200203121756.g2CHuG514941@rum.cs.yale.edu> <200203131058.g2DAwQh05428@wijiji.santafe.edu> <200203150341.g2F3flZ06455@wijiji.santafe.edu> <200203160639.g2G6drE07446@wijiji.santafe.edu> <200203180906.g2I96T908530@wijiji.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1016506097 11072 127.0.0.1 (19 Mar 2002 02:48:17 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 19 Mar 2002 02:48:17 +0000 (UTC) Cc: monnier+gnu/emacs@rum.cs.yale.edu, 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 16n9fd-0002sU-00 for ; Tue, 19 Mar 2002 03:48:17 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16n9ki-0000wd-01 for ; Tue, 19 Mar 2002 03:53:33 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16n6ij-0004xR-00; Mon, 18 Mar 2002 18:39:17 -0500 Original-Received: from mailout05.sul.t-online.com ([194.25.134.82]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16n6g0-0004tI-00; Mon, 18 Mar 2002 18:36:28 -0500 Original-Received: from fwd04.sul.t-online.de by mailout05.sul.t-online.com with smtp id 16n6fu-0005BF-00; Tue, 19 Mar 2002 00:36:22 +0100 Original-Received: from tupik.goethe.zz (520018396234-0001@[62.226.11.128]) by fwd04.sul.t-online.com with esmtp id 16n6ft-0n7QeGC; Tue, 19 Mar 2002 00:36:21 +0100 Original-Received: (from dak@localhost) by tupik.goethe.zz (8.11.6/linuxconf) id g2INaJs02980; Tue, 19 Mar 2002 00:36:19 +0100 Original-To: rms@gnu.org Original-Lines: 89 X-Sender: 520018396234-0001@t-dialin.net Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2022 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2022 Richard Stallman writes: > In particular, how would your model treat an overlay > having a display property with an image in it, when the text up to and > including character 10 of the buffer was invisible (due to a text > property, for example), and both overlay-start and overlay-end are 11. > > Your previous statements did not say that you meant empty overlays > only. Nor did this statement. The point I wanted to make but apparently failed to get across is that any behavior for treating the invisibility property should work consistently with the special case of empty overlays. > I was thinking of nonempty overlays. For empty overlays, the > treatment you proposed might be right. At least it seems plausible > to try. > > It would be useful to have functions to get the text properties (or > just one of them) that would be inherited by an insertion at a given > buffer position. It looks like that would be useful as a subroutine > for many purposes. Now this failure to get my meaning across certainly is my fault for using the wrong words. What I wanted to make the behavior depend on was not the stickiness of properties, but actually the marker insertion type of the overlay boundaries. I apologize for the confusion. Probably with text properties indeed the stickiness might be interesting, but here I am currently concerned with overlays. Let's try to come up with the most consistent behavior for cursor display and invisibility display. As Stefan (or was it Miles?) has already remarked, the default display of cursors should preferably be such that an insertion of new characters will occur at the location where the cursor is visible. Let's first talk this through without the further complication of invisibility. If point is on the first character of a text-range with a before-string property (this property only works with overlays), this means that the cursor should display on the first character of the range if the insertion type of the overlays begin marker is don't-move-on-insertion, but it should display on the before-string itself if the insertion type is move-on-insertion. Similar behavior would apply if point is on the first character following an overlay. Ok, now we have the case that the cursor is usually moved out of invisible areas (point adjustment) and currently cannot be positioned immediately behind an invisible area so that cursor movement does not appear to hesitate. If the cursor is kept out of invisible areas, it makes sense to try to define the insertion such that wherever a legal cursor position is, insertion characters will not insert into the invisible area. This cannot always be achieved: when the overlay-beginning marker is of the stay-before-insertion variety, and the overlay-end marker is of the move-after-insertion variety, there will be no cursor position between the preceding visible and the following visible character where inserted characters would not become invisible. The other cases can be dealt with consistently: if both markers are of the moving variety, we want to have the cursor position before the overlay legal. If both are of the staying variety, we want to have the cursor position behind the overlay legal. If the front marker is of the moving and the end marker of the staying variety, I would tend to make the position behind the invisible overlay legal (so that the overlay does not move), and the pathological case where inserted characters disappear should be treated the same so that successively entered invisible characters will appear (after point adjustment) in the right order at the end of the invisible area. If the position before the invisible area would be the legal one, then one character would get inserted invisibly, but then the cursor would move to after the character following the overlay -- unpretty. Now to the visibility of before-string and after-string: as pointed out already, it is a common idiom to set some text (often just an "x") to invisible and place a before-string or after-string for an image instead, so we would not want to have those disappear in the common case. Afraid I am too tired currently to work out this in detail, too. If anybody cares about these sort of ramblings, I can try to think about it later. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: David.Kastrup@t-online.de _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel