Hi,
On 2 May 2013 20:56, Kristian Høgsberg wrote:
> On Tue, Apr 16, 2013 at 06:19:47PM -0700, Bill Spitzak wrote:
>> I would remember the positions of styling as bytes. However the
>> renderer can render as though they are moved left to the first break
>> between glyphs (ie it will preedit-highli
On 05/02/2013 09:56 PM, Kristian Høgsberg wrote:
> On Tue, Apr 16, 2013 at 06:19:47PM -0700, Bill Spitzak wrote:
>> Jan Arne Petersen wrote:
>>
>>> I completely agree that editing UTF-8 text as UTF-8 is fine.
>>>
>>> I am just wondering if we should have offsets in "Unicode code points"
>>> (with t
On Tue, Apr 16, 2013 at 06:19:47PM -0700, Bill Spitzak wrote:
> Jan Arne Petersen wrote:
>
> >I completely agree that editing UTF-8 text as UTF-8 is fine.
> >
> >I am just wondering if we should have offsets in "Unicode code points"
> >(with the addition that for invalid byte sequences each byte c
Jan Arne Petersen wrote:
I completely agree that editing UTF-8 text as UTF-8 is fine.
I am just wondering if we should have offsets in "Unicode code points"
(with the addition that for invalid byte sequences each byte counts as
one code point) or offsets in bytes.
The reason for the offset in
On 04/16/2013 06:06 PM, Bill Spitzak wrote:
> On 04/16/2013 01:16 AM, Jan Arne Petersen wrote:
>
>> But we still need to think about how to handle invalid byte sequences
>> anyways. What do we expect a toolkit to do when text with invalid byte
>> sequences is inserted with commit_string? How to ha
There seem to be some claims that you cannot random-access a UTF-8
string with errors in it. This is false if you define the handling of
errors to strict patterns that do not contain valid encodings, and
easiest with my recommendation that errors only be 1 byte long.
To make this sample code s
在 2013年4月16日 星期二 10:16:53，Jan Arne Petersen 写道：
> Hi,
>
> On 04/15/2013 09:14 PM, Bill Spitzak wrote:
> > Jan Arne Petersen wrote:
> >> * Changes offsets to be Unicode character instead of byte based
> >
> > No, PLEASE DON'T DO THIS!!!
> >
> > You think you are making things "easier" but you are
On 04/16/2013 01:16 AM, Jan Arne Petersen wrote:
But we still need to think about how to handle invalid byte sequences
anyways. What do we expect a toolkit to do when text with invalid byte
sequences is inserted with commit_string? How to handle
delete_surrounding_text with the byte offsets not
Hi,
On 04/15/2013 09:14 PM, Bill Spitzak wrote:
> Jan Arne Petersen wrote:
>
>> * Changes offsets to be Unicode character instead of byte based
>
> No, PLEASE DON'T DO THIS!!!
>
> You think you are making things "easier" but you are making it much much
> harder.
My main reason was that EFL, IBu
Jan Arne Petersen wrote:
* Changes offsets to be Unicode character instead of byte based
No, PLEASE DON'T DO THIS!!!
You think you are making things "easier" but you are making it much much
harder. You may not believe it, but "how many characters are in this
UTF-8" will generate dozens of d
From: Jan Arne Petersen
This patch series:
* Fixes serials handling in text protocol
* Changes offsets to be Unicode character instead of byte based
* Adds documentation to the protocols
* Adds wl_ prefixes to the interfaces.
It is based on the previous "Extend text protocol for IBus support"
J
11 matches
Mail list logo
