Re: Unreadable buffer names in Emacs 23.2

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

Re: Unreadable buffer names in Emacs 23.2

[rustom]

On Aug 14, 9:16 am, Tim X <t...@nospam.dev.null> wrote:

> 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

Ive seen it a couple of times when ubuntu changed the directory paths
of the fonts and the xorg.conf file was not consistent with the
change.

Since the OP is on windows this would of course not apply

Re: Unreadable buffer names in Emacs 23.2

[Ilya Zakharevich]

On 2010-08-14, Tim X <timx@nospam.dev.null> wrote:
>> 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. 

Of course it may know this!  Only after you remove properties text
becomes "a plain text"...  One should try
Edit/Text_Properties/Whatever_the_spelling_of_remove_is...

Ilya

Re: Unreadable buffer names in Emacs 23.2

[Tim X]

Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:

> On 2010-08-14, Tim X <timx@nospam.dev.null> wrote:
>>> 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. 
>
> Of course it may know this!  Only after you remove properties text
> becomes "a plain text"...  One should try
> Edit/Text_Properties/Whatever_the_spelling_of_remove_is...
>
Technically, you are right in that this would be possible, but I don't
believe there are any font properties used to indicate that a bit of
text is a buffer name. 

Tim

-- 
tcross (at) rapttech dot com dot au

Re: Unreadable buffer names in Emacs 23.2

[Android Eve]

On Aug 14, 12:16 am, Tim X <t...@nospam.dev.null> wrote:
>
> 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?

Tim, thanks for your thorough reply. I will be checking shortly some
of the suggestions you provided, but before doing so, I would like to
provide links to snapshots of what I actually see (1 picture is worth
1000 words):

minibuffer: http://yfrog.com/meminibufferp

buffer list:  http://yfrog.com/3mbufferlistp

dired buffer: http://yfrog.com/jkdiredp

Does the above help zero in on the problem?

Re: Unreadable buffer names in Emacs 23.2

[Tim X]

Android Eve <androidev@gmx.com> writes:

> On Aug 14, 12:16 am, Tim X <t...@nospam.dev.null> wrote:
>>
>> Most likely, a custom setting for the
>> minibuffer prompt and maybe an Xresource setting for the menu font.
>>
>
> OK - I found the offending lines in my .emacs (both statements need to
> be commented out!):
>
>      (setq default-frame-alist
> 	    (cons '(font . "-*-Lucida Console-normal-r-*-*-12-*-*-*-c-*-*-
> iso8859-1")
> 		  default-frame-alist))
>      (set-default-font
>       "-*-Lucida Console-normal-r-*-*-12-*-*-*-c-*-*-iso8859-1")
>
> Now I need to find out why.
>

Something which may help is that if your using emacs 23 (or later), you
can probably set your font from the options menu. Try that and see if
you get a better result. Don't forget to save your options. 

The advantage of this approach is that you should only be presented with
fonts that are available or which emacs can find. It will also result in
a default face definition in your .emacs custom-faces section. You cold
then use that to define the fonts in the frame alists if you want,
however, it may not be necessary. 

Tim
-- 
tcross (at) rapttech dot com dot au

Re: Unreadable buffer names in Emacs 23.2

[Tim X]

Android Eve <androidev@gmx.com> writes:

> Thank you, Tim. I did exactly as you suggested and it works very well.
> Modifying .emacs via the Options menu (which is a totally new concept
> to me...), resulted in appending the following 2 lines:
>
> (custom-set-faces
> '(default ((t (:inherit nil :stipple nil :background
> "Black" :foreground "LightGray" :inverse-video nil :box nil :strike-
> through nil :overline nil :underline nil :slant normal :weight
> normal :height 90 :width normal :foundry "outline" :family "Lucida
> Console")))))
>
> I must admit that although I can't live without Emacs, I find it
> frustrating to have to "fix" my .emacs every time I upgrade to a new
> version. Is there a way to create a .emacs that will never break?
> (i.e. forward-compatible)
>

Forward compatibility is pretty much impossible as you cannot predict
the future. However, the emacs dev team work pretty hard to keep
backwards compatibility. This can be very difficult due to the nature of
emacs and the extensive customization it supports. My suggestions would
be

1. Use customize as much as you can. As this provides a standard
framework for customizing everything, it also provides something which
the emacs devs can use to try and maintain backwards compatibility. I
switched to customize a few years back as I found it work far more
reliably than all my custom elisp code, which often broke on upgrade of
emacs. I still have some elisp for stuff not covered by custom, but it
is a lot less and a lot easier to maintain. 

2. Always read the NEWS and PROBLEMS file before upgrading. 99% of the
time, information in both files alert you to things you may have to
tweak in your .emacs and saves you a lot of time. 

3. Over a number of years, I've often found it beneficial to work with
emacs rather than against it. Initially, I cusotmized and tweaked stuff
all over the place, but then realised what I was doing was trying to
make emacs like other editors I was familiar with. This had two
disadvantages. Firstly, it created a level of maintenance that was a
pain and secondly, I often missed some of he real advantages of emacs. I
now tend to only customize things after I've used them for a while.
Frequently, I find the new or unfamiliar behaviour turns out to be much
better than what I had grown use to with other tools. Instead of trying
to make emacs like other things, I now wish other things were more like
emacs! 

HTH

Tim

-- 
tcross (at) rapttech dot com dot au