GNU bug report logs -
#14542
24.3.50; Simultaneous use of display and invisible properties
Previous Next
Reported by: Jambunathan K <kjambunathan <at> gmail.com>
Date: Mon, 3 Jun 2013 04:37:02 UTC
Severity: minor
Found in version 24.3.50
Done: Jambunathan K <kjambunathan <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14542 in the body.
You can then email your comments to 14542 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#14542
; Package
emacs
.
(Mon, 03 Jun 2013 04:37:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jambunathan K <kjambunathan <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 03 Jun 2013 04:37:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I have a piece of text that has both invisible and display property set.
The underlying buffer text is invisible but the display engine displays
the overlay string. i.e., In the example below, I can see {org-defkey}
in my monitor. The underlying character "1..." etc is hidden.
This bug is merely to check whether the above behaviour is as intended
or a "unknown" side-effect. I have looked at (info "(elisp) Replacing
Specs"). I am not sure whether the 'invisible property counts as a
display spec. I think it is worth clarifying the desgin or
implementation detail in the Elisp manual.
Just in case it matters, the 'display property is added right after
(insert ...) operation. The invisible property is added as part of
font-lock operation.
,---- (text-properties-at (point))
| (invisible t fontified t display
| #("{org-defkey}" 0 12
| (face font-lock-function-name-face)))
`----
,---- (overlays-at (point))
| nil
`----
,---- C-u C-x =
| position: 122 of 2707 (4%), column: 4
| character: 1 (displayed as 1) (codepoint 49, #o61, #x31)
| preferred charset: ascii (ASCII (ISO646 IRV))
|
| There are text properties here:
| display [Show]
| fontified t
| invisible t
|
| [back]
`----
GNU Emacs 24.3.50.2 (i686-pc-linux-gnu, GTK+ Version 2.20.1)
of 2013-06-03 on debian-6.05
Bzr revision: 112824 rgm <at> gnu.org-20130602182638-wbn53t13ukjyzxq5
Windowing system distributor `The X.Org Foundation', version 11.0.10707000
Important settings:
value of $LANG: en_IN
locale-coding-system: iso-latin-1-unix
default enable-multibyte-characters: t
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#14542
; Package
emacs
.
(Mon, 03 Jun 2013 15:52:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 14542 <at> debbugs.gnu.org (full text, mbox):
> From: Jambunathan K <kjambunathan <at> gmail.com>
> Date: Mon, 03 Jun 2013 10:04:51 +0530
>
>
> I have a piece of text that has both invisible and display property set.
> The underlying buffer text is invisible but the display engine displays
> the overlay string. i.e., In the example below, I can see {org-defkey}
> in my monitor. The underlying character "1..." etc is hidden.
>
> This bug is merely to check whether the above behaviour is as intended
> or a "unknown" side-effect.
It's undefined behavior. What you see is a consequence of how the
display engine implements application of text properties. When the
same buffer or string position has more than one property change, the
display engine applies them in this order:
. 'fontified'
. 'face'
. 'display'
. 'invisible'
. 'composition'
When 2 properties remove text from display in different ways, the
result depends on the order.
> I have looked at (info "(elisp) Replacing Specs"). I am not sure
> whether the 'invisible property counts as a display spec.
It doesn't. Display specs are limited to 'display' properties (and
not all of them are "replacing"). The 'invisible' property just makes
the text invisible on display.
> I think it is worth clarifying the desgin or implementation detail
> in the Elisp manual.
Not sure we should leak the implementation into the documentation.
This code is unaltered since it was written 13 years ago, and I don't
think I ever heard any questions about this particular situation. I
guess it's sufficiently rare.
Reply sent
to
Jambunathan K <kjambunathan <at> gmail.com>
:
You have taken responsibility.
(Fri, 15 Nov 2013 05:21:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
Jambunathan K <kjambunathan <at> gmail.com>
:
bug acknowledged by developer.
(Fri, 15 Nov 2013 05:21:04 GMT)
Full text and
rfc822 format available.
Message #13 received at 14542-done <at> debbugs.gnu.org (full text, mbox):
OP here. Closed.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 13 Dec 2013 12:24:13 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 years and 250 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.