From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: Unreadable buffer names in Emacs 23.2 Date: Sat, 14 Aug 2010 14:16:02 +1000 Organization: Unlimited download news at news.astraweb.com Message-ID: <87lj8996d9.fsf@puma.rapttech.com.au> References: <35f2d04d-7fea-4469-b6d0-5db21bf53a9c@t2g2000yqe.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1291858439 5552 80.91.229.12 (9 Dec 2010 01:33:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 9 Dec 2010 01:33:59 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Dec 09 02:33:55 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PQVOM-00065C-5q for geh-help-gnu-emacs@m.gmane.org; Thu, 09 Dec 2010 02:33:54 +0100 Original-Received: from localhost ([127.0.0.1]:58049 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQVOL-0005ap-IG for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 20:33:53 -0500 Original-Path: usenet.stanford.edu!news.glorb.com!news2.glorb.com!news.alt.net!news.astraweb.com!border1.newsrouter.astraweb.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:zpaN2EFXUSqQPt+P7CIV+5PIO7M= Original-Lines: 93 Original-NNTP-Posting-Host: e926f8a4.news.astraweb.com Original-X-Trace: DXC=eAli`G0:HjLjEc; hW[JGKHL?0kYOcDh@JW\:Hm@YlDbJ^FQoa5AIR:C\6:o3aKBMRM\Nc]EBL9GYH Original-Xref: usenet.stanford.edu gnu.emacs.help:180690 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:76393 Archived-At: Android Eve 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