Kenichi Handa <[EMAIL PROTECTED]> writes:
>> 2, apply the patch below.
>
> I don't understand why you need it because the default value
> of selection-coding-system is compound-text-with-extensions,
> and thus the patch won't change the behavior.
Yes, the default value of selection-coding-system
On 3/8/06, Zhang Wei <[EMAIL PROTECTED]> wrote:
> The arch repository can't keep up with the CVS repository.
The arch repository is not synced in real-time. I typically do it 1
or 2 times a day.
-Miles
--
Do not taunt Happy Fun Ball.
___
emacs-pretes
Kenichi Handa <[EMAIL PROTECTED]> writes:
> It seems that ctext decoder of crxvt-gb is buggy. It
> expects extra "ESC ( B" (ASCII designtion) after Chinese
> characters encoded using an extended segment. According to
> the spec of CTEXT, it is not necessary to produce that extra
> designation se
Kenichi Handa <[EMAIL PROTECTED]> writes:
> I've just installed fixes. Could you please try again? The
> locale of Emacs and crxvt-gb must be the same. Then both
> ways of cut&paste should work well now in zh_CN.GB and
> in zh_CN.GBK.
The arch repository can't keep up with the CVS repository.
In article <[EMAIL PROTECTED]>, Zhang Wei <[EMAIL PROTECTED]> writes:
> This time Emacs works well with crxvt-gb under zh_CN.GB2312, but
> there's still some strange behavior can be observed under zh_CN.GBK,
> if the sequence to be paste to crxvt-gb is a mixed sequence, I mean a
> english characte
Kenichi Handa <[EMAIL PROTECTED]> writes:
> I've just installed fixes. Could you please try again? The
> locale of Emacs and crxvt-gb must be the same. Then both
> ways of cut&paste should work well now in zh_CN.GB and
> in zh_CN.GBK.
I just made a complete checkout from cvs, and test again, s
In article <[EMAIL PROTECTED]>, Zhang Wei <[EMAIL PROTECTED]> writes:
> The crxvt-gb that I installed comes from the "rxvt-ml" debian package.
> $ crxvt-gb -help
> Usage v2.6.4 : (XPM,utmp,menubar,Chinese (GB),graphics,XGetDefaults)
I see. I've just installed it too, and found what's going
on w
Kenichi Handa <[EMAIL PROTECTED]> writes:
> I'm very confused. You at first sent us the patch for
> decoding "gbk-0" encoded compound text. So, I thought
> crxvt-gb also accepts such an encoding, and thus committed
> the recent change for making ctext-pre-write-convsion
> produce correct "gbk-0"
I've overlooked your reply mail in the flow of bouncing mails...
Anyway, at first, I was careless when I wrote this:
>> 1, (set-selection-coding-system 'chinese-gbk)
>
>Of course you need it. In the other environment, I think
>UTF-8 extended segment (which is more widely accepted)
>should be use
Kenichi Handa <[EMAIL PROTECTED]> writes:
> In article <[EMAIL PROTECTED]>, Zhang Wei
> <[EMAIL PROTECTED]> writes:
>
>> While copy and paste between Emacs unicode branch and a ctext required
>> software such as crxvt-gb, emacs can't format/decode correctly the
>> "gbk-0" encoded compound text.
>
In article <[EMAIL PROTECTED]>, Zhang Wei <[EMAIL PROTECTED]> writes:
> While copy and paste between Emacs unicode branch and a ctext required
> software such as crxvt-gb, emacs can't format/decode correctly the
> "gbk-0" encoded compound text.
> With the following patch, emacs could accept gbk-0
While copy and paste between Emacs unicode branch and a ctext required
software such as crxvt-gb, emacs can't format/decode correctly the
"gbk-0" encoded compound text.
With the following patch, emacs could accept gbk-0 encoded selection,
but still can't paste to crxvt-gb.
btw, because emacs-unic
12 matches
Mail list logo
