Unusual behavior of `gnus-uu-mark-all' (M-P a)

Unusual behavior of `gnus-uu-mark-all' (M-P a)

[Harry Putnam]

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


I've noticed something strange lately with the command
gnus-uu-mark-all (M-P a)

Certain messages do not get marked anymore.
Recently I removed  (standard-display-european 1) from site-start.el
because it seemed to be causing emacs to see multibyte chars as UTF-8.
Since removing it... The different behavior of `M-P a' showed up.
Put it back in, and M-P a marks the same messages it missed.

gnus-uu-mark-buffer (M-P b) does the job with or without
(standard-display-european 1).

Anyone know what is happening here?

Below are two sections.  First section shows a summary line taken
from summary  buffer with (standard-display-european 1) in init files.

This same line is missed with (standard-display-european 1) removed
The data below `=====' is gotten by placing cursor on one of the
subject chars and pressing C-u C-x =:
The double ===== marks the second section where I did the same thing
on two summary lines with (standard-display-european 1) removed. 

=============================================================
=============================================================
Section 1:

1 line from summary buffer:   
    1O# 08-May [  15: ÷ë                  ] »Ú½§òÊþØ·»ô20ª
========================================================
  character: ° (0260, 176, 0xb0)
    charset: eight-bit-graphic (8-bit graphic char (0xA0..0xFF))
 code point: 176
     syntax:   	which means: whitespace
   category:
buffer code: 0xB0
  file code: not encodable by coding system iso-latin-1
  font: -Adobe-Courier-Bold-R-Normal--14-100-100-100-M-90-ISO8859-1

There are text properties here:
  gnus-number          97
  face                 gnus-summary-normal-ancient-face

====================================================================
====================================================================
Section 2 

With  (standard-display-european 1) commented out

Two from summary buffer

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


 1O  09-May [   4: 晓丽                ] 来看我的照片,体验另类刺激!

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

 1O  09-May [  34: Бесплатно посещаемос] БЕСПЛАТНО УВЕЛИЧИТЬ ПОСЕЩАЕМОСТЬ САЙТА
====================================================

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

  character: 看 (0117664, 40884, 0x9fb4)
    charset: chinese-gb2312 (GB2312 Chinese simplified: ISO-IR-58.)
 code point: 63 52
     syntax: w 	which means: word
   category: C:Chinese (Han) characters of 2-byte character sets   
             c:Chinese
	     |:While filling, we can break a line at this character.  
buffer code: 0x91 0xBF 0xB4
  file code: not encodable by coding system iso-latin-1
       font: -ISAS-Fangsong 
              ti-Medium-R-Normal--16-160-72-72-c-160-GB2312.1980-0

There are text properties here:
  gnus-number          104
  face                 gnus-summary-normal-ancient-face

[-- Attachment #5: Type: text/plain, Size: 526 bytes --]


-- 
  character: В (07062, 3634, 0xe32)
    charset: cyrillic-iso8859-5
	     (Right-Hand Part of Latin/Cyrillic Alphabet 
             (ISO/IEC 8859-5): ISO-IR-144.)
 code point: 50
     syntax: w 	which means: word
   category: y:Cyrillic  
buffer code: 0x8C 0xB2
  file code: not encodable by coding system iso-latin-1
    Unicode: 0412
       font: -Misc-Fixed-Bold-R-Normal--14-130-75-75-C-70-ISO8859-5

There are text properties here:
  gnus-number          105
  face                 gnus-summary-normal-ancient-face

Re: Unusual behavior of `gnus-uu-mark-all' (M-P a)

[Dave Love]

Harry Putnam <hgp@sbcglobal.net> writes:

> Recently I removed  (standard-display-european 1) from site-start.el
> because it seemed to be causing emacs to see multibyte chars as
> UTF-8.

That's the right thing to do, but as far as I know, Gnus should still
DTRT in unibyte mode to the extent it can while unibyte is an
advertised feature (unfortunately).

[The only real advantage I can think of for unibyte mode is that
multibyte may load a lot more fonts into an X server.  There's been
much mis- and dis-information about multibyte mode (which is the
default for good reasons).  Please ignore it.  Note that there appear
to be problems with XEmacs's implementation which lead to it
defaulting to not providing multilingual features, but Emacs is
different.]

Currently `mm-multibyte-p' is defined to refer to the current buffer
-- it was - previously ambiguous -- and is used in various places
which should test the global value.  I've made some comments in the
code about that recently but haven't fixed them and suspect changes
will cause short-term breakage in multibyte sessions due to confusions
in the way coding conversion is done.