"Michel Fortin" wrote in message
news:igo5v2$gq2$1...@digitalmars.com...
> On 2011-01-13 14:11:44 -0500, spir said:
>
>> In Cocoa, string sorting and case-insensitive comparition is also
>> dependent on the user's locale settings, although you can also specify
>> your own locale if the user's
On 2011-01-13 15:39:14 -0500, "Nick Sabalausky" said:
"Andrej Mitrovic" wrote in message
news:mailman.604.1294932704.4748.digitalmar...@puremagic.com...
OT: Spir, do you know if I can change the syntax highlighting settings
on bitbucket? I can't see anything with these gray on dark-gray
color
On 2011-01-13 14:11:44 -0500, spir said:
In Cocoa, string sorting and case-insensitive comparition is also
dependent on the user's locale settings, although you can also specify
your own locale if the user's locale is not what you want. See kde
trying to invent a, hum, "natural", way of sorti
"Andrej Mitrovic" wrote in message
news:mailman.604.1294932704.4748.digitalmar...@puremagic.com...
> OT: Spir, do you know if I can change the syntax highlighting settings
> on bitbucket? I can't see anything with these gray on dark-gray
> colors: http://i.imgur.com/SmLk1.jpg
I'm getting the sam
On 01/13/2011 02:47 PM, Michel Fortin wrote:
On 2011-01-13 06:48:46 -0500, spir said:
Note that D's stdlib currently provides no means to do this, not even
on the fly. You'd have to interface with eg ICU (a C/C++/Java Unicode
library) (good luck ;-). But even ICU, as well as supposed
unicode-a
OT: Spir, do you know if I can change the syntax highlighting settings
on bitbucket? I can't see anything with these gray on dark-gray
colors: http://i.imgur.com/SmLk1.jpg
On 2011-01-13 07:10:09 -0500, Jonathan M Davis said:
However, regardless of what the best way to handle unicode is in
general, I think that it's painfully clear that your average programmer
doesn't know much about unicode. Even understanding the nuances between
char, wchar, and dchar is more
On 2011-01-13 06:48:46 -0500, spir said:
Note that D's stdlib currently provides no means to do this, not even
on the fly. You'd have to interface with eg ICU (a C/C++/Java Unicode
library) (good luck ;-). But even ICU, as well as supposed
unicode-aware typse or librarys for any language, wou
On 01/13/2011 01:10 PM, Jonathan M Davis wrote:
I wasn't saying that code points are guaranteed to be characters. I was saying
that in most cases they are, so if efficiency is an issue, then having properly
abstract characters could be too costly.
The problem is then: how does a library or appl
On Thursday 13 January 2011 03:48:46 spir wrote:
> On 01/13/2011 11:16 AM, Jonathan M Davis wrote:
> > On Thursday 13 January 2011 01:49:31 spir wrote:
> >> On 01/13/2011 01:45 AM, Michel Fortin wrote:
> >>> On 2011-01-12 14:57:58 -0500, spir said:
> On 01/12/2011 08:28 PM, Don wrote:
> >
On 01/13/2011 11:16 AM, Jonathan M Davis wrote:
On Thursday 13 January 2011 01:49:31 spir wrote:
On 01/13/2011 01:45 AM, Michel Fortin wrote:
On 2011-01-12 14:57:58 -0500, spir said:
On 01/12/2011 08:28 PM, Don wrote:
I think the only problem that we really have, is that "char[]",
"dchar[]"
On Thursday 13 January 2011 01:49:31 spir wrote:
> On 01/13/2011 01:45 AM, Michel Fortin wrote:
> > On 2011-01-12 14:57:58 -0500, spir said:
> >> On 01/12/2011 08:28 PM, Don wrote:
> >>> I think the only problem that we really have, is that "char[]",
> >>> "dchar[]" implies that code points is alw
On 01/13/2011 01:45 AM, Michel Fortin wrote:
On 2011-01-12 14:57:58 -0500, spir said:
On 01/12/2011 08:28 PM, Don wrote:
I think the only problem that we really have, is that "char[]",
"dchar[]" implies that code points is always the appropriate level of
abstraction.
I'd like to know when i
13 matches
Mail list logo