* Re: Unreadable buffer names in Emacs 23.2 [not found] <35f2d04d-7fea-4469-b6d0-5db21bf53a9c@t2g2000yqe.googlegroups.com> @ 2010-08-14 4:16 ` Tim X 2010-08-14 8:03 ` rustom ` (3 more replies) 0 siblings, 4 replies; 7+ messages in thread From: Tim X @ 2010-08-14 4:16 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Unreadable buffer names in Emacs 23.2 2010-08-14 4:16 ` Unreadable buffer names in Emacs 23.2 Tim X @ 2010-08-14 8:03 ` rustom 2010-08-15 1:00 ` Ilya Zakharevich ` (2 subsequent siblings) 3 siblings, 0 replies; 7+ messages in thread From: rustom @ 2010-08-14 8:03 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Unreadable buffer names in Emacs 23.2 2010-08-14 4:16 ` Unreadable buffer names in Emacs 23.2 Tim X 2010-08-14 8:03 ` rustom @ 2010-08-15 1:00 ` Ilya Zakharevich 2010-08-15 4:45 ` Tim X 2010-08-15 3:57 ` Android Eve [not found] ` <3a2ce65c-4bd6-4c62-8fb4-ae823d209112@f6g2000yqa.googlegroups.com> 3 siblings, 1 reply; 7+ messages in thread From: Ilya Zakharevich @ 2010-08-15 1:00 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Unreadable buffer names in Emacs 23.2 2010-08-15 1:00 ` Ilya Zakharevich @ 2010-08-15 4:45 ` Tim X 0 siblings, 0 replies; 7+ messages in thread From: Tim X @ 2010-08-15 4:45 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Unreadable buffer names in Emacs 23.2 2010-08-14 4:16 ` Unreadable buffer names in Emacs 23.2 Tim X 2010-08-14 8:03 ` rustom 2010-08-15 1:00 ` Ilya Zakharevich @ 2010-08-15 3:57 ` Android Eve [not found] ` <3a2ce65c-4bd6-4c62-8fb4-ae823d209112@f6g2000yqa.googlegroups.com> 3 siblings, 0 replies; 7+ messages in thread From: Android Eve @ 2010-08-15 3:57 UTC (permalink / raw) To: help-gnu-emacs 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? ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <3a2ce65c-4bd6-4c62-8fb4-ae823d209112@f6g2000yqa.googlegroups.com>]
* Re: Unreadable buffer names in Emacs 23.2 [not found] ` <3a2ce65c-4bd6-4c62-8fb4-ae823d209112@f6g2000yqa.googlegroups.com> @ 2010-08-15 4:43 ` Tim X [not found] ` <8b2d7002-9985-4f86-af0e-8bbfc4b930cd@t2g2000yqe.googlegroups.com> 0 siblings, 1 reply; 7+ messages in thread From: Tim X @ 2010-08-15 4:43 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <8b2d7002-9985-4f86-af0e-8bbfc4b930cd@t2g2000yqe.googlegroups.com>]
* Re: Unreadable buffer names in Emacs 23.2 [not found] ` <8b2d7002-9985-4f86-af0e-8bbfc4b930cd@t2g2000yqe.googlegroups.com> @ 2010-08-16 22:47 ` Tim X 0 siblings, 0 replies; 7+ messages in thread From: Tim X @ 2010-08-16 22:47 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-08-16 22:47 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <35f2d04d-7fea-4469-b6d0-5db21bf53a9c@t2g2000yqe.googlegroups.com> 2010-08-14 4:16 ` Unreadable buffer names in Emacs 23.2 Tim X 2010-08-14 8:03 ` rustom 2010-08-15 1:00 ` Ilya Zakharevich 2010-08-15 4:45 ` Tim X 2010-08-15 3:57 ` Android Eve [not found] ` <3a2ce65c-4bd6-4c62-8fb4-ae823d209112@f6g2000yqa.googlegroups.com> 2010-08-15 4:43 ` Tim X [not found] ` <8b2d7002-9985-4f86-af0e-8bbfc4b930cd@t2g2000yqe.googlegroups.com> 2010-08-16 22:47 ` Tim X
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).