unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Tassilo Horn <tsdh@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: How to solve overlay conflict between invisible and display?
Date: Wed, 17 Jul 2024 10:16:01 +0200	[thread overview]
Message-ID: <87o76wl9ha.fsf@gnu.org> (raw)

Hi all,

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.

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.  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---

In my scenario, I would like that the outer invisible overlay also hides
the nested display overlays.

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?

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.

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)?

Thanks,
  Tassilo

[1] https://github.com/magit/magit/issues/5176



             reply	other threads:[~2024-07-17  8:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-17  8:16 Tassilo Horn [this message]
2024-07-17 12:13 ` How to solve overlay conflict between invisible and display? Eli Zaretskii
2024-07-19  7:02   ` Tassilo Horn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o76wl9ha.fsf@gnu.org \
    --to=tsdh@gnu.org \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).