tchrist% perl -e 'binmode(STDOUT, ":utf8"); print chr(0xFFFF_FFFF_FFFF_FFFF)' | wc -c
Code point 0xFFFFFFFFFFFFFFFF is not Unicode, may not be portable at -e line 1.
13
tchrist% cat myr
#!/usr/bin/perl -lp
use strict;
use warnings;
use utf8;
use open qw(:utf8 :std);
use charnames ":full";
use constant CAMEL => ord "\N{DROMEDARY CAMEL}";
use constant ORDA => ord "A";
tr[a-zA-Z][n-za-mN-ZA-M];
s/(.)/chr(ord($1) - ORDA + CAMEL)/ge;
tchrist% cat rym
#!/usr/bin/perl -lp
use strict;
use warnings;
use utf8;
use open qw(:utf8 :std);
use charnames ":full";
use constant CAMEL => ord "\N{DROMEDARY CAMEL}";
use constant ORDA => ord "A";
s/(.)/chr(ord($1) + ORDA - CAMEL)/ge;
tr[a-zA-Z][n-za-mN-ZA-M];
However, what you can do is splatter those way up in the trans-astral planes and really screw with people.
For example, myr myr | myr | myr | myr produces trans-astral magic.
Remember how Wordstar used to use the high bit to mark characters because ASCII couldn't have that, and so it was stuck at ASCII? You can add 0x20_0000 to a code point to similarly mark it. That has all kinds of interesting fun.
And it keeps the UTF-16 programmers away from your code. :)
Okay, nobody called out Mr Lightness for his silly bytes thing. I hope he isn’t a programmer.
“Bytes”? Like seriously? You seem to have misunderstood Unicode. Pray tell, just which byte were you planning on storing something like € in anyway? The byte 0xA4 for € works only in the ISO-8859-15 encoding — and down that road lies madness. That € takes 3 bytes in this web page’s UTF-8, so if you had your way it would be what, 3 less in the count? Nobody should be talking about bytes, especially when calling them characters, which they aren’t. Only actual logical characters should be mentioned, not incorrect counts related to low-level bit layouts used in this or that encoding system. — tchrist2 mins ago
Oh I see. He’s a C⁺⁺ programmer. Still a sad thing to confuse bytes with characters.
It's really just like with programming languages: if you haven't forgotten how many different languages you've studied and used, you haven't learned enough of them yet.
@JonEricson More seriously, I’ve tried to think of how the message should best be worded, and I honestly find myself fumbling around in the dark. And I even know this stuff. It is a tricky problem. If I “knew” the solution, I promise you that I would suggest it. Just complaining about things without offering fixes isn’t as helpful as patches.
At least with Chrome I can gconftool /apps/metacity/general/button_layout -t string -s ":close" and get rid of the minimize/maximize and instead use dragging-to-side-or-corner-method to resize.
@JonEricson The only consistent solution I can think of from a low-level programming point of view is going to use worst case storage. Suppose you give a user 100 characters. Worst case is 400 bytes whether in UTF-8 or UTF-16. But the most common case is only 100 bytes in UTF-8. So your storage mechanism should not pre-allocate a 400-byte buffer for permanent storage. This becomes troublesome with SQL databases.
I just think the end-user should not be exposed to storage matters that can vary by implementation.
“A friend” recently upgraded from MySQL schema that were accidentally set to use the misnamed utf8 for the character set to using actual utf8mb4, and we they ended up bumping into a rather annoying 768-byte limit on a certain thing.
> InnoDB has a maximum index length of 767 bytes for tables that use a COMPACT or REDUNDANT row format, so for utf8 or utf8mb4 columns, you can index a maximum of 255 or 191 characters, respectively. If you currently have utf8 columns with indexes longer than 191 characters, you will need to index a smaller number of characters.
That was not expected. Very annoying.
I recognize that programmers doing physical-layout of actual bits must absolutely keep byte sizes in mind. But I also believe that end-users should be insulated from that sort of thing.
I almost don’t want to even mention the other issue, but maybe it will help.
@Jo̼nathan does have a combining seagull flying below his o. When I backspace, it eats the entire grapheme. For UX issues, you usually want to count Jo̼nathan as 9 graphemes rather than as 10 code points or as 11 UTF-8 bytes.
People use them so infrequently, that I see no harm in counting code points instead, at least for now. With all these other LANG.stackoverflow.com sites coming online, one may wish to reconsider that. But not now.
When you post a link from Stack Exchange into the chatbox using HTTPS, the link does not onebox. However, if you change the link to HTTP, it works. See the screenshot below:
HTTPS URLs should onebox, too.
> Version 8.0 made small adjustments to line break and other segmentation rules. In particular: ... In UAX #29, the default sentence segmentation rules were adjusted to prevent spurious sentence breaks at full stops occurring interior to words. This is colloquially known as the "Mr.Hamster" problem.
When posting an xkcd link in chat, it doesn't get oneboxed when using the https version of the URI:
http://xkcd.com/660/
vs
https://xkcd.com/660/
The first one gets oneboxed, but the latter just displays the link.
When I paste a link like http://www.xkcd.com/975 on chat, it promptly oneboxes the comic. However if I post the HTTPS version of that https://www.xkcd.com/975 it doesn't. This is true for all other oneboxable links from sites that let you access through HTTPS like YouTube.
Can we get HTTPS links...
The ones closed as a duplicate of the fixed one probably need to explicitly say that they are not duplicates because they are not fixed. Or did I miss that they do so already?
@yellowantphil wot /wɒt/, v. arch. Etymology: var. of wit v.1, due to the carrying over of the preterite-present stem wō̧t (earlier and northern wāt) into other parts of the verb. The substitution occurs first in the 2nd pers. sing. (wāt, wō̧t for wāst, wō̧st) and the plur. (for wĭten) of the present tense, and appears in northern texts from the end of the 13th century. The infin. woten occurs early in the 15th cent., and wotte, wote, wot in the 16th, together with the pres. pple. wotting.
1818 Scott Hrt. Midl. xi, ― Let her know that he she wots of remained here··expecting to see her. 1879 E. Arnold Lt. Asia viii. 22 ― The ant wots of its ways, The white doves know them well.
1530 Tindale Gen. xx. 6, ― I wot it well that thou dydest it in purenesse of thi herte. 1591 Shaks. 1 Hen. VI, ii. v. 16 ― As witting I no other comfort haue. 1724 Ramsay Tea-t. Misc. (1733) I. 8, ― I wat on him she did na gloom. 1816 Scott Old Mort. v, ― Well wot I thou hast not heard the call of a true preacher. 1899 Century Mag. Dec. 300/2 ― They··witting little that the tide has long since turned.
Oh good, I don’t have to file a bug after all. It is already there.
@TimStone In the case of splitting up graphemes, it is indeed erroneously inserted. It must only be inserted between graphemes so it does not separate the combining character from its base: s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿s̳̿e̳̿x̳̿. — tchrist1 min ago
Hm, the chat mess-up is a bit different from the comment mess-up.
When you post a link from Stack Exchange into the chatbox using HTTPS, the link does not onebox. However, if you change the link to HTTP, it works. See the screenshot below:
HTTPS URLs should onebox, too.
When posting an xkcd link in chat, it doesn't get oneboxed when using the https version of the URI:
http://xkcd.com/660/
vs
https://xkcd.com/660/
The first one gets oneboxed, but the latter just displays the link.
That should be "committers", with an extra t.
