From: shamino@techie.com (David C.)
Subject: Macintosh character display (128-255)
Date: Wed, 29 Dec 2004 09:56:38 GMT [thread overview]
Message-ID: <m2brcd5sx6.fsf@qqqq.invalid> (raw)
I'm running Emacs 21.3.50, compiled for Macintosh OS X 10.3.
I have set up my system to display the mac-roman version of the
courier font for all frames, and to display all hi-page characters
as-is, since the font contains glyphs for them all. The relevant
lines from my .emacs file are:
(set-default-font
"-apple-courier-medium-r-normal--14-*-*-*-*-*-mac-roman")
(setq default-frame-alist
(append
'((width . 80)
(height . 104)
(font . "-apple-courier-medium-r-normal--14-*-*-*-*-*-mac-roman"))
default-frame-alist))
(standard-display-8bit 128 255)
Using this setup, I find that the hi-page characters still don't
display properly. I get the hollow rectanlges (some extra-wide)
representing those characters in all newly-created buffers. If I
load a file with these characters, however, they display OK.
As a test, I created a simple text file containing all 128 of the
hi-page characters.
If I load the buffer (C-x C-f <filename>), all of the hi-page
characters display correctly.
If instead, I create a new buffer (or simply switch to the scratch
buffer) and insert the contents of that same file (C-x i <filename>),
the even-numbered hi-page characters all display as boxes and the
odd-numbered hi-page characters all display as a capital "A" with an
umlaut over it.
I don't think this a frame-setting problem, because I see the problem
when both buffers are displayed in the same frame.
The "new buffer" behavior is also exhibited when reading messages
with Gnus.
If I comment off the font-changes from my .emacs file, I get the same
behavior as before, but with latin-1 characters displayed for loaded
files instead of mac-roman characters.
If I comment off the "standard-display-8bit" call, I see a variation
on the same behavior. New buffers show all of the hi-page characters
as their octal equivalents, while loaded buffers show octal for the
range of 128-159 and Mac characters from 160-255. Obviously, the part
of the Emacs library that processes the default (nil) standard display
table knows what the difference is between these buffers.
Unfortunately, I do not.
I checked what I think are all the obvious variables for the two buffers:
buffer-file-coding-system is raw-text-unix for both buffers.
buffer-display-table is nil for both buffers, meaning they are
both using the same table (standard-display-table).
buffer-file-format is nil for both buffers.
Could someone point me in the right direction. Or even better,
suggest a change to my .emacs that will force newly-created buffers
to display the mac-roman encoding for all of the hi-page characters?
Thanks in advance.
-- David
next reply other threads:[~2004-12-29 9:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-29 9:56 David C. [this message]
2004-12-29 10:09 ` Macintosh character display (128-255) kurtz
2004-12-29 10:32 ` Peter Dyballa
[not found] ` <mailman.9656.1104317240.27204.help-gnu-emacs@gnu.org>
2004-12-29 11:37 ` David C.
2004-12-29 12:26 ` Peter Dyballa
[not found] ` <mailman.9707.1104324115.27204.help-gnu-emacs@gnu.org>
2004-12-29 14:00 ` David C.
2004-12-29 14:59 ` David C.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2brcd5sx6.fsf@qqqq.invalid \
--to=shamino@techie.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).