Re: unibyte buffers won't display latin-1 characters

[Kenichi Handa]

I included Karl <karl@gnu.org> in CC: because it seems that
the current problem is related to cyrpt++.

In article <873ct4ughi.fsf@snail.pool>, David Kuehling <dvdkhlng@gmx.de> writes:
> Even if this is a small problem, the question remains, why gzipped files
> are opened as unibyte.  This is extremely inconvenient.  I think that
> also keeps me from reading japanese info files which are (in my Debian
> Woody system) by default gzipped.  Emacs only displays them properly
> when I gunzip them.

> The hole problem also applys to crypt++.

I've just tried crypt++ Ver.2.90.  When I load it, on
reading a compressed file, it is automatically decompressed
even if auto-compression-mode is turned off.  And, in that
case, I confirmed that the file is read into a unibyte
buffer without any code conversion.

But, when I turned on auto-compression-mode, the file is
read into a multibyte buffer with normal code convesion.

Karl, the comment of cyrpt++.el says that you are the
maintainer.   Do you know how to fix this problem?

Here's a reply to the other bug.

> Unfortunately I can't get Emacs
> to display latin-1 characters in unibyte buffers, although the
> documentation states that this is possible.

For that, I've just installed the attached fix in HEAD and
RC.  Could you please try it?

---
Ken'ichi HANDA
handa@etl.go.jp


2002-08-27  Kenichi Handa  <handa@etl.go.jp>

        * xdisp.c (get_next_display_element): In unibyte case, don't use
        octal form for such eight-bit characters that can be converted to
        multibyte char.

Index: xdisp.c
===================================================================
RCS file: /cvs/emacs/src/xdisp.c,v
retrieving revision 1.777
retrieving revision 1.778
diff -u -c -r1.777 -r1.778
cvs server: conflicting specifications of output style
*** xdisp.c     22 Aug 2002 16:52:56 -0000      1.777
--- xdisp.c     27 Aug 2002 00:59:55 -0000      1.778
***************
*** 4258,4271 ****
             the translation.  This could easily be changed but I
             don't believe that it is worth doing.
  
!            Non-printable multibyte characters are also translated
!            octal form.  */
!         else if ((it->c < ' '
                    && (it->area != TEXT_AREA
                        || (it->c != '\n' && it->c != '\t')))
!                  || (it->c >= 127
!                      && it->len == 1)
!                  || !CHAR_PRINTABLE_P (it->c))
            {
              /* IT->c is a control character which must be displayed
                 either as '\003' or as `^C' where the '\\' and '^'
--- 4258,4279 ----
             the translation.  This could easily be changed but I
             don't believe that it is worth doing.
  
!            If it->multibyte_p is nonzero, eight-bit characters and
!            non-printable multibyte characters are also translated to
!            octal form.
! 
!            If it->multibyte_p is zero, eight-bit characters that
!            don't have corresponding multibyte char code are also
!            translated to octal form.  */
!         else if (((it->c < ' ' || it->c == 127)
                    && (it->area != TEXT_AREA
                        || (it->c != '\n' && it->c != '\t')))
!                  || (it->multibyte_p
!                      ? ((it->c >= 127
!                          && it->len == 1)
!                         || !CHAR_PRINTABLE_P (it->c))
!                      : (it->c >= 128
!                         && it->c == unibyte_char_to_multibyte (it->c))))
            {
              /* IT->c is a control character which must be displayed
                 either as '\003' or as `^C' where the '\\' and '^'