Проба пера 1 Prôbá pèrå 2

Проба пера 1 Prôbá pèrå 2

[Vladimir Volovich]

[-- Attachment #1: Type: text/plain, Size: 127 bytes --]

Hi Shenghuo,

When i try to send a message which contains a line given in a subject
(and in the following line):

Проба пера 1 

[-- Attachment #2: Type: text/plain, Size: 817 bytes --]

Prôbá pèrå 2

with UTF-8 setup:

(setq load-path (cons "/usr/share/emacs/site-lisp/mule-ucs" load-path))
(require 'un-define)
(eval-after-load "mm-util"
  '(setq mm-mime-mule-charset-alist
	 (append '((utf-8 cyrillic-iso8859-5 latin-iso8859-1)) mm-mime-mule-charset-alist)))
(setq mm-body-charset-encoding-alist
  '((iso-8859-1 . 8bit)
    (utf-8 . 8bit)
    (koi8-r . 8bit)
    (big5 . 8bit)))

When i try to raw preview a message (C-u M-m P) i get the something like

\320\237\321[  ] \320\277\320\265\321\200\320\260 1 Pr\303\264b\303\241 p\303\250r\303\245 2
where the   ^^^^ is an "Invalid character 013520, 5968, 0x1750" (as reported by C-u M-x =).

The "*Raw MIME preview ...*" buffer is not in raw encoding but in
cyrillic-koi8 (status line contains "-R:%*").

When i try to send a message, i get a warning:


[-- Attachment #3: Type: text/plain, Size: 267 bytes --]

The target text contains the following non ASCII character(s):
                  unknown: \237\321
              composition: [  ]
These can't be encoded safely by the coding system cyrillic-koi8.

Please select one from the following safe coding systems:
  raw-text

[-- Attachment #4: Type: text/plain, Size: 152 bytes --]

Which also looks like a bug. Previewing with M-m P looks Ok, though.

In some previous version of Gnus all worked well with UTF-8 messages...

Best,
v.

Re: Проба пера 1 Prôbá pèrå 2

[Shenghuo ZHU]

>>>>> "VV" == Vladimir Volovich <vvv@vvv.vsu.ru> writes:

VV> Hi Shenghuo,
VV> When i try to send a message which contains a line given in a subject
VV> (and in the following line):

It sounds like the unibyte problem.  But I am out of town and can not
debug it right now.  I'll try to fix it in Wednesday.

-- 
Shenghuo

Re: Проба пера 1 Prôbá pèrå 2

[Vladimir Volovich]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

"ZSH" == Shenghuo ZHU writes:

 ZSH> It sounds like the unibyte problem.  But I am out of town and
 ZSH> can not debug it right now.  I'll try to fix it in Wednesday.

Thanks. BTW, i noticed that my original mail contained subject:

Subject: =?koi8-r?b?8NLPwsEg0MXSwQ==?= 1 =?iso-8859-1?q?Pr=F4b=E1_p=E8r=E5?= 2

while in your reply the subject became:

Subject: Re: =?koi8-r?b?8NLPwsEg0MXSwQ==?= 1
  =?iso-8859-1?q?Pr=F4b=E1_p=E8r=E5?= 2

i.e. it was split into two lines (probably because of `Re: '). Because
of this, it was displayed in the article buffer as

Subject: Re: Проба пера 1

[-- Attachment #2: Type: text/plain, Size: 49 bytes --]

Prôbá pèrå 2

while in the original mail it was


[-- Attachment #3: Type: text/plain, Size: 22 bytes --]

Subject: Проба пера 1 

[-- Attachment #4: Type: text/plain, Size: 192 bytes --]

Prôbá pèrå 2

Is this a correct behavior? Should gnus somehow preserve spaces in the
original subject not converting them into newlines (maybe `hiding'
them in QP or encoded words)?

Best,
v.

Re: Проба пера 1 Prôbá pèrå 2

[Shenghuo ZHU]

>>>>> "VV" == Vladimir Volovich <vvv@vvv.vsu.ru> writes:

[...]

VV> Thanks. BTW, i noticed that my original mail contained subject:

VV> Subject: =?koi8-r?b?8NLPwsEg0MXSwQ==?= 1 =?iso-8859-1?q?Pr=F4b=E1_p=E8r=E5?= 2

VV> while in your reply the subject became:

VV> Subject: Re: =?koi8-r?b?8NLPwsEg0MXSwQ==?= 1
VV>   =?iso-8859-1?q?Pr=F4b=E1_p=E8r=E5?= 2

VV> i.e. it was split into two lines (probably because of `Re: '). Because
VV> of this, it was displayed in the article buffer as

[...]

VV> Is this a correct behavior? Should gnus somehow preserve spaces in
VV> the original subject not converting them into newlines (maybe
VV> `hiding' them in QP or encoded words)?

I read through the RFC 2047. There are no details about how to encode
the pre-existed CRLFs or how to render CRLFs except for those between
two adjacent encoded words. Therefore, I don't know whether it is a
correct behavior. Did I miss something?

-- 
Shenghuo

Re: Проба пера 1 Prôbá pèrå 2

[Shenghuo ZHU]

>>>>> "VV" == Vladimir Volovich <vvv@vvv.vsu.ru> writes:

VV> Hi Shenghuo,
VV> When i try to send a message which contains a line given in a subject
VV> (and in the following line):

VV> Проба пера 1 Prôbá pèrå 2

[...]


VV> When i try to raw preview a message (C-u M-m P) i get the something like

VV> \320\237\321[  ] \320\277\320\265\321\200\320\260 1 Pr\303\264b\303\241 p\303\250r\303\245 2
VV> where the   ^^^^ is an "Invalid character 013520, 5968, 0x1750" (as reported by C-u M-x =).

VV> The "*Raw MIME preview ...*" buffer is not in raw encoding but in
VV> cyrillic-koi8 (status line contains "-R:%*").

It is because Emacs can not render some 8bit characters right.

VV> When i try to send a message, i get a warning:

VV> The target text contains the following non ASCII character(s):
VV>                   unknown: \237\321
VV>               composition: [  ]
VV> These can't be encoded safely by the coding system cyrillic-koi8.

VV> Please select one from the following safe coding systems:
VV>   raw-text
VV> Which also looks like a bug. Previewing with M-m P looks Ok, though.

It is OK for me, possibly because I am using chinese-iso-8bit.
Anyway, I force Gnus use a binary buffer to send mails, so please test
it again after checking out the CVS version.  

Hope this mail is sent out as utf-8 8bit.

-- 
Shenghuo

Re: Проба пера 1 Prôbá pèrå 2

[Janusz S. Bien]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

>>>>>> "VV" == Vladimir Volovich <vvv@vvv.vsu.ru> writes:
>
>VV> The "*Raw MIME preview ...*" buffer is not in raw encoding but in
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>VV> cyrillic-koi8 (status line contains "-R:%*").

This seems to be a common confusion (I am sensitive to it because it
took me quite long to realize it myself). The notion of encoding
(coding system) does not apply to the buffer content. Setting the
coding system to `cyrillic-koi8' affects only how the buffer context
will be represented when you save it in a file, put it in a
kill-ring etc. C-U C-X = allows you to check whether it is at all
possible to represent a character with the current coding system.

>It is because Emacs can not render some 8bit characters right.

There are only two kinds of buffer: multibyte and unibyte. In
multibyte buffer (as I mentioned in one of my previous postings) some
8-bit characters are interpreted as `leading bytes' starting a
multibyte representation of a character.

You cannot set a coding system for a unibyte buffer. If you see "-R"
(or just "--") in the status line, this means that you are looking at
a multibyte buffer.

>It is OK for me, possibly because I am using chinese-iso-8bit.
>Anyway, I force Gnus use a binary buffer to send mails, so please test
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>it again after checking out the CVS version.  

In other words, you use a unibyte buffer to send mails, and in a
unibyte buffer all 8-bit characters are just 8-bit characters. So
your solution used for `chinese-iso-8bit' should work also for
`cyrillic-koi8'.

Best regards

Janusz

---------------------------------------------------------------------
                     ,   
dr hab. Janusz S. Bien, prof. UW
Prof. Janusz S. Bien, Warsaw Uniwersity
---------------------------------------------------------------------
---------------------------------------------------------------------
Na tym koncie czytam i wysylam poczte i wiadomosci offline -
prosze nie oczekiwac szybkiej odpowiedzi!
Data w naglowku to data rozpoczecia pisania listu, a nie jego wyslania.
---------------------------------------------------------------------
On this account I read/post mail/news offline - do not expect 
an immediate answer!
The date in the header refers to the moment when I started to write
the letter, not to the moment when I sent it.
---------------------------------------------------------------------

Re: Проба пера 1 Prôbá pèrå 2

[Shenghuo ZHU]

>>>>> "Janusz" == Janusz S Bien <jsbien@mimuw.edu.pl> writes:

Janusz> You cannot set a coding system for a unibyte buffer. If you
Janusz> see "-R" (or just "--") in the status line, this means that
Janusz> you are looking at a multibyte buffer.

Good. Now I disable-multibyte for the raw preview buffer.

>> It is OK for me, possibly because I am using chinese-iso-8bit.
>> Anyway, I force Gnus use a binary buffer to send mails, so please test
Janusz>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> it again after checking out the CVS version.  

Janusz> In other words, you use a unibyte buffer to send mails, and in a
Janusz> unibyte buffer all 8-bit characters are just 8-bit characters. So
Janusz> your solution used for `chinese-iso-8bit' should work also for
Janusz> `cyrillic-koi8'.

It did not happen even before I forced Gnus use a binary buffer to
send mails.

-- 
Shenghuo