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.