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: 16 Mar 2002 02:18:03 +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> <200203160022.g2G0MJ204725@rum.cs.yale.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1016241730 2915 127.0.0.1 (16 Mar 2002 01:22:10 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 16 Mar 2002 01:22:10 +0000 (UTC) Cc: Richard Stallman , 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 16m2te-0000kv-00 for ; Sat, 16 Mar 2002 02:22:10 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16m2wm-0007fn-00 for ; Sat, 16 Mar 2002 02:25:24 +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 16m2sh-0000jg-00; Fri, 15 Mar 2002 20:21:11 -0500 Original-Received: from mailout01.sul.t-online.com ([194.25.134.80]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16m2pp-0000ae-00; Fri, 15 Mar 2002 20:18:13 -0500 Original-Received: from fwd01.sul.t-online.de by mailout01.sul.t-online.com with smtp id 16m2po-0003Fr-01; Sat, 16 Mar 2002 02:18:12 +0100 Original-Received: from tupik.goethe.zz (520018396234-0001@[62.226.12.163]) by fwd01.sul.t-online.com with esmtp id 16m2pk-0o56GGC; Sat, 16 Mar 2002 02:18:08 +0100 Original-Received: (from dak@localhost) by tupik.goethe.zz (8.11.6/linuxconf) id g2G1I4l10560; Sat, 16 Mar 2002 02:18:04 +0100 Original-To: "Stefan Monnier" In-Reply-To: <200203160022.g2G0MJ204725@rum.cs.yale.edu> Original-Lines: 100 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:1951 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1951 "Stefan Monnier" writes: > > isearch-open-invisible will call a user-supplied hook in order to make > > invisible texts appear when searching. Those images I use in my > > buffer effectively make the original text invisible (for example, I > > replace $\frac{\pi}{3}$ by an image for the formula), so I want > > isearch to "open" them while going through the buffer. isearch will, > > however, only call isearch-open-invisible if the text/overlay is > > marked as invisible, so that is what I do. > > > > It would make more sense to modify isearch-open-invisible so it can > > deal with these images in another way. The invisible property should > > override the display property and make the text it covers not appear, > > not as itself, not modified by a display property. > > I'm not completely sure about that. After all, why would someone > put a `display' property on an `invisible' overlay if the `invisible' > property means that the `display' property will be ignored anyway ? > > In the case of `display' properties, I agree that your point of view > might be acceptable, but in the case of `before-string' and > `after-string' it is clearly not so, because it is very common to > use an overlay with both the `before-string' and the `invisible' > property in order to replace a piece of text with another. Ok, I'll try now to be as pedantic as possible with regard to this. If we make a large text area invisible, and there are some images contained entirely within it, we would usually want to have them disappear together with the hidden text. Now in the case of overlays, those are not connected with single characters, but with buffer positions. What to do in case an overlay ends exactly on a boundary between visible and invisible text? If we are at a boundary where invisibility starts, the before-string is to be displayed before the overlay, before invisibility starts. If we are at a boundary where invisibility ends, the after-string is to be displayed after the overlay, after invisibility ends. Since the invisibility property of the overlay is proposed by Richard to be equivalent to the covered text bearing an invisibility property, it would be entirely consistent to let the before-string and after-string show in the case that invisibility starts at the start of the overlay, or ends at the end, respectively. If you want to have the invisibility extend to the before-string and after-string also in case where they sit on a border of invisibility, add the appropriate text properties to the strings themselves. Now the question remains what to do with the display property itself. In case the overlay lies completely contained within an invisible area (as determined by text properties or another overlay with invisible property), it should not display. That much is obvious. But if start and/or end lie on the edge, what should we do? If we really are pedantic, the behavior will depend on the stickiness of the invisibility borders. If a character inserted at the front of the overlay will be visible (namely the overlay-start marker is of the moving type and the text invisibility comes from the overlay), the overlay can be visible. If a character inserted at the end of the overlay will be visible (the overlay-marker of the non-moving kind), the overlay can be visible, too. If one would want finer control, one would put a string into the display property. Unfortunately, a display property on characters of this string gets ignored, so there is no way to show an image via that path. I would prefer it if recursive display properties would be heeded (perhaps with a hard limit on the recursiveness, but exceeding the single level allowed currently). The most desirable semantics are less than clear here. > In such a case we again end up with `invisible' text which does have > a screen representation so that having point before or after the > invisible text is user-visible (just as is the case with ellipsis), > which implies that we again shouldn't prevent the user from placing > point immediately after the invisible text. Actually, there is a fine distinction here. The cursor can never be immediately before a before-string. It is either strictly before the start of the overlay, in which case it is one character away from the before-string, or it is on the first character of the overlay, in which case it is _after_ the before-string. It would make no sense to let it jump before the before-string once the text gets made invisible, so the cursor as an indication of point will never appear immediately before a before-string image. In a similar vein, it can never appear to be on an after-string image, but either on a character before it, or on one after it. The cursor *can*, however appear on an image displayed with the display property. > I hope you're beginning to see what I meant when I said that it's > not easy to determine when a piece of `invisible' text really has no > effect on screen. Checking the invisibility-spec is not enough: you > also have to check the presence of a `before-string' or an > `after-string' or a `display' (although this last one might > disappear if you decide that its behavior should be changed) and > maybe there are other cases. 'display can carry various items. Some *modify* the text under consideration (different faces, for example). The modifications should certainly be made invisible together with the text affected by invisibility spec of the overlay itself. But those display properties that *replace* the text altogether, well... see the above. -- 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