bug#32276: char-width of a space is 0 when display-table entry has a face.

bug#32276: char-width of a space is 0 when display-table entry has a face.

[Keith David Bershatsky]

Step 1:  Open a newly built GUI version of Emacs master branch.

Step 2:  Open a scratch buffer and evaluate the following code:

;;; char-width == 0
(progn
  (fundamental-mode)
  (setq buffer-display-table (make-display-table))
  (aset buffer-display-table
        ?\s
        (vector (make-glyph-code ?· 'font-lock-warning-face)))
  (char-width ?\s))

Step 3:  The char-width in Step 2 is 0.

Step 4:  In the same or a different scratch buffer, evaluate the following code:

;;; char-width == 1
(progn
  (fundamental-mode)
  (setq buffer-display-table (make-display-table))
  (aset buffer-display-table
        ?\s
        (vector (make-glyph-code ?·)))
  (char-width ?\s))

Step 5:  The char-width in Step 4 is 1.

EXPECTED RESULT:  The char-width should be 1 in Step 2, just like in Step 4.

bug#32276: char-width of a space is 0 when display-table entry has a face.

[Eli Zaretskii]

> Date: Wed, 25 Jul 2018 20:33:33 -0700
> From: Keith David Bershatsky <esq@lawlist.com>
> 
> EXPECTED RESULT:  The char-width should be 1 in Step 2, just like in Step 4.

Thanks, fixed on the emacs-26 branch.

bug#32276: char-width of a space is 0 when display-table entry has a face.

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

Unfortunately that change causes the emacs-26 build to fail for me:

make[1]: Entering directory '/home/eggert/src/gnu/emacs/emacs-26-sc/src'
   CC       character.o
In file included from character.c:34:0:
character.c: In function ‘char_width’:
lisp.h:1682:11: error: ‘c’ may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
     ? ((a) + (unsigned) 0) op ((b) + (unsigned) 0)   \
            ^
character.c:292:10: note: ‘c’ was declared here
       int c;
           ^
cc1: all warnings being treated as errors
Makefile:376: recipe for target 'character.o' failed


Although the attached patch fixes this and presumably speeds up the code a bit 
when optimized, is this the right thing to do? I have not looked into the code 
carefully.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Adjust-recent-Bug-32276-fix.patch --]
[-- Type: text/x-patch; name="0001-Adjust-recent-Bug-32276-fix.patch", Size: 989 bytes --]

From 4c321dc8d6b059ddaf5aab137aadbae18a3cb5af Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 28 Jul 2018 15:36:04 -0700
Subject: [PATCH] Adjust recent Bug#32276 fix

* src/character.c (char_width): Make explicit the assumption that
a display character vector element is a character if is not a
glyph code.
---
 src/character.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/character.c b/src/character.c
index 48268e0..6af9825 100644
--- a/src/character.c
+++ b/src/character.c
@@ -293,8 +293,11 @@ char_width (int c, struct Lisp_Char_Table *dp)
 	    ch = AREF (disp, i);
 	    if (GLYPH_CODE_P (ch))
 	      c = GLYPH_CODE_CHAR (ch);
-	    else if (CHARACTERP (ch))
-	      c = XFASTINT (ch);
+	    else
+	      {
+		eassert (CHARACTERP (ch));
+		c = XFASTINT (ch);
+	      }
 	    int w = CHARACTER_WIDTH (c);
 	    if (INT_ADD_WRAPV (width, w, &width))
 	      string_overflow ();
-- 
2.7.4

bug#32276: char-width of a space is 0 when display-table entry has a face.

[Eli Zaretskii]

> Cc: 32276@debbugs.gnu.org, Keith David Bershatsky <esq@lawlist.com>
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 28 Jul 2018 15:37:50 -0700
> 
> Unfortunately that change causes the emacs-26 build to fail for me:

Sorry about that.

> make[1]: Entering directory '/home/eggert/src/gnu/emacs/emacs-26-sc/src'
>    CC       character.o
> In file included from character.c:34:0:
> character.c: In function ‘char_width’:
> lisp.h:1682:11: error: ‘c’ may be used uninitialized in this function 
> [-Werror=maybe-uninitialized]
>      ? ((a) + (unsigned) 0) op ((b) + (unsigned) 0)   \
>             ^
> character.c:292:10: note: ‘c’ was declared here
>        int c;
>            ^
> cc1: all warnings being treated as errors
> Makefile:376: recipe for target 'character.o' failed
> 
> Although the attached patch fixes this and presumably speeds up the code a bit 
> when optimized, is this the right thing to do? I have not looked into the code 
> carefully.

I preferred to keep the modified code work the same as before that
change, i.e. count any non-characters (which now shouldn't happen, I
think) as having a width of zero.  So I pushed a slightly different
fix.