unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: shamino@techie.com (David C.)
Subject: Re: Macintosh character display (128-255)
Date: Wed, 29 Dec 2004 11:37:19 GMT	[thread overview]
Message-ID: <m2oegd1gk1.fsf@qqqq.invalid> (raw)
In-Reply-To: mailman.9656.1104317240.27204.help-gnu-emacs@gnu.org

Peter Dyballa <Peter_Dyballa@Web.DE> writes:
> Am 29.12.2004 um 10:56 schrieb David C.:
> 
>> I'm running Emacs 21.3.50, compiled for Macintosh OS X 10.3.
> 
> Are you running it in Terminal, or as carbonized Emacs natively in
> Aqua, or as very good programme under X11?

A carbonized Emacs natively in Aqua.  emacs-version reports:

    GNU Emacs 21.3.50.1 (powerpc-apple-darwin7.2.0) of 2004-01-18

When I run in a terminal window, this problem doesn't happen.  All
the characters always display with the expected glyphs, based on what
font the Terminal window is configured to use.

>> 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")
> 
> This is too short! Later more.
> 
>>     (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)
> 
> I think that's not needed.
> 
>> 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.
> 
> Which coding-system is displayed in the modeline?

The mode-line doesn't seem to show one:

    -:---Emacs  upper-ascii.txt   All L1    (Text Fill)-----------

>> 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.
> 
> Again: which coding-system? You have to teach Emacs to prefer some
> coding-system. If it's running in Terminal, then Terminal should be
> set  to UTF-8, and under X11 and in Terminal you should make Emacs use
> UTF-8  too.

The mode-line here is different:

    -t:**-Emacs  *scratch*      All L1    (Lisp Interaction)---------

According to list-coding-systems, the "t" indicates raw-text

>> 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
> 
> In Unicode and ISO Latin these are control codes, only Mac Roman and
> maybe Windows too uses this range as characters. So in a Unicode or
> Latin buffer you can't anything else than octal values.

Mac-Roman is 8-bit and has characters in these positions.  When I
call standard-display-8bit to force the display of these characters,
and do a find-file, the characters in those positions are displayed
with the characters in those positions.

>> 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?
> 
> Here is a setup for a .emacs file:

I'll try some of this, but it's going to need quite a bit of editing,
since it is setting up all kinds of things that (I hope) are
unrelated to this problem.  (For instance, you LaTeX hooks).

I pulled these lines from your .emacs:

      (set-variable 'file-name-coding-system           'utf-8)
      (set-variable 'default-buffer-file-coding-system 'mac-roman-unix)
      (set-default-coding-systems                      'mac-roman-unix)
      (set-keyboard-coding-system                      'mac-roman)
      (prefer-coding-system                            'mac-roman-unix)

When I do this, every buffer is created in the Mac-Roman encoding.
And as a result of this, every buffer (whether new or loaded) shows my
test file as nothing but empty squares.  In other words, it made the
problem worse.

As for all the fontset work, I appreciate your assistance here, but I
really don't think fontsets are the issue.  As I wrote originally, my
existing font configuration _DOES_ show the required characters when
I do a find-file on the buffer.  It only has problems for new
buffers.  And all buffers in all frames are using the same font.

> The fontsets are bit more complicated (excerpts from other postings to
> the Mac OS X Emacs list
> List Post: <mailto:macosx-emacs@email.esm.psu.edu>
> List Archives: <http://www.esm.psu.edu/mac-tex/MacOSX-Emacs-Digests/> ):

This is a resource I didn't know about.  Thanks.

-- David

  parent reply	other threads:[~2004-12-29 11:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-29  9:56 Macintosh character display (128-255) David C.
2004-12-29 10:09 ` 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. [this message]
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=m2oegd1gk1.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).