From unknown Mon Jun 16 23:32:46 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#76658 <76658@debbugs.gnu.org> To: bug#76658 <76658@debbugs.gnu.org> Subject: Status: Emacs 27.2; Prioritized invisible overlay is NOT taking precedence over non-prioritized display overlay Reply-To: bug#76658 <76658@debbugs.gnu.org> Date: Tue, 17 Jun 2025 06:32:46 +0000 retitle 76658 Emacs 27.2; Prioritized invisible overlay is NOT taking prece= dence over non-prioritized display overlay reassign 76658 emacs submitter 76658 "David's Coding Lounge" severity 76658 normal tag 76658 notabug thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 01 04:37:20 2025 Received: (at submit) by debbugs.gnu.org; 1 Mar 2025 09:37:21 +0000 Received: from localhost ([127.0.0.1]:32951 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1toJHa-0002gN-QE for submit@debbugs.gnu.org; Sat, 01 Mar 2025 04:37:20 -0500 Received: from lists.gnu.org ([2001:470:142::17]:60368) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1to9iE-0006XU-09 for submit@debbugs.gnu.org; Fri, 28 Feb 2025 18:24:12 -0500 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 1to9i4-0007B5-Qh for bug-gnu-emacs@gnu.org; Fri, 28 Feb 2025 18:24:01 -0500 Received: from mail-lj1-x22f.google.com ([2a00:1450:4864:20::22f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1to9i2-0000la-80 for bug-gnu-emacs@gnu.org; Fri, 28 Feb 2025 18:24:00 -0500 Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-30b9f7c4165so5975481fa.3 for ; Fri, 28 Feb 2025 15:23:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740785035; x=1741389835; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=xGaq9mSaAvARiGyggWufLgPhnbVYtIt6JFSoqgNT74s=; b=VtEW0DKbR0/2s7uBHkbUDIn1dKSm0xMAzbSwVORIogFgNcLvaDiYZDiq0YF5IDq5V6 Yb7uuQiVg7TZXHzoU1KXY//kJzVlKqfJdo7xY7cdxWO0iHsNdww0fpPjfJcEA7BuMfgD /D0LBqIJsMKD8pDgbPBtUSkTGS5CJR2KQmsTPW092QocS6oy4zwDGYSLokZ4+6JQEFrw Qx6C3yFLBu8xZ3ynno/mlxFYocBgedeO7Q3r+1MltfP24zNv9kLvtzjGGktrvawrLTWW Ahbs7l/aXuHk5FTzM2k93RjgBGX4lH09G4oki29ALSr6ylqVcYGypQm8xmU+qgJjBg7d pOkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740785035; x=1741389835; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=xGaq9mSaAvARiGyggWufLgPhnbVYtIt6JFSoqgNT74s=; b=lQtC3y2QXu6oPB9ar3NTuDa3hLjwyuyZEnOUi184GUp6DTdcOPQfTjgyUX0JdaL88R lSlqmWH7d+ec+py73nsG0VjPTw6u/5gBOHiZ6bc7dCxhnOu+hfQB3A8w44ykfpmRMjHR oUP0cxEGicHA9OLrQTy/GP1OyphRfyCwPel4XftRLMuXbQ5gEszyBrLSQwEpidZlNIZl lMCgEx5tNBgI9heGSu8E8YtBH4NaDjuvTvsXveDe9fBqbbv7yHuyHmeLnSNBZnRjq1Sj +F/zoxGf0oDN5erzcQAJ25H47Ae4oqE3gjx+o8V3017+pyyGNIzzmCzSulamnhjl105G PSmQ== X-Gm-Message-State: AOJu0YwgqaQ09ypWK9LqZBCm34F0/vJqOfpJRdH+pK6qF3hnV285woia XLCYsMJLBivj7VJkNm7MWtMC67JbqbvrUwJQ7sVip0v+ZL2qcKM8z0JQc98w3mlMtdyAb1U0/l0 w2Ty5zkZ56E/eIq3WFIpJaaNYzgZAmYL7 X-Gm-Gg: ASbGncvEow9KDhxr64pTeSABcDA3cBl97TlHDIV2GvgXo9j7F/l5uNXBE1r9skM+huc ZdCvtcOlx2i8j8R6GE9ACMrrMQQLURgGH7o3KB92wGe2Tn2YfFtgfMi9fdHOM+gm6LA1qVILjLf 64FyICQqCd+gKjPhmAxXHrK99Ihq9PGB33X8kfve8EleL+djbsr6F4d+Q6x+s= X-Google-Smtp-Source: AGHT+IG7jPaSAlqSjxB0c0y0IQkBokMs3EiOdDg85Y7BefQ10H3oyR2dLjiMHOGr8cTD/T7RfYnXXlm8GTZ0AqgShGU= X-Received: by 2002:a2e:7a06:0:b0:308:e1ed:d321 with SMTP id 38308e7fff4ca-30b93454baemr12057191fa.33.1740785034345; Fri, 28 Feb 2025 15:23:54 -0800 (PST) MIME-Version: 1.0 From: "David's Coding Lounge" Date: Fri, 28 Feb 2025 18:23:41 -0500 X-Gm-Features: AQ5f1Jr5c1OEyUqvvi0SmQVoiVUnIvbIDA_AhfbUFGgNntRdJxJo5vqezHaNO8s Message-ID: Subject: Emacs 27.2; Prioritized invisible overlay is NOT taking precedence over non-prioritized display overlay To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="0000000000009a47d5062f3c19b5" Received-SPF: pass client-ip=2a00:1450:4864:20::22f; envelope-from=davidcodinglounge@gmail.com; helo=mail-lj1-x22f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sat, 01 Mar 2025 04:37:18 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --0000000000009a47d5062f3c19b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, This bug report is essentially taken from my Emacs Stack Exchange post: https://emacs.stackexchange.com/questions/83169/why-doesnt-a-prioritized-in= visible-overlay-take-precedence-over-non-prioritized ## Details I have several overlays being applied to a buffer to replace the `display` property of certain characters. There is also another overlay being applied (conditionally) for making the nested items/text `invisible` in _addition_ to changing the `display` property. I set the overlay with the `invisible` property to a higher priority (i.e. actually having a priority), but it is not working as expected. The character is _still_ being displayed with the alternative `display` character while _also_ having the `invisible` property set to `t` from the higher priority overlay. The only thing that I could find that would _seem_ to explain this behavior was an obscure Reddit thread: https://www.reddit.com/r/emacs/comments/17nxc9s/problem_making_overlays_inv= isible/ whereby the `display` property apparently takes precedence over `invisible`. This makes sense for non-prioritized overlays, however I wouldn't imagine this would be correct when there is a `priority` property applied. ## Reproducible Code/Data Example code (using `ov` library) to demonstrate the problem: ```lisp (ov 1 2 'display "=E2=80=A2") (ov 10 12 'display "=E2=98=85") (ov 19 21 'display "=E2=98=85") (ov 28 30 'display "=E2=98=85") (ov 10 37 'invisible t 'priority 10) ``` Example data to show the issue (NOTE: - Org mode is irrelevant, it occurs by executing the code against the same data in a scratch buffer): ```text * Root A ** Sub A ** Sub B ** Sub C * Root B ** Sub 1 ** Sub 2 ** Sub 3 ** Sub 4 * Root C ** Sub I ** Sub II * Root D ``` The even more confusing issue is that the effect _would_ seem to work as expected when I change the `invisible` overlay start index by 1 less (e.g. `(ov 9 37 'invisible t 'priority 10)`). This doesn't seem to logically be consistent. ### Image of Example Code/Data Reproducing the Issue: https://i.sstatic.net/8cAP29TK.png *The character at index position 10 is visible despite having the `invisible` property set to `t` and the `invisible` overlay having the highest priority.* ## Investigation Notes Even after reviewing the documentation for `overlays` and the `priority` property ( https://www.gnu.org/software/emacs/manual/html_node/elisp/Overlay-Propertie= s.html), it _still_ does not make sense. The documentation says (emphasis mine): > This property=E2=80=99s value determines the priority of the overlay. If = you want to specify a priority value, use either nil (or zero), or a positive integer, or a cons of two values. Any other value triggers undefined behavior. > > **The priority matters when two or more overlays cover the same character and both specify the same property with different values; the one whose priority value is higher overrides the other.** (For the face property, the higher priority overlay=E2=80=99s value does not completely override the ot= her value; instead, its individual face attributes override the corresponding face attributes of the face property whose priority is lower.) If two overlays have the same priority value, and one is =E2=80=9Cnested=E2=80=9D = in the other (i.e., covers fewer buffer or string positions), then the inner one will prevail over the outer one. If neither is nested in the other then you should not make assumptions about which overlay will prevail. > > **When a Lisp program puts overlays with defined priorities on text that might have overlays without priorities, this could cause undesirable results, because any overlay with a positive priority value will override all the overlays without a priority.** Since most Emacs features that use overlays don=E2=80=99t specify priorities for their overlays, integer prior= ities should be used with care. Instead of using integer priorities and risk overriding other overlays, you can use priority values of the form (primary . secondary), where the primary value is used as described above, and secondary is the fallback value used when primary and the nesting considerations fail to resolve the precedence between overlays. In particular, priority value (nil . n), with n a positive integer, enables you to have the overlays ordered by priority when necessary without completely overriding other overlays. > > Currently, all overlays take priority over text properties. Even when reading the first sentence of the third paragraph in the documentation, the issue _still_ occurs even if I defined a lower priority for the `display` overlays. NOTE: - The `buffer-invisibility-spec` is correctly set up to support invisibility too, just in case anyone thought that might be the issue. It is not. I am certain of it. ## Question Can anyone explain why this issue only seems to occur when the overlay `(ov 10 37 'invisible t 'priority 10)` is applied but not when `(ov 9 37 'invisible t 'priority 10)` is applied (i.e. why does including the preceding new line make the effect "work")? Is there a finer point of nuance for overlays and the `priority`, `display`, and `invisible` properties? An ancillary note: I _can_ achieve the proper effect, with the proper indexes, by explicitly setting the `display` property to an empty string on the `invisible` overlay: `(ov 10 37 'invisible t 'priority 10 'display "")`= . However, despite this, I still want to properly understand things, why the issue occurs/doesn't seem to make sense, etc. It's not an XY problem. #### Standard environment disclosure: - OS: MacOS - Chip: Intel - Emacs Version: 27.2.1 - Port: Mitsuharu Yamamoto / Railwaycat - Other Notes: - No special distributions / etc. - Relevant Common Packages Used: - ov - Standard internal Emacs packages Thanks, David --0000000000009a47d5062f3c19b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

This bug report is essentially taken fr= om my Emacs Stack Exchange post: https://emacs.stackexchange.com/questions/83169/why-= doesnt-a-prioritized-invisible-overlay-take-precedence-over-non-prioritized=

## Details

I have several overlays being applied to a bu= ffer to replace the `display` property of certain characters. There is also= another overlay being applied (conditionally) for making the nested items/= text `invisible` in _addition_ to changing the `display` property. I set th= e overlay with the `invisible` property to a higher priority (i.e. actually= having a priority), but it is not working as expected.

The characte= r is _still_ being displayed with the alternative `display` character while= _also_ having the `invisible` property set to `t` from the higher priority= overlay.

The only thing that I could find that would _seem_ to expl= ain this behavior was an obscure Reddit thread: https:/= /www.reddit.com/r/emacs/comments/17nxc9s/problem_making_overlays_invisible/= whereby the `display` property apparently takes precedence over `invis= ible`. This makes sense for non-prioritized overlays, however I wouldn'= t imagine this would be correct when there is a `priority` property applied= .

## Reproducible Code/Data

Example code (using `ov` library)= to demonstrate the problem:

```lisp
(ov 1 2 'display "= =E2=80=A2")
(ov 10 12 'display "=E2=98=85")
(ov 19= 21 'display "=E2=98=85")
(ov 28 30 'display "=E2= =98=85")
(ov 10 37 'invisible t 'priority 10)
```
Example data to show the issue (NOTE: - Org mode is irrelevant, it occurs = by executing the code against the same data in a scratch buffer):

``= `text
* Root A
** Sub A
** Sub B
** Sub C
* Root B
** Sub= 1
** Sub 2
** Sub 3
** Sub 4
* Root C
** Sub I
** Sub II=
* Root D
```

The even more confusing issue is that the effect= _would_ seem to work as expected when I change the `invisible` overlay sta= rt index by 1 less (e.g. `(ov 9 37 'invisible t 'priority 10)`). Th= is doesn't seem to logically be consistent.

### Image of Example= Code/Data Reproducing the Issue: https://i.sstatic.net/8cAP29TK.png

*The character at index= position 10 is visible despite having the `invisible` property set to `t` = and the `invisible` overlay having the highest priority.*

## Investi= gation Notes

Even after reviewing the documentation for `overlays` a= nd the `priority` property (https://www.gnu.org/software= /emacs/manual/html_node/elisp/Overlay-Properties.html), it _still_ does= not make sense. The documentation says (emphasis mine):

> This p= roperty=E2=80=99s value determines the priority of the overlay. If you want= to specify a priority value, use either nil (or zero), or a positive integ= er, or a cons of two values. Any other value triggers undefined behavior.>
> **The priority matters when two or more overlays cover the = same character and both specify the same property with different values; th= e one whose priority value is higher overrides the other.** (For the face p= roperty, the higher priority overlay=E2=80=99s value does not completely ov= erride the other value; instead, its individual face attributes override th= e corresponding face attributes of the face property whose priority is lowe= r.) If two overlays have the same priority value, and one is =E2=80=9Cneste= d=E2=80=9D in the other (i.e., covers fewer buffer or string positions), th= en the inner one will prevail over the outer one. If neither is nested in t= he other then you should not make assumptions about which overlay will prev= ail.
>
> **When a Lisp program puts overlays with defined prio= rities on text that might have overlays without priorities, this could caus= e undesirable results, because any overlay with a positive priority value w= ill override all the overlays without a priority.** Since most Emacs featur= es that use overlays don=E2=80=99t specify priorities for their overlays, i= nteger priorities should be used with care. Instead of using integer priori= ties and risk overriding other overlays, you can use priority values of the= form (primary . secondary), where the primary value is used as described a= bove, and secondary is the fallback value used when primary and the nesting= considerations fail to resolve the precedence between overlays. In particu= lar, priority value (nil . n), with n a positive integer, enables you to ha= ve the overlays ordered by priority when necessary without completely overr= iding other overlays.
>
> Currently, all overlays take priorit= y over text properties.

Even when reading the first sentence of the = third paragraph in the documentation, the issue _still_ occurs even if I de= fined a lower priority for the `display` overlays.

NOTE: - The `buff= er-invisibility-spec` is correctly set up to support invisibility too, just= in case anyone thought that might be the issue. It is not. I am certain of= it.

## Question

Can anyone explain why this issue only seems= to occur when the overlay `(ov 10 37 'invisible t 'priority 10)` i= s applied but not when `(ov 9 37 'invisible t 'priority 10)` is app= lied (i.e. why does including the preceding new line make the effect "= work")? Is there a finer point of nuance for overlays and the `priorit= y`, `display`, and `invisible` properties?

An ancillary note: I _can= _ achieve the proper effect, with the proper indexes, by explicitly setting= the `display` property to an empty string on the `invisible` overlay: `(ov= 10 37 'invisible t 'priority 10 'display "")`.
However, despite this, I still want to properly understand things, why th= e issue occurs/doesn't seem to make sense, etc. It's not an XY prob= lem.

#### Standard environment disclosure:

- OS: MacOS
- C= hip: Intel
- Emacs Version: 27.2.1
- Port: Mitsuharu Yamamoto / Railw= aycat
- Other Notes: - No special distributions / etc.
- Relevant Com= mon Packages Used:
=C2=A0 =C2=A0 - ov
=C2=A0 =C2=A0 - Standard intern= al Emacs packages

Thanks,
David
--0000000000009a47d5062f3c19b5-- From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 01 05:36:02 2025 Received: (at 76658) by debbugs.gnu.org; 1 Mar 2025 10:36:02 +0000 Received: from localhost ([127.0.0.1]:33592 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1toKCP-0002wU-Uh for submit@debbugs.gnu.org; Sat, 01 Mar 2025 05:36:02 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54498) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1toKCM-0002vp-To; Sat, 01 Mar 2025 05:35:59 -0500 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 1toKCH-00027P-Ea; Sat, 01 Mar 2025 05:35:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=NcFsETrDgRFpsBr/anL7j2jbQyWJDeWq3j3LbqWG6vo=; b=Tvntqq0b52ZB D7Jg6MtSHDn1pGZhCKfkHgTEivKwtNzB4kDcfqHqrYcRV661DJkZgwWkgjvrEjDmPysAutYFMf8vl iSZAksf5uwyzf6PVfS253L9tBlB6PUc75jBrRy6ET907ydvr+xJ8yBZ2FRmukWrbFz3ovvPZpAPjP hOn31fubPXZDBzVdLwlsEroYfnO7HEOQghpb63cFFjWVy7XxjwuL/ZIntWE8DPxCQxx8SZajjg5LU tgRV4T09VvMD18AV+XSh85d45kKdbfdFgurj20CzATigC3WBTvIHyNv+rbXOneUXU3aWX1kcnLz2v A8JMtjlIVF+tudpl86VPpQ==; Date: Sat, 01 Mar 2025 12:35:49 +0200 Message-Id: <86a5a5qbqy.fsf@gnu.org> From: Eli Zaretskii To: "David's Coding Lounge" In-Reply-To: (davidcodinglounge@gmail.com) Subject: Re: bug#76658: Emacs 27.2; Prioritized invisible overlay is NOT taking precedence over non-prioritized display overlay References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76658 Cc: 76658@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) tags 76658 notabug thanks > From: "David's Coding Lounge" > Date: Fri, 28 Feb 2025 18:23:41 -0500 > > This bug report is essentially taken from my Emacs Stack Exchange post: > https://emacs.stackexchange.com/questions/83169/why-doesnt-a-prioritized-invisible-overlay-take-precedence-over-non-prioritized It is not easy to understand what exactly is the issue which you are reporting and for which you are asking for explanations. Both this report and the linked postings have a lot of stuff, most of which is AFAIU irrelevant. My understanding is that the issue you are asking about is the effect on display of having both 'display' and 'invisible' property start at the same buffer position. If this is not the issue you are asking about, what's below may or may not make sense. When both 'display' and 'invisible' properties start at the same buffer position, and the 'display' property is a "replacing" property (i.e. it instructs Emacs to show something else instead of buffer text), then the 'display' property "wins", in the sense that the invisible property is effectively ignored. This happens due to how the Emacs display engine processes properties: . it processes 'display' properties before 'invisible' . when either a replacing 'display' property or 'invisible' property is found, the display engine completely skips the text covered by the property, so any other properties in the same text are not processed This should explain everything that you see. In particular, overlay priorities have nothing to do with this, since (as the ELisp manual says) the priorities are only examined when two or more overlays have the same property for the same buffer position, which is not the case here. Also, it explains why, if the 'invisible' property starts before 'display', it makes all the text invisible, including the overlay that specifies a 'display' property which shows an image. If you sometimes need to have the image (defined via the 'display' property) to vanish from display, simply remove the 'display' property, or use the conditional 'display' property of the form '(when CONDITION . DISPLAY-SPEC)' and change Lisp variables that affect CONDITION. Bottom line: this is not a bug. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 05 00:56:26 2025 Received: (at 76658) by debbugs.gnu.org; 5 Mar 2025 05:56:26 +0000 Received: from localhost ([127.0.0.1]:34196 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tphk0-0002bR-RM for submit@debbugs.gnu.org; Wed, 05 Mar 2025 00:56:26 -0500 Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]:53344) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tpgNd-0006CT-Oe for 76658@debbugs.gnu.org; Tue, 04 Mar 2025 23:29:15 -0500 Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-30761be8fa8so68895571fa.2 for <76658@debbugs.gnu.org>; Tue, 04 Mar 2025 20:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741148947; x=1741753747; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vJDxTuDTwtXlxfTu1nd/fJVf7E0nsNKZnMqfqA990U0=; b=VwW5fssmihAgnQtLUr1aZtXhp5gYmBs9OxFyFWPPnSYGQ2hp2gqLgflHZzSk/j7C/9 DkSc9tXx+FSqwzwxcGMblh0B8vBZo2BCKcW/2ZW1aND/3d8I5+gFhelj915Rarzi86Ej utzZYCFLvw9Yth6gwpwEUI17xpdHUvori/PwOWIKvHW3Drj4LLVdOxnhZI6bKJb1lJYs uLAv2Da7bZjJScs2cuoictVarSLlsVbyQWTOxqYdTXudWkNY0ajHoYQRPz90LH3Z3DJG B0mlpJYO0JQjstkRgI2sbiS2dh4Ev3WQLjvwAbHfxHK7jToXPVFN+sYsbXRVLw26ddB+ hoTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741148947; x=1741753747; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vJDxTuDTwtXlxfTu1nd/fJVf7E0nsNKZnMqfqA990U0=; b=nqzGKxP9X3AR2dwNTS0GAQfCgN6Zephg9nggthGMxOo5C7ub7CEJEcGxCwlSnnSNTk UKXD4/jhaASAlXIznifKEuLBmKUGckTceli7ML/MUBuf04MobzphD8QJabpuTzcBJ6or qAq+CkCGH8gdtOLuxM+63/+QriVgtp43I/FQPn6m24G3dij/p6lAn46FziruKqLo1Rqs +WjA6dmfknwPNZDAupQsD+d13JQqXiZdFYagtrLHh42Yx+BPkhzmKpkZEgYlH9eut/2Y tqQlihO1H0J+4RQ9hB3T5heGnrW41btAIrA+YAfLm2dG3PZWFt2NgDsncRp8UPlXB5DV Es9A== X-Gm-Message-State: AOJu0YzuPZRQ8x5iu/IzyKH61wS55FvQ4Paiwaf9ihz2RfMo1Jk3QLFr 7WtAaKf28slLXdzsAll6/9b5eDhpDd6+TVLULAoQjBCTK7YjcfxDbbdUxlVsQGzahBCCEQeLYWy THMDqSZryAN94XCrIqTP2WXASpLg= X-Gm-Gg: ASbGncvarE4d8AT4pK80eh8fcrT2pOsB1N6TVAliRnyBopDPoqXbkVIsqwGR8JxPFfK AMet0Y5r9w8KqUiLqf53Ovi6SHQChWM0o9EEPYMfV6dPqaLXX/YlRhTZn8bbnbV+lyrPyPU1q0q ZVwXV5s15xB/h83VwpnOtMM3zWg9KUlBvHpSO3UmbhWJUUe8qSwZYKPeEiAJ8= X-Google-Smtp-Source: AGHT+IHGJ4Ufvyunf9jsT7gI83WSqzUQoQvbhCqWNALd0wzsHyeU1eXqOtTOuZwsCUgLJSWmK54xdD/xNm+qECl95Rk= X-Received: by 2002:a2e:be11:0:b0:30b:bb45:6616 with SMTP id 38308e7fff4ca-30bd7af1aabmr4529841fa.29.1741148946899; Tue, 04 Mar 2025 20:29:06 -0800 (PST) MIME-Version: 1.0 References: <86a5a5qbqy.fsf@gnu.org> In-Reply-To: <86a5a5qbqy.fsf@gnu.org> From: "David's Coding Lounge" Date: Tue, 4 Mar 2025 23:28:55 -0500 X-Gm-Features: AQ5f1JocmCU35MLO4ljOUDOTW98p6FETjyEYPePKiznwF78c7OQFGtMs6HgxbfU Message-ID: Subject: Re: bug#76658: Emacs 27.2; Prioritized invisible overlay is NOT taking precedence over non-prioritized display overlay To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000007b2fa1062f90d41f" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76658 X-Mailman-Approved-At: Wed, 05 Mar 2025 00:56:20 -0500 Cc: 76658@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000007b2fa1062f90d41f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the response, Eli. Your understanding of the problem is correct. Your response both makes sense as well and aligns with what I have encountered in testing. Apologies for the extra information in my posts, but I clearly was confused in my understanding of how the properties of overlays interacted with each other and overlays between themselves. After re-reading the documentation for an Overlay's `priority` property several times before I asked my question, I had a suspicion that it was only relevant on clashing properties that were declared across multiple overlays (i.e. Overlay Priority is a tie-breaker at the individual property level between the same properties, not at the overlay level between overlays: first line of the second paragraph). I was unsure though and thought the behavior I was experiencing was wrong/my understanding of the documentation was incorrect. The clarification and confirmation is appreciated. The behavior around `display` taking precedence over `invisible` is surprising ... somewhat. I am not sure if that is documented anywhere or called out explicitly, I probably missed it if it was. However, stopping to think about the context, it seems to make sense and is logically what would be expected. There is still some doubt I have for certain scenarios and what makes intuitive sense but that is more about me needing to more clearly understand the display engine at a finer level than I currently do (`xdisp.c` here I come). The cases presented thus far make sense, the first overlay processed essentially "wins" and if the starting positioning of an overlay is the same as another with each specifying either `invisible` or `display`, the `display` property value of whichever overlay "wins" (since the underlying text is _essentially_ invisible for all intents and purposes based on what/how `display` works, correct?). In other words, it could be thought of as `display` is `invisible` with benefits: `hide but show something else instead` OR the other way around, `invisible` is functionally equivalent to just `display ""`? To solve my issue, I did end up specifying a `display` property on the `invisible` overlay with a condition similar to the condition applied for `invisible`: `display (if XYZ "")`. It worked, however, at the time it just felt "wrong" or "doing more than it should need to do for the effect desired" (if that makes sense). Thanks for the explanation, clarification, and confirmations Eli! Much appreciated, David On Sat, Mar 1, 2025 at 5:35=E2=80=AFAM Eli Zaretskii wrote: > tags 76658 notabug > thanks > > > From: "David's Coding Lounge" > > Date: Fri, 28 Feb 2025 18:23:41 -0500 > > > > This bug report is essentially taken from my Emacs Stack Exchange post: > > > https://emacs.stackexchange.com/questions/83169/why-doesnt-a-prioritized-= invisible-overlay-take-precedence-over-non-prioritized > > It is not easy to understand what exactly is the issue which you are > reporting and for which you are asking for explanations. Both this > report and the linked postings have a lot of stuff, most of which is > AFAIU irrelevant. > > My understanding is that the issue you are asking about is the effect > on display of having both 'display' and 'invisible' property start at > the same buffer position. If this is not the issue you are asking > about, what's below may or may not make sense. > > When both 'display' and 'invisible' properties start at the same > buffer position, and the 'display' property is a "replacing" property > (i.e. it instructs Emacs to show something else instead of buffer > text), then the 'display' property "wins", in the sense that the > invisible property is effectively ignored. This happens due to how > the Emacs display engine processes properties: > > . it processes 'display' properties before 'invisible' > . when either a replacing 'display' property or 'invisible' property > is found, the display engine completely skips the text covered by > the property, so any other properties in the same text are not > processed > > This should explain everything that you see. In particular, overlay > priorities have nothing to do with this, since (as the ELisp manual > says) the priorities are only examined when two or more overlays have > the same property for the same buffer position, which is not the case > here. Also, it explains why, if the 'invisible' property starts > before 'display', it makes all the text invisible, including the > overlay that specifies a 'display' property which shows an image. > > If you sometimes need to have the image (defined via the 'display' > property) to vanish from display, simply remove the 'display' > property, or use the conditional 'display' property of the form > '(when CONDITION . DISPLAY-SPEC)' and change Lisp variables that > affect CONDITION. > > Bottom line: this is not a bug. > --0000000000007b2fa1062f90d41f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the response, Eli. Your understanding of the pr= oblem is correct. Your response both makes sense as well and aligns with wh= at I have encountered in testing. Apologies for the extra information in my= posts, but I clearly was confused in my understanding of how the propertie= s of overlays interacted with each other and overlays between themselves.
After re-reading the documentation for an Overlay's `priority` pr= operty several times before I asked my question, I had a suspicion that it = was only relevant on clashing properties that were declared across multiple= overlays (i.e. Overlay Priority is a tie-breaker at the individual propert= y level between the same properties, not at the overlay level between overl= ays: first line of the second paragraph). I was unsure though and thought t= he behavior I was experiencing was wrong/my understanding of the documentat= ion was incorrect. The clarification and confirmation is appreciated.
The behavior around `display` taking precedence over `invisible` is surpr= ising ... somewhat. I am not sure if that is documented anywhere or called = out explicitly, I probably missed it if it was. However, stopping to think = about the context, it seems to make sense and is logically what would be ex= pected. There is still some doubt I have for certain scenarios and what mak= es intuitive sense but that is more about me needing to more clearly unders= tand the display engine at a finer level than I currently do (`xdisp.c` her= e I come).

The cases presented thus far make sense, the first overla= y processed essentially "wins" and if the starting positioning of= an overlay is the same as another with each specifying either `invisible` = or `display`, the `display` property value of whichever overlay "wins&= quot; (since the underlying text is _essentially_ invisible for all intents= and purposes based on what/how `display` works, correct?). In other words,= it could be thought of as `display` is `invisible` with benefits: `hide bu= t show something else instead` OR the other way around, `invisible` is func= tionally equivalent to just `display ""`?

To solve my issu= e, I did end up specifying a `display` property on the `invisible` overlay = with a condition similar to the condition applied for `invisible`: `display= (if XYZ "")`. It worked, however, at the time it just felt "= ;wrong" or "doing more than it should need to do for the effect d= esired" (if that makes sense).

Thanks for the explanation, clar= ification, and confirmations Eli!

Much appreciated,
David

On Sat, Mar 1, 2025 at 5:35=E2=80=AFAM Eli Zaretskii <= eliz@gnu.org> wrote:
tags 76658 notabug
thanks

> From: "David's Coding Lounge" <davidcodinglounge@gmail.com&= gt;
> Date: Fri, 28 Feb 2025 18:23:41 -0500
>
> This bug report is essentially taken from my Emacs Stack Exchange post= :
> https://emacs.stackexchange.com/questions= /83169/why-doesnt-a-prioritized-invisible-overlay-take-precedence-over-non-= prioritized

It is not easy to understand what exactly is the issue which you are
reporting and for which you are asking for explanations.=C2=A0 Both this report and the linked postings have a lot of stuff, most of which is
AFAIU irrelevant.

My understanding is that the issue you are asking about is the effect
on display of having both 'display' and 'invisible' propert= y start at
the same buffer position.=C2=A0 If this is not the issue you are asking
about, what's below may or may not make sense.

When both 'display' and 'invisible' properties start at the= same
buffer position, and the 'display' property is a "replacing&qu= ot; property
(i.e. it instructs Emacs to show something else instead of buffer
text), then the 'display' property "wins", in the sense t= hat the
invisible property is effectively ignored.=C2=A0 This happens due to how the Emacs display engine processes properties:

=C2=A0 . it processes 'display' properties before 'invisible= 9;
=C2=A0 . when either a replacing 'display' property or 'invisib= le' property
=C2=A0 =C2=A0 is found, the display engine completely skips the text covere= d by
=C2=A0 =C2=A0 the property, so any other properties in the same text are no= t
=C2=A0 =C2=A0 processed

This should explain everything that you see.=C2=A0 In particular, overlay priorities have nothing to do with this, since (as the ELisp manual
says) the priorities are only examined when two or more overlays have
the same property for the same buffer position, which is not the case
here.=C2=A0 Also, it explains why, if the 'invisible' property star= ts
before 'display', it makes all the text invisible, including the overlay that specifies a 'display' property which shows an image.
If you sometimes need to have the image (defined via the 'display'<= br> property) to vanish from display, simply remove the 'display'
property, or use the conditional 'display' property of the form
'(when CONDITION . DISPLAY-SPEC)' and change Lisp variables that affect CONDITION.

Bottom line: this is not a bug.
--0000000000007b2fa1062f90d41f-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 05 08:22:36 2025 Received: (at 76658-done) by debbugs.gnu.org; 5 Mar 2025 13:22:36 +0000 Received: from localhost ([127.0.0.1]:36109 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tpohn-0001JB-Vv for submit@debbugs.gnu.org; Wed, 05 Mar 2025 08:22:36 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37542) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tpohl-0001Iv-CE for 76658-done@debbugs.gnu.org; Wed, 05 Mar 2025 08:22:34 -0500 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 1tpohc-0002cY-Jw; Wed, 05 Mar 2025 08:22:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=wHsOdMumTThSRaDencardoAODGrQ96qfSDWxxI+KyOE=; b=Aq5Q4BSu03lT TLuF3e0t9U7rg63hbMitXbjelOcKjaILYkdp/iI0eoL5/idKYY5AD3lDkpbQ+IlUi+Asxqxakhn/R FlEds8QXelvRpDefkol8Q7+MmzIYuMvDVqbWW8XNymu0dSA/Efl/+329s/KzPbMae9zuYAxndmYKP yGFb/jeyq4Ghe/zR8RQ8H/2VFSNqnE+CtSm+cfZeZ/gpX5VUGa+nB5O9pXXu4pX8KwlIphYIISny1 bcvQi+6CUcD08Cjgzh3tE86Lse9lON/ZIv4PESWhSBYCjs8Z1ABhIaiP8qV7GjEc3WDPrpeKsg37g Dr6xs7U9A1V6vEryb5qryQ==; Date: Wed, 05 Mar 2025 15:22:20 +0200 Message-Id: <861pvbpq7n.fsf@gnu.org> From: Eli Zaretskii To: "David's Coding Lounge" In-Reply-To: (davidcodinglounge@gmail.com) Subject: Re: bug#76658: Emacs 27.2; Prioritized invisible overlay is NOT taking precedence over non-prioritized display overlay References: <86a5a5qbqy.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76658-done Cc: 76658-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: "David's Coding Lounge" > Date: Tue, 4 Mar 2025 23:28:55 -0500 > Cc: 76658@debbugs.gnu.org > > The behavior around `display` taking precedence over `invisible` is surprising ... somewhat. I am not sure if > that is documented anywhere or called out explicitly, I probably missed it if it was. It wasn't documented until now, but I added it notes to the ELisp manual about it, since you are not the first one bumping into this subtlety. > The cases presented thus far make sense, the first overlay processed essentially "wins" and if the starting > positioning of an overlay is the same as another with each specifying either `invisible` or `display`, the > `display` property value of whichever overlay "wins" (since the underlying text is _essentially_ invisible for all > intents and purposes based on what/how `display` works, correct?). In other words, it could be thought of as > `display` is `invisible` with benefits: `hide but show something else instead` OR the other way around, > `invisible` is functionally equivalent to just `display ""`? Right. > To solve my issue, I did end up specifying a `display` property on the `invisible` overlay with a condition > similar to the condition applied for `invisible`: `display (if XYZ "")`. It worked, however, at the time it just felt > "wrong" or "doing more than it should need to do for the effect desired" (if that makes sense). > > Thanks for the explanation, clarification, and confirmations Eli! Thanks, I'm therefore closing this bug. From unknown Mon Jun 16 23:32:46 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 03 Apr 2025 11:24:15 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator