Kenichi Handa wrote:
This will be useful for checking UTF-8 validity.
(define-ccl-program ccl-check-utf-8
'(0
((r0 = 1)
(loop
(read-if (r1 < #x80) (repeat)
((r0 = 0)
(if (r1 < #xC2) (end))
(read r2)
(if ((r2 & #xC0) != #x80) (end))
In article <[EMAIL PROTECTED]>, Stefan Monnier <[EMAIL PROTECTED]> writes:
> I think we can't know what should be done, so we should strive for
> simplicity and try to avoid losing information. I.e. just return the
> unibyte string as-is.
Even if it doesn't conform to ICCCM? I'll attach the
rel
Stefan Monnier skrev:
>>> Also IIRC a perfectly valid utf-8 buffer may contain eight-bit-* chars, use
>>> to keep track of valid unicode chars that have no corresponding character in
>>> emacs-mule. So the presence of eight-bit-* chars does not imply that the
>>> utf-8 encoded form of the text wil
>> Also IIRC a perfectly valid utf-8 buffer may contain eight-bit-* chars, use
>> to keep track of valid unicode chars that have no corresponding character in
>> emacs-mule. So the presence of eight-bit-* chars does not imply that the
>> utf-8 encoded form of the text will contain an invalid utf-8
In article <[EMAIL PROTECTED]>, Stefan Monnier <[EMAIL PROTECTED]> writes:
> > AFAIK, only when TEXT is requested, an selection owner can
> > choose the returning type from STRING, COMPOUND_TEXT, or
> > UTF8_STRING. When UTF8_STRING is requested, we should
> > return it or return nothing.
> Also
>> I've checked in a fix that changes UTF8_STRING to STRING if the data
>> doesn't look like UTF8. However, this might give errors too. The only
>> way to be sure to copy raw binary data correctly is by adding a new type
>> (like application-specific/octet-stream). But if we do that, nobody
>>
In article <[EMAIL PROTECTED]>, Jan Djärv <[EMAIL PROTECTED]> writes:
> > AFAIK, only when TEXT is requested, an selection owner can
> > choose the returning type from STRING, COMPOUND_TEXT, or
> > UTF8_STRING. When UTF8_STRING is requested, we should
> > return it or return nothing.
> >
> > And
Kenichi Handa skrev:
In article <[EMAIL PROTECTED]>, "Jan D." <[EMAIL PROTECTED]> writes:
I've checked in a fix that changes UTF8_STRING to STRING if the data
doesn't look like UTF8. However, this might give errors too. The only
way to be sure to copy raw binary data correctly is by adding
In article <[EMAIL PROTECTED]>, "Jan D." <[EMAIL PROTECTED]> writes:
> I've checked in a fix that changes UTF8_STRING to STRING if the data
> doesn't look like UTF8. However, this might give errors too. The only
> way to be sure to copy raw binary data correctly is by adding a new type
> (lik
Jan D. wrote:
Kevin Rodgers wrote:
Jan Djärv wrote:
Chris Moore skrev:
A very simple case which reproduces the bug:
I made a 1-byte file containing just character 0300 (octal),
copied that using Emacs, and clipman started printing its error
message over and over again.
Anyway, I will fi
Kevin Rodgers wrote:
Jan Djärv wrote:
Chris Moore skrev:
A very simple case which reproduces the bug:
I made a 1-byte file containing just character 0300 (octal),
copied that using Emacs, and clipman started printing its error
message over and over again.
I reported this bug firstly to th
Jan Djärv wrote:
Chris Moore skrev:
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
I run the Xfce 4 desktop environment, along with the
xfce4-clipman-plugin applet which collects clipboard entries and
allows me to chose between them from a menu.
I
Chris Moore skrev:
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
I run the Xfce 4 desktop environment, along with the
xfce4-clipman-plugin applet which collects clipboard entries and
allows me to chose between them from a menu.
I have x-select-ena
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
I run the Xfce 4 desktop environment, along with the
xfce4-clipman-plugin applet which collects clipboard entries and
allows me to chose between them from a menu.
I have x-select-enable-clipboard set to t
14 matches
Mail list logo
