Re: Unreadable buffer names in Emacs 23.2

[Tim X]

Android Eve <androidev@gmx.com> writes:

> I upgraded from Emacs 21.2 to 23.2 (on Windows XP) and while I managed
> to tweak my .emacs to fit most new changes, I couldn't find a solution
> for the unreadable buffer names:
>
> Neither in the minibuffer, nor in the buffer menu can the characters
> be displayed normally. Instead, all I see are the infamous Unicode
> blank rectangles.
>

The 'infamous Unicode blank rectangles' are most likely characters that
cannot be displayed by the font being used in the minibuffer or menus. 

The first thing I'd try is running emacs -Q and see if you get the same
behavior. If you don't, then its something you have set in your .emacs
(or possibly .Xresources). Most likely, a custom setting for the
minibuffer prompt and maybe an Xresource setting for the menu font. 

> All buffers are displayed perfectly (same font) - even with syntax
> highlighting. Buffers that contain buffer names also display
> everything properly -- except for buffer names!
>
So the buffer names have exactly the same set of characters that appear
in other buffers that display OK? Seems very strange. Text in a buffer
is text in a buffer. Once the text is in a buffer, Emacs doesn't really
know whether it is a buffer name or some other text. 

> I suspect this problem could be related to the new feature introduced
> in Emacs 23.2 called "uniquify-buffer-name-style", but I tried 'toggle-
> uniquify-buffer-names' and I placed the following in .emacs and that
> didn't help:

Is this a new feature? The uniquify.el file has been around for a long
long time i.e. Emacs 18. 
>
> (require 'uniquify)
> (setq
>   uniquify-buffer-name-style 'post-forward
>   uniquify-separator ":")
>
>
Well, if you think it is uniquify, the first thing I would do after
emacs -Q is to not load this feature. Remove any (require 'uniquify)
from your .emacs and any custom settings relating to it. Then see if you
get the same issue. 

Uniquify doesn't do anything terribly tricky and doesn't just grab
characters at random. I uses increasing bits of the file path until it
has a unique name. So, all of the characters it uses are ones from your
filepath (plus the seperator). 

First step is to run emacs -Q and see if the problem is exactly the
same. It definitely sounds like some sort of font issue. If you have
turned off the uniquify-buffer-names and still see the problem, it is
unlikely that is the cause. 

Check you don't have some font settings in your .Xresources that could
be affecting things. Also watch out for any coding system settings you
may have - perhaps something is misconfigured there. 

Look at the custom-faces section of your .emacs and see if anything
looks different for fonts that are used for font-lock etc and faces used
for the minibuffer (If your running a GTK build, I think the menu fonts
can only be set via GTK resources i.e. .gtkrc and possibly Xresources). 

I'm running emacs 23.1 (ubuntu) 23.2 (debian) and 24.0.50 on both and
don't see this problem in any version with or without the
uniquify-buffer-names feature. My 'lang' settings are UTF-8. 

What is your font setting? What are your locale settings? Does dired
work? What do you see in shell/term/eshell prompts and can you read the
output from ls in these buffers? Is the buffer encoding for boffers that
look right and those that don't the same?

Are all the buffer name characters boxes or are just some of them?
My wild guess is that you have a couple of characters that your font
cannot display, but which don't appear often in normal text.
So, your font looks fine in most buffers. For example, maybe you have
one of the higher unicode characters for dash or long dash etc which
your fon't cannot display. However, in normal buffers, you have only got
the more 'common' - or minus character, which nearly all fonts can
display, but your shell is using the unicode character rather than -. 

Without exception, everytime I've seen the 'boxes' rather than
characters in emacs, it has been because the font was not able to print
that character. Changing to a different font which was more complete has
generally fixed the issue. 

Tim

-- 
tcross (at) rapttech dot com dot au