bug#15177: 24.3.50; codepoint 35 chars displayed as binary matrix after some file names

bug#15177: 24.3.50; codepoint 35 chars displayed as binary matrix after some file names

[Drew Adams]

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

See attached screenshot from `emacs -Q' followed by M-x speedbar.

Some of the file names are followed by a codepoint 35 character (`#')
that is displayed as a blue matrix of tiny 0s and 1s.  Other file names
have no such character after them.  (Not shown: read-only files have
instead a yellow padlock icon following the file name.)

`C-u C-x =' on that character gives this info:

             position: 21143 of 44023 (48%), column: 18
            character: # (displayed as #) (codepoint 35, #o43, #x23)
    preferred charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x23
               script: latin
               syntax: . 	which means: punctuation
             category: .:Base, a:ASCII, l:Latin, r:Roman
             to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME"
          buffer code: #x23
            file code: #x23 (encoded by coding system iso-latin-1-dos)
              display: by this font (glyph code)
    uniscribe:-outline-Courier New-normal-normal-normal-mono-17-*-*-*-c-*-iso8859-1 (#x06)

Character code properties: customize what to show
  name: NUMBER SIGN
  general-category: Po (Punctuation, Other)
  decomposition: (35) ('#')

There are text properties here:
  display              [Show]
  rear-nonsticky       [Show]

However, where the text copied above shows "# (displayed as #)", what
I actually see in buffer *Help* is "# (displayed as [])", where `[]'
is that blue binary matrix char display.

Seems like a bug of some kind.  `C-h m' says that character `#' after
a file name indicates that the file has been compiled:

"Files with a `#' or `!' character after them are source files that
 have an object file associated with them.  The `!' indicates that the
 files is out of date.  You can control what source/object associations
 exist through the variable `speedbar-obj-alist'."

So it seems that the bug is that the `#' char is displayed wrong (in
both speedbar and `C-u C-x =' output).

(A second comment about the speedbar display, in passing: Why does it
use a different face for mouseover from the default face for this
elsewhere, `highlight'?  If a user has gone to the trouble of
customizing face `highlight', why would that not be used here also?)


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-08-23 on ODIEONE
Bzr revision: 113986 rgm@gnu.org-20130823185841-zoy6h1qk433ibrlf
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

[-- Attachment #2: throw-speedbar.png --]
[-- Type: image/png, Size: 18879 bytes --]

bug#15177: 24.3.50; codepoint 35 chars displayed as binary matrix after some file names

[Drew Adams]

The same bug appears in Emacs 24.1 through the reported build.
In Emacs 23.4 and prior images were not shown by default, and
the `#' char was displayed correctly.

bug#15177: 24.3.50; codepoint 35 chars displayed as binary matrix after some file names

[Eli Zaretskii]

> Date: Sat, 24 Aug 2013 02:03:11 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> See attached screenshot from `emacs -Q' followed by M-x speedbar.
> 
> Some of the file names are followed by a codepoint 35 character (`#')
> that is displayed as a blue matrix of tiny 0s and 1s.  Other file names
> have no such character after them.  (Not shown: read-only files have
> instead a yellow padlock icon following the file name.)

It's a feature; "M-x speedbar-toggle-images RET" toggles it on and
off.  The tiny 0s and 1s are supposed to tell you that there's a
binary file associated with the current file.  See sb-image.el for the
details.

Any reason not to close this bug?

bug#15177: 24.3.50; codepoint 35 chars displayed as binary matrix after some file names

[Drew Adams]

> > See attached screenshot from `emacs -Q' followed by M-x speedbar.
> >
> > Some of the file names are followed by a codepoint 35 character (`#')
> > that is displayed as a blue matrix of tiny 0s and 1s.  Other file names
> > have no such character after them.  (Not shown: read-only files have
> > instead a yellow padlock icon following the file name.)
> 
> It's a feature; "M-x speedbar-toggle-images RET" toggles it on and
> off.  The tiny 0s and 1s are supposed to tell you that there's a
> binary file associated with the current file.  See sb-image.el for the
> details.

I would never have guessed that.  At first I thought it might be an image,
but when I did C-u C-x = I did not notice anything pointing that out.  I
guess the "displayed as" is the only hint about this.

> Any reason not to close this bug?

Yes, of course.  It's not fixed.  Just because you happen to know why
users see what they see, that does not fix the bug.  At all.

All explanation for the user speaks only of `#'.  The doc, messages,
mode-string (`C-h m'), etc. all need to be updated to properly describe
what the user now sees, not something s?he no longer sees by default.

The doc can make clear that there are two alternative display modes:
images and chars.  But I already knew that, and I still had no clue as
to what this was about.  In particular because the doc does not provide
a legend for that (or the other) images.  It provides only an incomplete,
hence out-of-date, legend of what each char means, not each image.

At the very least, if the doc cannot show the various images, it needs
to describe each of them and say what char(s) each image corresponds to
in the char display.

I would point out also that similar glyphs (or images or whatever) are
shown when a given font cannot show some character, and a user is
likely to have seen these.  I was guessing that perhaps that was the
problem here: some char was being displayed that the font could not
show as such.  And that's why I tried `C-u C-x =', to see what I could
find out about the "mystery character".

IOW, that particular image is perhaps not the best one to use to
represent a binary/compiled file type.  Something to consider, anyway.