GNU bug report logs -
#40687
Missing right border on composed text used in 'display property
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40687 in the body.
You can then email your comments to 40687 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#40687
; Package
emacs
.
(Fri, 17 Apr 2020 19:45:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Clément Pit-Claudel <cpitclaudel <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 17 Apr 2020 19:45:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi all,
With the following sample code, I observe the results shown in the attached image. The first two "ab" have a border, but the last one only has three-quarters of its border: the right side is missing.
(defface my-button
'((t :box(:line-width -4 :style released-button)
:background"lightgrey":foreground"black"))
"Button face")
(with-current-buffer (get-buffer-create "button")
(insert "\n")
(insert (propertize "ab" 'face 'my-button))
(insert " ")
(insert (propertize (compose-chars ?a '(Br . Bl) ?b) 'face 'my-button))
(insert " ")
(insert (propertize "ab" 'display (compose-chars ?a '(Br . Bl) ?b) 'face 'my-button))
(insert " ")
(pop-to-buffer-same-window (current-buffer)))
Clément.
In GNU Emacs 28.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.22.30, cairo version 1.15.10)
of 2020-03-15 built on clem-w50-mint
Repository revision: 9dccaf8a5cdb10dae597345ec3741475477a7d97
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Linux Mint 19.3
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD
JSON PDUMPER LCMS2 GMP
Important settings:
value of $LC_MONETARY: en_DK.UTF-8
value of $LC_NUMERIC: en_DK.UTF-8
value of $LC_TIME: en_DK.UTF-8
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Fundamental
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 45833 8246)
(symbols 48 6336 1)
(strings 32 15876 1701)
(string-bytes 1 514312)
(vectors 16 10216)
(vector-slots 8 138591 9384)
(floats 8 19 45)
(intervals 56 188 0)
(buffers 1000 12))
[truncated-border.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40687
; Package
emacs
.
(Fri, 17 Apr 2020 20:34:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 40687 <at> debbugs.gnu.org (full text, mbox):
On Fri, 17 Apr 2020 15:44:36 -0400 Clément Pit-Claudel <cpitclaudel <at> gmail.com> wrote:
> Hi all,
>
> With the following sample code, I observe the results shown in the attached image. The first two "ab" have a border, but the last one only has three-quarters of its border: the right side is missing.
>
> (defface my-button
> '((t :box(:line-width -4 :style released-button)
> :background"lightgrey":foreground"black"))
> "Button face")
>
> (with-current-buffer (get-buffer-create "button")
> (insert "\n")
> (insert (propertize "ab" 'face 'my-button))
> (insert " ")
> (insert (propertize (compose-chars ?a '(Br . Bl) ?b) 'face 'my-button))
> (insert " ")
> (insert (propertize "ab" 'display (compose-chars ?a '(Br . Bl) ?b) 'face 'my-button))
> (insert " ")
> (pop-to-buffer-same-window (current-buffer)))
I see the same thing, but I noticed that when you add a space to
composed characters of the display property, ie.:
(compose-chars ?a '(Br . Bl) ?b ? )
then right side border appears.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40687
; Package
emacs
.
(Fri, 17 Apr 2020 21:12:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 40687 <at> debbugs.gnu.org (full text, mbox):
On 17/04/2020 16.33, Stephen Berman wrote:
> On Fri, 17 Apr 2020 15:44:36 -0400 Clément Pit-Claudel <cpitclaudel <at> gmail.com> wrote:
>
>> Hi all,
>>
>> With the following sample code, I observe the results shown in the attached image. The first two "ab" have a border, but the last one only has three-quarters of its border: the right side is missing.
>>
>> (defface my-button
>> '((t :box(:line-width -4 :style released-button)
>> :background"lightgrey":foreground"black"))
>> "Button face")
>>
>> (with-current-buffer (get-buffer-create "button")
>> (insert "\n")
>> (insert (propertize "ab" 'face 'my-button))
>> (insert " ")
>> (insert (propertize (compose-chars ?a '(Br . Bl) ?b) 'face 'my-button))
>> (insert " ")
>> (insert (propertize "ab" 'display (compose-chars ?a '(Br . Bl) ?b) 'face 'my-button))
>> (insert " ")
>> (pop-to-buffer-same-window (current-buffer)))
>
> I see the same thing, but I noticed that when you add a space to
> composed characters of the display property, ie.:
> (compose-chars ?a '(Br . Bl) ?b ? )
> then right side border appears.
IIUC, this space is read as the number 32 and considered as the encoded version of the rule (tr . br). Indeed, this gives the same result:
(insert (propertize "ab" 'display (compose-chars ?a '(Bc . Bc) ?b '(tr . br)) 'face 'my-button))
But is that even a valid composition rule?It seems to break with non-trivial composition, like the following:
(insert (propertize "ab" 'display (compose-chars ?a '(Bc . Bc) ?b ? ) 'face 'my-button))
(instead of being stacked, a and b are side by side)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40687
; Package
emacs
.
(Thu, 23 Apr 2020 15:49:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 40687 <at> debbugs.gnu.org (full text, mbox):
> From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
> Date: Fri, 17 Apr 2020 15:44:36 -0400
>
> With the following sample code, I observe the results shown in the attached image. The first two "ab" have a border, but the last one only has three-quarters of its border: the right side is missing.
>
> (defface my-button
> '((t :box(:line-width -4 :style released-button)
> :background"lightgrey":foreground"black"))
> "Button face")
>
> (with-current-buffer (get-buffer-create "button")
> (insert "\n")
> (insert (propertize "ab" 'face 'my-button))
> (insert " ")
> (insert (propertize (compose-chars ?a '(Br . Bl) ?b) 'face 'my-button))
> (insert " ")
> (insert (propertize "ab" 'display (compose-chars ?a '(Br . Bl) ?b) 'face 'my-button))
> (insert " ")
> (pop-to-buffer-same-window (current-buffer)))
Thanks, should be fixed now.
FTR, a recipe to test more fully display of composed text with a :box
face is below. I found quite a few problems with this, especially
when the text in the boxed face ends with a composed character. They
should be fixed now on the master branch. I tested this fully only on
MS-Windows; could someone please use the recipe below to verify the
display looks correctly also on X and on NS? Note that what appears
below to be LATIN SMALL LETTER A WITH ACUTE is not a single character,
but 2 characters that are composed into a single glyph.
(defface my-button
'((t :box(:line-width -4 :style released-button)
:background"lightgrey":foreground"black"))
"Button face")
(with-current-buffer (get-buffer-create "button")
(insert "\n")
(insert " ")
(insert (propertize "ab" 'face 'my-button))
(insert " ")
(insert "\n")
(insert " ")
(insert (propertize (compose-chars ?a '(Br . Bl) ?b) 'face 'my-button))
(insert " ")
(insert "\n")
(insert " ")
(insert (propertize "ab" 'display (compose-chars ?a '(Br . Bl) ?b) 'face 'my-button))
(insert " ")
(insert "\n")
(insert " ")
(insert (propertize "xá" 'face 'my-button))
(insert " ")
(insert "\n")
(insert " ")
(insert (propertize "Khmer (ភាសាខ្មែរ) ជំរាបសួរ" 'face 'my-button))
(insert " ")
(pop-to-buffer-same-window (current-buffer)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40687
; Package
emacs
.
(Thu, 23 Apr 2020 15:50:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 40687 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Date: Fri, 17 Apr 2020 22:33:48 +0200
> Cc: 40687 <at> debbugs.gnu.org
>
> I see the same thing, but I noticed that when you add a space to
> composed characters of the display property, ie.:
> (compose-chars ?a '(Br . Bl) ?b ? )
> then right side border appears.
Yes, because the bug only happened when a display string _ended_ in a
composition.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40687
; Package
emacs
.
(Thu, 23 Apr 2020 20:08:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 40687 <at> debbugs.gnu.org (full text, mbox):
On Thu, 23 Apr 2020 18:48:09 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
>> Date: Fri, 17 Apr 2020 15:44:36 -0400
>>
>> With the following sample code, I observe the results shown in the
>> attached image. The first two "ab" have a border, but the last one
>> only has three-quarters of its border: the right side is missing.
>>
>> (defface my-button
>> '((t :box(:line-width -4 :style released-button)
>> :background"lightgrey":foreground"black"))
>> "Button face")
>>
>> (with-current-buffer (get-buffer-create "button")
>> (insert "\n")
>> (insert (propertize "ab" 'face 'my-button))
>> (insert " ")
>> (insert (propertize (compose-chars ?a '(Br . Bl) ?b) 'face 'my-button))
>> (insert " ")
>> (insert (propertize "ab" 'display (compose-chars ?a '(Br . Bl) ?b) 'face 'my-button))
>> (insert " ")
>> (pop-to-buffer-same-window (current-buffer)))
>
> Thanks, should be fixed now.
>
> FTR, a recipe to test more fully display of composed text with a :box
> face is below. I found quite a few problems with this, especially
> when the text in the boxed face ends with a composed character. They
> should be fixed now on the master branch. I tested this fully only on
> MS-Windows; could someone please use the recipe below to verify the
> display looks correctly also on X and on NS?
I'm on GNU/Linux and confirm that with your patch all the buttons
produced by your recipe display correctly, i.e., with the right border.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40687
; Package
emacs
.
(Thu, 23 Apr 2020 20:26:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 40687 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 23/04/2020 16.07, Stephen Berman wrote:
> On Thu, 23 Apr 2020 18:48:09 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Thanks, should be fixed now.
>>
> I'm on GNU/Linux and confirm that with your patch all the buttons
> produced by your recipe display correctly, i.e., with the right border.
Same here, on GNU/Linux + X as well. Everything looks great. Thanks a lot!
> Note that what appears
> below to be LATIN SMALL LETTER A WITH ACUTE is not a single character,
> but 2 characters that are composed into a single glyph.
I think I must have a configuration issue somewhere. In Emacs, the accent is drawn next to the a (on the right side of it), inside the button (I have attached a screenshot)
This isn't a new problem, and it's not due to borders (the code of the repro has the same display issue, and my Emacs always behaved like this, I think), but maybe it's worth a separate bug report?
Clément.
[button.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40687
; Package
emacs
.
(Fri, 24 Apr 2020 06:35:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 40687 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Clément Pit-Claudel <cpitclaudel <at> gmail.com>,
> 40687 <at> debbugs.gnu.org
> Date: Thu, 23 Apr 2020 22:07:21 +0200
>
> > FTR, a recipe to test more fully display of composed text with a :box
> > face is below. I found quite a few problems with this, especially
> > when the text in the boxed face ends with a composed character. They
> > should be fixed now on the master branch. I tested this fully only on
> > MS-Windows; could someone please use the recipe below to verify the
> > display looks correctly also on X and on NS?
>
> I'm on GNU/Linux and confirm that with your patch all the buttons
> produced by your recipe display correctly, i.e., with the right border.
Thanks for testing, much appreciated.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40687
; Package
emacs
.
(Fri, 24 Apr 2020 06:45:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 40687 <at> debbugs.gnu.org (full text, mbox):
> Cc: 40687 <at> debbugs.gnu.org
> From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
> Date: Thu, 23 Apr 2020 16:25:18 -0400
>
> On 23/04/2020 16.07, Stephen Berman wrote:
> > On Thu, 23 Apr 2020 18:48:09 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> Thanks, should be fixed now.
> >>
> > I'm on GNU/Linux and confirm that with your patch all the buttons
> > produced by your recipe display correctly, i.e., with the right border.
>
> Same here, on GNU/Linux + X as well. Everything looks great. Thanks a lot!
Great, thanks.
> > Note that what appears
> > below to be LATIN SMALL LETTER A WITH ACUTE is not a single character,
> > but 2 characters that are composed into a single glyph.
>
> I think I must have a configuration issue somewhere. In Emacs, the accent is drawn next to the a (on the right side of it), inside the button (I have attached a screenshot)
> This isn't a new problem, and it's not due to borders (the code of the repro has the same display issue, and my Emacs always behaved like this, I think), but maybe it's worth a separate bug report?
I don't think it's a bug. It's likely just an issue with the font(s)
you are using If you insert this pair of codepoints in a buffer, can
you move point between them with C-f and C-b? If you can, it means
they are not composed for some reason, perhaps the font you are using
doesn't have a glyph for the acute accent, so Emacs uses a different
font for it, and thus is unable to compose. Try a different font.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40687
; Package
emacs
.
(Fri, 24 Apr 2020 12:12:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 40687 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 23 Apr 2020 18:48:09 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
Eli> Thanks, should be fixed now.
Eli> FTR, a recipe to test more fully display of composed text with a :box
Eli> face is below. I found quite a few problems with this, especially
Eli> when the text in the boxed face ends with a composed character. They
Eli> should be fixed now on the master branch. I tested this fully only on
Eli> MS-Windows; could someone please use the recipe below to verify the
Eli> display looks correctly also on X and on NS? Note that what appears
Eli> below to be LATIN SMALL LETTER A WITH ACUTE is not a single character,
Eli> but 2 characters that are composed into a single glyph.
It all looks correct on NS as well (once I switched to a font that had both
an 'a' and a COMBINING ACUTE ACCENT glyph, Menlo in this case)
Robert
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Fri, 24 Apr 2020 12:28:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Clément Pit-Claudel <cpitclaudel <at> gmail.com>
:
bug acknowledged by developer.
(Fri, 24 Apr 2020 12:28:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 40687-done <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Clément Pit-Claudel <cpitclaudel <at> gmail.com>,
> 40687 <at> debbugs.gnu.org
> Date: Fri, 24 Apr 2020 14:10:57 +0200
>
> >>>>> On Thu, 23 Apr 2020 18:48:09 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>
> Eli> Thanks, should be fixed now.
>
> Eli> FTR, a recipe to test more fully display of composed text with a :box
> Eli> face is below. I found quite a few problems with this, especially
> Eli> when the text in the boxed face ends with a composed character. They
> Eli> should be fixed now on the master branch. I tested this fully only on
> Eli> MS-Windows; could someone please use the recipe below to verify the
> Eli> display looks correctly also on X and on NS? Note that what appears
> Eli> below to be LATIN SMALL LETTER A WITH ACUTE is not a single character,
> Eli> but 2 characters that are composed into a single glyph.
>
> It all looks correct on NS as well (once I switched to a font that had both
> an 'a' and a COMBINING ACUTE ACCENT glyph, Menlo in this case)
Great, so I'm closing this bug. Thanks to all who supported the
testing of the fix.
P.S. FTR: the fix is on the master branch, so it will be in Emacs
28.1.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40687
; Package
emacs
.
(Fri, 24 Apr 2020 14:02:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 40687-done <at> debbugs.gnu.org (full text, mbox):
On 24/04/2020 08.26, Eli Zaretskii wrote:
> Great, so I'm closing this bug. Thanks to all who supported the
> testing of the fix.
Thanks for your hard work.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40687
; Package
emacs
.
(Fri, 24 Apr 2020 14:07:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 40687-done <at> debbugs.gnu.org (full text, mbox):
> Cc: 40687-done <at> debbugs.gnu.org
> From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
> Date: Fri, 24 Apr 2020 10:01:43 -0400
>
> On 24/04/2020 08.26, Eli Zaretskii wrote:
> > Great, so I'm closing this bug. Thanks to all who supported the
> > testing of the fix.
>
> Thanks for your hard work.
Thanks for an interesting use case that happened to teach me several
things I didn't know.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 23 May 2020 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 28 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.