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: 13 Mar 2002 12:19:15 +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> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1016018477 21049 80.91.224.249 (13 Mar 2002 11:21:17 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 13 Mar 2002 11:21: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 16l6on-0005TO-00 for ; Wed, 13 Mar 2002 12:21:17 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16l6rO-0005Tx-00 for ; Wed, 13 Mar 2002 12:23:58 +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 16l6oe-0002ZT-00; Wed, 13 Mar 2002 06:21:08 -0500 Original-Received: from mailout03.sul.t-online.com ([194.25.134.81]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16l6nB-0002VZ-00; Wed, 13 Mar 2002 06:19:37 -0500 Original-Received: from fwd03.sul.t-online.de by mailout03.sul.t-online.com with smtp id 16l6n8-0002Dv-09; Wed, 13 Mar 2002 12:19:34 +0100 Original-Received: from tupik.goethe.zz (520018396234-0001@[217.80.157.220]) by fwd03.sul.t-online.com with esmtp id 16l6mx-1cGWeGC; Wed, 13 Mar 2002 12:19:23 +0100 Original-Received: (from dak@localhost) by tupik.goethe.zz (8.11.6/linuxconf) id g2DBJGb01859; Wed, 13 Mar 2002 12:19:16 +0100 Original-To: rms@gnu.org In-Reply-To: <200203131058.g2DAwQh05428@wijiji.santafe.edu> Original-Lines: 74 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:1906 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1906 Richard Stallman writes: > That much I know, but the problem is when there's some other property > like a `display' property that ends up displaying something. > > If the text is invisible, it should not display *anything* no matter > what other properties it has (including `display', `after-string' and > `before-string'). An invisible piece of text should not contribute to > the screen contents (except for the ellipsis, if any). Actually, I am using overlays here. The overlay I use has the display property set (to an image), and it has the invisible property set. This makes the original text invisible (in my book), and displays some graphic. Since the display property is that of the overlay and not of the text, I find this more or less acceptable. > It seems not since David uses display+invisible when replacing > TeX source code with an image of the output in his preview-latex > package (the `invisible' property seems useless at first, but he > uses it so he can use the isearch-open-invisible hook). > > Isn't it the case that specifying an image with a property on some > text replaces the text with the image? I think so. Yes. > If that is so, I don't understand what purpose this invisible > property is supposed to serve. Can you explain? I cannot figure > out, from the mere reference to isearch-open-invisible, what he is > trying to do. When somebody uses isearch in order to look for strings in the buffer, I want to have the original text displayed where appropriate. 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. > Anyway, it is clearly a bug if invisible fails to completely > suppress the display of the text it covers. The text is not displayed. I presume that if a display property was present as a text property of the text, that the text would still be invisible. The display property of the *overlay*, however, is not really connected with the text. For example, you can have empty overlays (not covering any text) with a display property. Those effectively are "visible markers": you cannot change or delete them, but they move around like markers when inserting and deleting things. Since the display property of an overlay is not a property of the text, I find it quite acceptable that it gets not masked out by the invisible property. Things would be different if we were talking about a display property placed on text marked as invisible. > The text should be intangible when it is invisible, and not when it > is not. And none of that should require changing actual text > properties. Intangibility in its current implementation is *much* too heavy-handed for getting automatically activated. It has lots of bad side-effects, like making count-lines act differently and stuff. I _strongly_ suggest that you refrain from making invisible text intangible automatically. It is ok to have point-adjustment (namely, use the cursor out of invisible areas after a user command completes), but the semantics of "intangible" disturb all buffer manipulations. Lots of packages will break if you apply it automatically. -- 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