GNU bug report logs -
#76658
Emacs 27.2; Prioritized invisible overlay is NOT taking precedence over non-prioritized display overlay
Previous Next
Full log
Message #18 received at 76658-done <at> debbugs.gnu.org (full text, mbox):
> From: "David's Coding Lounge" <davidcodinglounge <at> gmail.com>
> Date: Tue, 4 Mar 2025 23:28:55 -0500
> Cc: 76658 <at> 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.
This bug report was last modified 73 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.