From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Invisibility bug: `invisible' vs `display' Date: Thu, 22 Feb 2007 14:38:47 +0100 Message-ID: <86mz36wbvc.fsf@lola.quinscape.zz> References: <87sldbtd50.fsf@wigwam.brockman.se> <87hctraqhh.fsf@stupidchicken.com> <87hctq6eyd.fsf@wigwam.brockman.se> <861wkucyxw.fsf@lola.quinscape.zz> <87ps8e9k8e.fsf@wigwam.brockman.se> <87vehu99x7.fsf@wigwam.brockman.se> <863b4yxvu3.fsf@lola.quinscape.zz> <87ps82gwdi.fsf@wigwam.brockman.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1172151553 24730 80.91.229.12 (22 Feb 2007 13:39:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 22 Feb 2007 13:39:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Daniel Brockman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 22 14:39:06 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HKEA5-0005UL-PO for ged-emacs-devel@m.gmane.org; Thu, 22 Feb 2007 14:39:06 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HKEA5-0002Rj-Fo for ged-emacs-devel@m.gmane.org; Thu, 22 Feb 2007 08:39:05 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HKE9t-0002RU-Rr for emacs-devel@gnu.org; Thu, 22 Feb 2007 08:38:53 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HKE9r-0002RI-Br for emacs-devel@gnu.org; Thu, 22 Feb 2007 08:38:52 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HKE9r-0002RF-71 for emacs-devel@gnu.org; Thu, 22 Feb 2007 08:38:51 -0500 Original-Received: from pc3.berlin.powerweb.de ([62.67.228.11]) by monty-python.gnu.org with esmtp (Exim 4.52) id 1HKE9q-0007J5-Hg for emacs-devel@gnu.org; Thu, 22 Feb 2007 08:38:50 -0500 Original-Received: from quinscape.de (pd95b0fdb.dip0.t-ipconnect.de [217.91.15.219]) by pc3.berlin.powerweb.de (8.9.3p3/8.9.3) with ESMTP id OAA26709 for ; Thu, 22 Feb 2007 14:38:43 +0100 X-Delivered-To: Original-Received: (qmail 30111 invoked from network); 22 Feb 2007 13:38:48 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by ns.quinscape.de (qmail-ldap-1.03) with SMTP for ; 22 Feb 2007 13:38:48 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id 206B923889; Thu, 22 Feb 2007 14:38:48 +0100 (CET) In-Reply-To: <87ps82gwdi.fsf@wigwam.brockman.se> (Daniel Brockman's message of "Thu\, 22 Feb 2007 14\:22\:33 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:66616 Archived-At: Daniel Brockman writes: > David Kastrup writes: > >> storm@cua.dk (Kim F. Storm) writes: >> >>> Mixing invisible and display properties -- with the desire to actually >>> get the effects of the display property looks very obscure to me, and >>> cannot image that any code is actually relying on such functionality. >>> >>> I think the change is safe, so I installed it. >> >> Sigh. If you use preview-latex on material where _some_ of it is made >> invisible using TeX-fold-mode, the desired outcome will be to get the >> display, and get it once only. > > The bug did not let you override the `invisible' property > using the `display' property whenever you wanted; How do you know what I want? > it _only_ let you do that at the start of invisible text --- clearly > counter-intuitive, counter-useful, illogical, and erroneous. A display embedded in an invisible area should obviously not be visible. At the immediate edge, it is not clear what should take preference. If we have a display overlay with identical start and end points both of which advance-on-insert, then the overlay _clearly_ marks the position _between_ the text before and behind it. If the text _behind_ it is invisible, this should obviously not affect the overlay. Even more so if the displayed overlay is non-advance-on-insert. Very clearly your proposed behavior is counter-intuitive, counter-useful, illogical, and erroneous. But since the patch does not involve any check related to "start of invisible", it would, anyway, seem to do much more than the purported fix. So we not only get new, erroroneous behavior, but also we get an undetermined and untested amount of such. > The reason I'm laboring this point is that you do not seem to > appreciate the obscurity of the now-eliminated special case. And you do not seem to appreciate the non-obscurity of a number of not so special cases that are now affected. >> I can't vouch for the patch being either a step in the right or >> wrong direction. > > Ignoring for a moment the fact that the old behavior was very > strange (it was almost exactly like the new behavior, except for an > obscure special case), are there actually any arguments for having > `display' override `invisible'? > > If you want some text to show, why not just set `invisible' > to nil on that text? Display properties are not necessarily a part of text. >> But I'd clearly like to see fewer "I think it should work and can't >> imagine anybody actually using it, anyway" patches at this point in >> the game. > > One can never be sure that no code is relying on obscure bugs, but I > _can_ imagine that quite some code is actually relying on the manual > being right in that ``any non-`nil' `invisible' property makes a > character invisible [...] if you don't alter the default value of > `buffer-invisibility-spec'.''[1] You yourself said that the bug was obscure and showed only in obscure cases. I did not see anybody claim the same for the purported fix, and there have been no tests. -- David Kastrup