bug#26742: Display bug with composed strings

bug#26742: Display bug with composed strings

[Clément Pit--Claudel]

[-- Attachment #1.1.1: Type: text/plain, Size: 3999 bytes --]

Hi bug-gnu-emacs,

If I create a file temp.txt containing the following:

-*- prettify-symbols-alist: (("R_PO" 8477 (Br . cl) 8804)); -*-
!!! R_PO !!!

and run ‘emacs-24.5 -Q temp.txt -f prettify-symbols-mode’, I observe a surprising display bug: when I move the point across the second line, as soon as the point reaches the blank space after “R_PO”, I see a second ℝ displayed instead of the third “!”.

Concretely, the line looks like “!!! ℝ≤ !!!” until I reach the second blank, and then it changes to “!!ℝ ℝ≤ !!!”.  Resizing the window fixes the issue until the next cursor blink.  Additionally, when the point is on R_PO, the point disappears — and taking a screenshot makes the prettified R_PO (ℝ≤) disappear, too (?!).

Is this a known issue? Can anyone else reproduce it? I have attached a few pictures (all of them show the same buffer text) — let me know if I can provide any other info!

Cheers,
Clément.

In GNU Emacs 26.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2017-04-16 built on clem-w50-mint
Repository revision: d1a65963ff50d2ebae87ac559514e19788ffc1cc
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description:	Linux Mint 18.1 Serena

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 LIBSYSTEMD

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: Lisp Interaction

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
  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 puny seq byte-opt subr-x gv
bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils time-date mule-util 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 menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame 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 case-table epa-hook jka-cmpr-hook help
simple abbrev obarray minibuffer 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 dbusbind inotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 96057 5153)
 (symbols 48 20438 1)
 (miscs 40 40 129)
 (strings 32 18025 4822)
 (string-bytes 1 576763)
 (vectors 16 14137)
 (vector-slots 8 485275 4358)
 (floats 8 48 68)
 (intervals 56 203 0)
 (buffers 976 11)
 (heap 1024 47991 1074))

[-- Attachment #1.1.2: Screenshot from 2017-05-02 02-53-09.png --]
[-- Type: image/png, Size: 15263 bytes --]

[-- Attachment #1.1.3: Screenshot from 2017-05-02 02-53-30.png --]
[-- Type: image/png, Size: 16067 bytes --]

[-- Attachment #1.1.4: Screenshot from 2017-05-02 02-53-43.png --]
[-- Type: image/png, Size: 18364 bytes --]

[-- Attachment #1.1.5: Screenshot from 2017-05-02 02-53-51.png --]
[-- Type: image/png, Size: 16535 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#26742: Display bug with composed strings

[Eli Zaretskii]

> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Tue, 2 May 2017 02:58:19 -0400
> 
> If I create a file temp.txt containing the following:
> 
> -*- prettify-symbols-alist: (("R_PO" 8477 (Br . cl) 8804)); -*-
> !!! R_PO !!!
> 
> and run ‘emacs-24.5 -Q temp.txt -f prettify-symbols-mode’, I observe a surprising display bug: when I move the point across the second line, as soon as the point reaches the blank space after “R_PO”, I see a second ℝ displayed instead of the third “!”.
> 
> Concretely, the line looks like “!!! ℝ≤ !!!” until I reach the second blank, and then it changes to “!!ℝ ℝ≤ !!!”.  Resizing the window fixes the issue until the next cursor blink.  Additionally, when the point is on R_PO, the point disappears — and taking a screenshot makes the prettified R_PO (ℝ≤) disappear, too (?!).
> 
> Is this a known issue? Can anyone else reproduce it? I have attached a few pictures (all of them show the same buffer text) — let me know if I can provide any other info!

I cannot reproduce this on my system, neither in Emacs 24.5 nor in
25.2 nor in the current master.

If you change the font use for displaying ℝ and ≤, does the problem go
away?

bug#26742: Display bug with composed strings

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 224 bytes --]

On 2017-05-02 04:15, Eli Zaretskii wrote:
> If you change the font use for displaying ℝ and ≤, does the problem go
> away?

No: it seems to happen both in my heavily-customized Emacs and in emacs -Q.

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#26742: Display bug with composed strings

[Eli Zaretskii]

> Cc: 26742@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Tue, 2 May 2017 11:40:08 -0400
> 
> On 2017-05-02 04:15, Eli Zaretskii wrote:
> > If you change the font use for displaying ℝ and ≤, does the problem go
> > away?
> 
> No: it seems to happen both in my heavily-customized Emacs and in emacs -Q.

That doesn't necessarily answer my question, unless the font used to
display those two characters is different in "emacs -Q" and in your
customized session.

If both use the same font, please try forcing Emacs to use some other
font, perhaps one that is more wide-spread on GNU/Linux systems, and
see if that changes anything.

If that doesn't help, then the next question is: is this problem
specific to these two characters, or is it more general?  If the
latter, I suspect the shaping engine used in your case is the culprit,
so perhaps upgrade your libotf, libm17n-flt, and m17n-db packages.  If
you already have the latest versions of these, it would be time to ask
Handa-san to chime in and look into this.

bug#26742: Display bug with composed strings

[Andreas Schwab]

On Mai 02 2017, Eli Zaretskii <eliz@gnu.org> wrote:

> If both use the same font, please try forcing Emacs to use some other
> font, perhaps one that is more wide-spread on GNU/Linux systems, and
> see if that changes anything.

I see the same effect, if I use Droid Sans Mono as the default font, but
not with DejaVu Sans Mono (in the latter case both characters are
selected from this font).

The component character(s) are displayed by these fonts (glyph codes):
 ℝ: xft:-unknown-Linux Libertine O-normal-normal-normal-*-15-*-*-*-*-0-iso10646-1 (#x748)
 ≤: xft:-unknown-Droid Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1 (#x231)

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#26742: Display bug with composed strings

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1631 bytes --]

On 2017-05-02 12:46, Eli Zaretskii wrote:
>> Cc: 26742@debbugs.gnu.org From: Clément Pit--Claudel
>> <clement.pitclaudel@live.com> Date: Tue, 2 May 2017 11:40:08 -0400
>> 
>> On 2017-05-02 04:15, Eli Zaretskii wrote:
>>> If you change the font use for displaying ℝ and ≤, does the
>>> problem go away?
>> 
>> No: it seems to happen both in my heavily-customized Emacs and in
>> emacs -Q.
> 
> That doesn't necessarily answer my question, unless the font used to 
> display those two characters is different in "emacs -Q" and in your 
> customized session.

For ℝ, "emacs -Q" uses "Latin Modern Math" and "emacs" with customizations uses "XITS Math". 
For ≤, both use Ubuntu Mono.  I changed the default font and noticed slightly different glitches, including with a variable-pitch font multiple "!" disappearing.

> If that doesn't help, then the next question is: is this problem 
> specific to these two characters, or is it more general?

More investigation suggests that the problem only happens when both parts of the composition are not displayed with the same font.  For example, if I set my default font to Latin Modern Math, the problem goes away.

> If the latter, I suspect the shaping engine used in your case is the
> culprit, so perhaps upgrade your libotf, libm17n-flt, and m17n-db
> packages.  

Apt tells me these packages are up-to-date, but it might not be offering me the very-latest version:

$ apt show libotf0
Package: libotf0
Version: 0.9.13-3

$ apt show libm17n-0
Package: libm17n-0
Version: 1.7.0-3

$ apt show m17n-db
Package: m17n-db
Version: 1.7.0-2


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#26742: Display bug with composed strings

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Clément Pit--Claudel <clement.pitclaudel@live.com>,
>   26742@debbugs.gnu.org
> Date: Tue, 02 May 2017 19:18:22 +0200
> 
> I see the same effect, if I use Droid Sans Mono as the default font, but
> not with DejaVu Sans Mono (in the latter case both characters are
> selected from this font).
> 
> The component character(s) are displayed by these fonts (glyph codes):
>  ℝ: xft:-unknown-Linux Libertine O-normal-normal-normal-*-15-*-*-*-*-0-iso10646-1 (#x748)
>  ≤: xft:-unknown-Droid Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1 (#x231)

Aha, so this is somehow font-depended after all.  Thanks.

For the record, on my system, the problem doesn't happen even if the
two characters are displayed using different fonts:

  The component character(s) are displayed by these fonts (glyph codes):
   ℝ: uniscribe:-outline-Symbola-normal-normal-normal-serif-13-*-*-*-p-*-iso10646-1 (#x471)
   ≤: uniscribe:-outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x94)

Does anything change if you add

  --eval "(setq use-default-font-for-symbols nil)"

to the Emacs command line, before the file name to visit?  In my case,
this still doesn't reproduce the problem, and the two characters still
use 2 different fonts, although ≤ now uses a different font, not the
one used by the default face.

bug#26742: Display bug with composed strings

[Eli Zaretskii]

> Cc: 26742@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Tue, 2 May 2017 13:22:19 -0400
> 
> For ℝ, "emacs -Q" uses "Latin Modern Math" and "emacs" with customizations uses "XITS Math". 
> For ≤, both use Ubuntu Mono.  I changed the default font and noticed slightly different glitches, including with a variable-pitch font multiple "!" disappearing.

Could you try fonts mentioned by Andreas?

> > If that doesn't help, then the next question is: is this problem 
> > specific to these two characters, or is it more general?
> 
> More investigation suggests that the problem only happens when both parts of the composition are not displayed with the same font.  For example, if I set my default font to Latin Modern Math, the problem goes away.

Does the problem affect other characters as well, or just these two?

> > If the latter, I suspect the shaping engine used in your case is the
> > culprit, so perhaps upgrade your libotf, libm17n-flt, and m17n-db
> > packages.  
> 
> Apt tells me these packages are up-to-date, but it might not be offering me the very-latest version:
> 
> $ apt show libotf0
> Package: libotf0
> Version: 0.9.13-3
> 
> $ apt show libm17n-0
> Package: libm17n-0
> Version: 1.7.0-3
> 
> $ apt show m17n-db
> Package: m17n-db
> Version: 1.7.0-2

Time to ask Handa-san to please chime in and comment on this issue,
and first of all a question: Is this feature supposed to work when the
characters are displayed not by the same font?  It seems to work with
the Uniscribe shaping engine on Windows, but not with libotf/libm17n.

Thanks.

bug#26742: Display bug with composed strings

[Eli Zaretskii]

> Date: Tue, 02 May 2017 20:57:45 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 26742@debbugs.gnu.org
> 
> > Cc: 26742@debbugs.gnu.org
> > From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> > Date: Tue, 2 May 2017 13:22:19 -0400
> > 
> > For ℝ, "emacs -Q" uses "Latin Modern Math" and "emacs" with customizations uses "XITS Math". 
> > For ≤, both use Ubuntu Mono.  I changed the default font and noticed slightly different glitches, including with a variable-pitch font multiple "!" disappearing.
> 
> Could you try fonts mentioned by Andreas?

Also, what happens if you replace 8804 in your test file with 10877?

bug#26742: Display bug with composed strings

[Andreas Schwab]

On Mai 02 2017, Eli Zaretskii <eliz@gnu.org> wrote:

> Does anything change if you add
>
>   --eval "(setq use-default-font-for-symbols nil)"

That doesn't change anything.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#26742: Display bug with composed strings

[Andreas Schwab]

On Mai 02 2017, Eli Zaretskii <eliz@gnu.org> wrote:

> Also, what happens if you replace 8804 in your test file with 10877?

Interestingly, this is also shows the effect, even though both
characters are taken from the same font (not the default font).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#26742: Display bug with composed strings

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: clement.pitclaudel@live.com,  26742@debbugs.gnu.org
> Date: Tue, 02 May 2017 21:02:17 +0200
> 
> On Mai 02 2017, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Does anything change if you add
> >
> >   --eval "(setq use-default-font-for-symbols nil)"
> 
> That doesn't change anything.

Thanks.

So the conclusion this far is that the feature only works reliably
when both characters are displayed by the same font.

bug#26742: Display bug with composed strings

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: clement.pitclaudel@live.com,  26742@debbugs.gnu.org
> Date: Tue, 02 May 2017 21:06:44 +0200
> 
> On Mai 02 2017, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Also, what happens if you replace 8804 in your test file with 10877?
> 
> Interestingly, this is also shows the effect, even though both
> characters are taken from the same font (not the default font).

So this conclusion:

> So the conclusion this far is that the feature only works reliably
> when both characters are displayed by the same font.

appears to be incorrect, and there's some other factor at work here.

bug#26742: Display bug with composed strings

[YAMAMOTO Mitsuharu]

> If I create a file temp.txt containing the following:

> -*- prettify-symbols-alist: (("R_PO" 8477 (Br . cl) 8804)); -*-
> !!! R_PO !!!

> and run ‘emacs-24.5 -Q temp.txt -f prettify-symbols-mode’, I observe
> a surprising display bug: when I move the point across the second
> line, as soon as the point reaches the blank space after “R_PO”, I
> see a second ℝ displayed instead of the third “!”.

On the Mac port, the filled box cursor disappears if I move it on
the composite characters.  The patch below seems to work for this
bug.  Could you try if it also solves the problems you observe?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

diff --git a/src/xdisp.c b/src/xdisp.c
index e3315c4..12ae202 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -24698,6 +24698,20 @@ set_glyph_string_background_width (struct glyph_string *s, int start, int last_x
 }
 
 
+/* Return glyph string that shares background with glyph string S and
+   whose `background_width' member has been set.  */
+
+static struct glyph_string *
+glyph_string_containing_background_width (struct glyph_string *s)
+{
+  if (s->cmp)
+    while (s->cmp_from)
+      s = s->prev;
+
+  return s;
+}
+
+
 /* Compute overhangs and x-positions for glyph string S and its
    predecessors, or successors.  X is the starting x-position for S.
    BACKWARD_P non-zero means process predecessors.  */
@@ -25025,7 +25039,10 @@ draw_glyphs (struct window *w, int x, struct glyph_row *row,
   i = start;
   BUILD_GLYPH_STRINGS (i, end, head, tail, hl, x, last_x);
   if (tail)
-    x_reached = tail->x + tail->background_width;
+    {
+      s = glyph_string_containing_background_width (tail);
+      x_reached = s->x + s->background_width;
+    }
   else
     x_reached = x;
 
@@ -25180,6 +25197,9 @@ draw_glyphs (struct window *w, int x, struct glyph_row *row,
 	  compute_overhangs_and_x (h, tail->x + tail->width, 0);
 	  append_glyph_string_lists (&head, &tail, h, t);
 	}
+      tail = glyph_string_containing_background_width (tail);
+      if (clip_tail)
+	clip_tail = glyph_string_containing_background_width (clip_tail);
       if (clip_head || clip_tail)
 	for (s = head; s; s = s->next)
 	  {

bug#26742: Display bug with composed strings

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 499 bytes --]

On 2017-05-02 15:06, Andreas Schwab wrote:
> On Mai 02 2017, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Also, what happens if you replace 8804 in your test file with 10877?
>
> Interestingly, this is also shows the effect, even though both
> characters are taken from the same font (not the default font).

Really? On my machine I get DejaVu sans for one, and DejaVu Sans Mono for the other (and the effect is indeed observable, but that's consistent with the "multiple fonts" hypothesis)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#26742: Display bug with composed strings

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 351 bytes --]

On 2017-05-02 13:57, Eli Zaretskii wrote:
> Does the problem affect other characters as well, or just these two?

It seems to affect any pair of characters (I tried using (set-fontset-font t '(?← . ?←) (font-spec :name "Symbola") nil) and this prop line:

  -*- prettify-symbols-alist: (("R_PO" . (?A (Br . cl) ?←))); -*-

Clément.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#26742: Display bug with composed strings

[Eli Zaretskii]

> Date: Wed, 03 May 2017 12:50:16 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: 26742@debbugs.gnu.org
> 
> +/* Return glyph string that shares background with glyph string S and
> +   whose `background_width' member has been set.  */
> +
> +static struct glyph_string *
> +glyph_string_containing_background_width (struct glyph_string *s)
> +{
> +  if (s->cmp)
> +    while (s->cmp_from)
> +      s = s->prev;
> +
> +  return s;
> +}

Please also test this with composed characters in R2L text (I don't
remember if s->cmp_from still has the same meaning in that case).

Thanks.

bug#26742: Display bug with composed strings

[Eli Zaretskii]

> Cc: 26742@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Wed, 3 May 2017 01:20:17 -0400
> 
> On 2017-05-02 13:57, Eli Zaretskii wrote:
> > Does the problem affect other characters as well, or just these two?
> 
> It seems to affect any pair of characters (I tried using (set-fontset-font t '(?← . ?←) (font-spec :name "Symbola") nil) and this prop line:
> 
>   -*- prettify-symbols-alist: (("R_PO" . (?A (Br . cl) ?←))); -*-

Thanks.  Please try the changes proposed by Ymamoto-san.

bug#26742: Display bug with composed strings

[Andreas Schwab]

On Mai 03 2017, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:

>> If I create a file temp.txt containing the following:
>
>> -*- prettify-symbols-alist: (("R_PO" 8477 (Br . cl) 8804)); -*-
>> !!! R_PO !!!
>
>> and run ‘emacs-24.5 -Q temp.txt -f prettify-symbols-mode’, I observe
>> a surprising display bug: when I move the point across the second
>> line, as soon as the point reaches the blank space after “R_PO”, I
>> see a second ℝ displayed instead of the third “!”.
>
> On the Mac port, the filled box cursor disappears if I move it on
> the composite characters.  The patch below seems to work for this
> bug.  Could you try if it also solves the problems you observe?

That fixes the disappearing box cursor, but doesn't fix the ghost
character.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#26742: Display bug with composed strings

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 03 May 2017 18:53:32 +0200, Andreas Schwab <schwab@linux-m68k.org> said:

>> On the Mac port, the filled box cursor disappears if I move it on
>> the composite characters.  The patch below seems to work for this
>> bug.  Could you try if it also solves the problems you observe?

> That fixes the disappearing box cursor, but doesn't fix the ghost
> character.

Then could you try the patch below, together with the previous one?  I
downloaded some fonts (Ubuntu Mono, Latin Modern Math, and XITS Math)
and installed them, but I couldn't reproduce the problem on X11 for
macOS.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

diff --git a/src/xdisp.c b/src/xdisp.c
index e3315c4..ed88f4c 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -24711,7 +24725,8 @@ compute_overhangs_and_x (struct glyph_string *s, int x, int backward_p)
 	{
 	  if (FRAME_RIF (s->f)->compute_glyph_string_overhangs)
 	    FRAME_RIF (s->f)->compute_glyph_string_overhangs (s);
-	  x -= s->width;
+	  if (!s->cmp || s->cmp_to == s->cmp->glyph_len)
+	    x -= s->width;
 	  s->x = x;
 	  s = s->prev;
 	}
@@ -24723,7 +24738,8 @@ compute_overhangs_and_x (struct glyph_string *s, int x, int backward_p)
 	  if (FRAME_RIF (s->f)->compute_glyph_string_overhangs)
 	    FRAME_RIF (s->f)->compute_glyph_string_overhangs (s);
 	  s->x = x;
-	  x += s->width;
+	  if (!s->cmp || s->cmp_from == 0)
+	    x += s->width;
 	  s = s->next;
 	}
     }

bug#26742: Display bug with composed strings

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 04 May 2017 14:39:16 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>> That fixes the disappearing box cursor, but doesn't fix the ghost
>> character.

> Then could you try the patch below, together with the previous one?

Sorry.  Please use this one instead of the last one.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

diff --git a/src/xdisp.c b/src/xdisp.c
index e3315c4..ed88f4c 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -24711,7 +24725,8 @@ compute_overhangs_and_x (struct glyph_string *s, int x, int backward_p)
 	{
 	  if (FRAME_RIF (s->f)->compute_glyph_string_overhangs)
 	    FRAME_RIF (s->f)->compute_glyph_string_overhangs (s);
-	  x -= s->width;
+	  if (!s->cmp || s->cmp_to == s->cmp->glyph_len)
+	    x -= s->width;
 	  s->x = x;
 	  s = s->prev;
 	}
@@ -24723,7 +24738,8 @@ compute_overhangs_and_x (struct glyph_string *s, int x, int backward_p)
 	  if (FRAME_RIF (s->f)->compute_glyph_string_overhangs)
 	    FRAME_RIF (s->f)->compute_glyph_string_overhangs (s);
 	  s->x = x;
-	  x += s->width;
+	  if (!s->cmp || s->cmp_to == s->cmp->glyph_len)
+	    x += s->width;
 	  s = s->next;
 	}
     }

bug#26742: Display bug with composed strings

[Andreas Schwab]

On Mai 04 2017, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:

> diff --git a/src/xdisp.c b/src/xdisp.c
> index e3315c4..ed88f4c 100644
> --- a/src/xdisp.c
> +++ b/src/xdisp.c
> @@ -24711,7 +24725,8 @@ compute_overhangs_and_x (struct glyph_string *s, int x, int backward_p)
>  	{
>  	  if (FRAME_RIF (s->f)->compute_glyph_string_overhangs)
>  	    FRAME_RIF (s->f)->compute_glyph_string_overhangs (s);
> -	  x -= s->width;
> +	  if (!s->cmp || s->cmp_to == s->cmp->glyph_len)
> +	    x -= s->width;
>  	  s->x = x;
>  	  s = s->prev;
>  	}
> @@ -24723,7 +24738,8 @@ compute_overhangs_and_x (struct glyph_string *s, int x, int backward_p)
>  	  if (FRAME_RIF (s->f)->compute_glyph_string_overhangs)
>  	    FRAME_RIF (s->f)->compute_glyph_string_overhangs (s);
>  	  s->x = x;
> -	  x += s->width;
> +	  if (!s->cmp || s->cmp_to == s->cmp->glyph_len)
> +	    x += s->width;
>  	  s = s->next;
>  	}
>      }

That fixes the ghost character.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#26742: Display bug with composed strings

[Clément Pit--Claudel]

On 2017-05-04 12:21, Andreas Schwab wrote:
> On Mai 04 2017, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:
> 
>> diff --git a/src/xdisp.c b/src/xdisp.c
>> index e3315c4..ed88f4c 100644
>> --- a/src/xdisp.c
>> +++ b/src/xdisp.c
>> …
> 
> That fixes the ghost character.

Indeed, same here. Thanks!

bug#26742: Display bug with composed strings

[mituharu]

>> That fixes the ghost character.
>
> Indeed, same here. Thanks!

Thanks for testing.  I've just pushed it to the trunk.
For the R2L cases, the background width is also set for the glyph string
whose cmp_from is 0.
So, this should also work for R2L texts.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp