From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: How to solve overlay conflict between invisible and display? Date: Wed, 17 Jul 2024 15:13:32 +0300 Message-ID: <86ed7sgqs3.fsf@gnu.org> References: <87o76wl9ha.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12751"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 17 14:14:32 2024 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sU3YF-00039F-N2 for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 17 Jul 2024 14:14:31 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sU3Xb-0002OD-2f; Wed, 17 Jul 2024 08:13:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sU3XS-00023H-JD for help-gnu-emacs@gnu.org; Wed, 17 Jul 2024 08:13:42 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sU3XQ-0007oB-VD for help-gnu-emacs@gnu.org; Wed, 17 Jul 2024 08:13:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=fs4gmlBnV0BsRxR0E2vR7yqdPpeP+gviw4RwGTDuCZU=; b=gLU7QhRP3QTk+fXCYVUq hc/DZF39yJ4c0CiFXRFksZkLoXtEv6tpmgH4yj4FXv7nBogkkm0Gs1kV3OKcqFcKIWcG7Fzx5ewiO B800sJE+e+jBuuNbavzx6LfqBau+GBApLnpkMu1e9IzktoeDLILovhkwVvRGulfdEsiTKF3LVsVxU yO+PMD495IpbhB0BgGT/oGJYvR69biY9DsK7548eATZBjCAl5WiXACL71na0D2NLGApntIcNTBdC7 5muNInu7bRydfoxRnJPZ1MilACdJYAucb5QGqD02rlYBuiMA2FT4uPwa9fRTNBRy4QLHaBwA1opUs W3DXvOROHONmaA==; In-Reply-To: <87o76wl9ha.fsf@gnu.org> (message from Tassilo Horn on Wed, 17 Jul 2024 10:16:01 +0200) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:147267 Archived-At: > From: Tassilo Horn > Date: Wed, 17 Jul 2024 10:16:01 +0200 > > I have a problem where two modes use overlays in a way where the result > is not desirable. One mode hides complete sections of text by adding > overlays with `invisible` property, the other mode alters the displayed > text using overlays with `display` property. That's not a good combination. > In the concrete scenario [1], the invisible-overlays always surround the > overlays with display property, e.g., the latter are nested in the > former. > > [invisible t [display foo] [display bar]...] > > So effectively the nested overlays have both a non-nil `invisible` > property and additionally a `display` property. In that case, it seems > the `display` property wins. What do you mean by "nested"? If the invisible property starts _before_ the display property, the invisible property "wins". This variant of your text program: (defun th/overlay-invisible-and-display-test () (interactive) (save-excursion (goto-char 1) (while (re-search-forward "foo" nil t) (let ((o1 (make-overlay (match-beginning 0) (match-end 0))) (o2 (make-overlay (1+ (match-beginning 0)) (1- (match-end 0))))) (overlay-put o1 'invisible t) (overlay-put o2 'display "§"))))) when run from *scratch*, completely removes "foo" from display, showing only the quotes, which means the invisible property "won". > That can be validated using this simple > demo command in a buffer with text where the word foo will get an > overlay with both `invisible` and `display` property: > > --8<---------------cut here---------------start------------->8--- > (defun th/overlay-invisible-and-display-test () > (interactive) > (save-excursion > (goto-char 1) > (while (re-search-forward "foo" nil t) > (let ((o (make-overlay (match-beginning 0) (match-end 0)))) > (overlay-put o 'invisible t) > (overlay-put o 'display "§"))))) > --8<---------------cut here---------------end--------------->8--- Here, both invisible and display properties start at the same buffer position, so the display property "wins". Why? simply because the display code examines the properties sequentially, and it examines the display property _before_ the invisible property. IOW, this is the side effect of how properties are handled by the display engine. > In my scenario, I would like that the outer invisible overlay also hides > the nested display overlays. Then make the invisible property start before display. > In there anything either the mode producing the outer `invisible` > overlay or the mode producing the inner `display` overlay could do so > that what should be invisible actually becomes invisible? Short of deleting the overlay with the display property, I don't think you can do anything other than changing where the invisible property begins. > I've already tried setting `display` to nil in the outer overlays and > raising the priority in the howe that `display nil` then overrides > `display "some string"` from the inner overlays but that doesn't seem to > make any difference. That's because display property with value nil is the same as no display property. > Well, it sounds like common sense that invisible should win over > display, or to be more clear, display should only be effective on > visible overlays. So maybe that's actually a bug in emacs (current > master)? The display property _replaces_ the text it covers, so it also kind-of "hides". Which one "hides" first is what determines the results. And no, it is not a bug: Emacs always worked like that. To be sure, I've ran your recipe in Emacs 21.4, and got the same result.