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

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 32276 in the body.
You can then email your comments to 32276 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Keith David Bershatsky <esq <at> lawlist.com>
To: Emacs Bug Reports <bug-gnu-emacs <at> gnu.org>
Subject: char-width of a space is 0 when display-table entry has a face.
Date: Wed, 25 Jul 2018 20:33:33 -0700

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.

Message #10 received at 32276-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Keith David Bershatsky <esq <at> lawlist.com>
Cc: 32276-done <at> debbugs.gnu.org
Subject: Re: bug#32276: char-width of a space is 0 when display-table entry
 has a face.
Date: Fri, 27 Jul 2018 12:34:30 +0300

> Date: Wed, 25 Jul 2018 20:33:33 -0700
> From: Keith David Bershatsky <esq <at> 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.

Message #13 received at 32276 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Keith David Bershatsky <esq <at> lawlist.com>, 32276 <at> debbugs.gnu.org
Subject: Re: bug#32276: char-width of a space is 0 when display-table entry
 has a face.
Date: Sat, 28 Jul 2018 15:37:50 -0700

[Message part 1 (text/plain, inline)]

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.

[0001-Adjust-recent-Bug-32276-fix.patch (text/x-patch, attachment)]

Message #16 received at 32276 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: esq <at> lawlist.com, 32276 <at> debbugs.gnu.org
Subject: Re: bug#32276: char-width of a space is 0 when display-table entry
 has a face.
Date: Sun, 29 Jul 2018 17:45:14 +0300

> Cc: 32276 <at> debbugs.gnu.org, Keith David Bershatsky <esq <at> lawlist.com>
> From: Paul Eggert <eggert <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.