Re: emacs 22 release

[Peter Dyballa]

Am 28.09.2005 um 22:35 schrieb Kevin Rodgers:

> Peter Dyballa wrote:
> > I don't see so many changes from stable GNU Emacs 21.4 to GNU Emacs 
> 22
> > from CVS. The latter still can't handle completely the case of 
> dealing
> > with more than one ISO or Unicode encoding.
>
> Did you happen to turn off unify-8859-on-encoding-mode?  (It's enabled
> in Emacs 22 by default.)  Did you try turning on
> unify-8859-on-decoding-mode?

In my 'standard' edition of GNU Emacs 22 I have not changed the default 
values. Adding

        (setq unify-8859-on-encoding-mode nil)
        (setq unify-8859-on-decoding-mode t)

makes no change in that field which I address in my writing: I can't 
i-search again for the same 8bit character when I change from buffer a 
in encoding a to buffer b in encoding b.

> > And printing is still bad
> > too! This message comes from trying to print a buffer in ISO 
> 8859-15/ISO
> > Latin-9:
> >
> >     These characters in the buffer can't be printed:
> >     €,  , ¡, ¢, £, €, ¥, Š, §, š, ©, ª, «, ¬, ­, and more...
> >     Click them to jump to the buffer position,
> >     or C-u C-x = will give information about them.
> >
> > And it's not even true, since I can see ¡, ¢, £, §, ©, ª, «, ¬, ­ ...
>
> Have you submitted a bug report?

Not yet, but you motivate me to do so! (Again. I think I reported 
something similiar earlier this year and Kenichi Handa then made some 
changes that the message about unprintable characters became more 
realistic, being based on the actual glyphs of the encoding used. He 
promised that in Unicode Emacs 23 the problem will be solved. Could be 
some backlash happened in the meantime that the reports are not true 
again ... as in real life and its politics. Or politicians?)

> Also, that error message includes 4 characters that are outside ISO
> 8859-x: 0x80 (twice), 0x8A, and 0x9A.  Your message was sent as:
>
>         Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
>         Content-Transfer-Encoding: quoted-printable

I work on Mac OS X and use Apple's Mail. I think it's so clever to use 
the encoding of the incoming message for the response's encoding. 
Looking at what Mail tells me about this eMail's encoding I see 
'US-Standard' checked! Whatever this means ... I mean, outside the U.S. 
of A! The characters from outside any ISO 8859 encoding you mention can 
come from copying them in GNU Emacs, transferring them to the Mac OS X 
clipboard and then pasting them into Mail. At least *I* can see in your 
citation the same shapes that I saw in Emacs and in my message!

> > Is it really that complicated to determine the system's TrueType 
> fonts
> > and use the Unicode encoded ones to print in whatever ISO, Greek, or
> > Cyrillic encoding? Or in Arabic or Hebrew?
>
> I don't know, but I suspect it is hard to do for all the platforms that
> Emacs supports.

It can't be that problematic. There is just a handful of Unicode 
encoded fonts which are regular parts of a Linux or BSD distribution. 
Kind of a standard base edition. And there is too customisation. So a 
'rich' user can make use of her or his set of fonts.

But the problem actually is inside the Elisp code for ps-print: it does 
a censorship on those glyphs it supposes they can't be printed. Here is 
an excerpt from an ISO 8859-15 encoded buffer:

          = 240 = 160 = A0 = U+00A0 =    C2 A0 : NO-BREAK SPACE
        ¡ = 241 = 161 = A1 = U+00A1 =    C2 A1 : INVERTED EXCLAMATION MARK
        ¢ = 242 = 162 = A2 = U+00A2 =    C2 A2 : CENT SIGN
        £ = 243 = 163 = A3 = U+00A3 =    C2 A3 : POUND SIGN
        € = 244 = 164 = A4 = U+20AC = E2 82 AC : EURO SIGN
        ¥ = 245 = 165 = A5 = U+00A5 =    C2 A5 : YEN SIGN

and here is that same region as censored by ps-print:

        LHL
        /f0 F
        (\240) S
        /f0 F
        ( = 240 = 160 = A0 = U+00A0 =    C2 A0 : NO-BREAK SPACE) S
        LHL
        /f0 F
        (\241) S
        /f0 F
        ( = 241 = 161 = A1 = U+00A1 =    C2 A1 : INVERTED EXCLAMATION MARK) S
        LHL
        /f0 F
        (\242) S
        /f0 F
        ( = 242 = 162 = A2 = U+00A2 =    C2 A2 : CENT SIGN) S
        LHL
        /f0 F
        (\243) S
        /f0 F
        ( = 243 = 163 = A3 = U+00A3 =    C2 A3 : POUND SIGN) S
        LHL
        1 1 SB
        /f0 F
        ( = 244 = 164 = A4 = U+20AC = E2 82 AC : EURO SIGN) S
        LHL
        /f0 F
        (\245) S
        /f0 F
        ( = 245 = 165 = A5 = U+00A5 =    C2 A5 : YEN SIGN) S

[LHL does a 'hard' linefeed, F selects an encoded font /f0, S does 
complicated things with the string in (), SB paints an empty box]

The Euro sign is taken away, although since five years or even longer 
no PostScript printer entered the market without being able to print a 
€. And you too see that ps-print leaves ¡, ¢, £ in the PS output -- 
although claiming the contrary!

From these bugs I'd like to estimate that Unicode Emacs 23 will be 
released before GNU Emacs 22. It's worth to go directly to Unicode, 
without wasting the valuable resources of the developers.

> > I'd look forward to Unicode Emacs 23.
>
> You'd be looking very far forward.

The elder you become, the easier it gets to look very far away! (I am 
writing from own experience.)

--
Greetings

  Pete                           <]
             o        __o         |__    o       HPV, the real
    ___o    /I       -\<,         |o \  -\),-%     high speed!
___/\ /\___./ \___...O/ O____.....`-O-'-()--o_________________