But the TAB is still the whitespace character you describe that is accepted
in the programming language using it.
Defining a new codepoint would require the lexical analyzer of these
languages to be modified (you modify those languages).
Clearly, given that the lexiccal items of the programming
2015-02-08 23:54 GMT+01:00 Pierpaolo Bernardi olopie...@gmail.com:
On Sun, Feb 8, 2015 at 11:27 PM, Alfred Zett alfre...@web.de wrote:
That was exactly my thought, so I figured it couldn't harm to have these
a Tab is exactly what you described.
No. It's only half of what I described.
We are being pretty conservative about what we add. There are approximately
1,200 emoji characters now (see tr51), and we're anticipating adding
perhaps 50 per release. And we are encouraging a sticker approach for the
longer term.
On the other hand, I wouldn't be surprised if the 41 emoji
In what character encoding standard, or extension, does ROBOT FACE appear?
Unicode has never been limited to what is in other character encoding
standard or extensions, official or de facto.
Mark https://google.com/+MarkDavis
*— Il meglio è l’inimico del bene —*
On Mon, Feb 9, 2015 at 9:16
Mark Davis ☕️ mark at macchiato dot com wrote:
In what character encoding standard, or extension, does ROBOT FACE
appear?
Unicode has never been limited to what is in other character encoding
standard or extensions, official or de facto.
Of course not. But that's been a stated condition for
Shervin Afshar shervinafshar at gmail dot com wrote:
The issue is with your very rigid interpretation of the criteria for
encoding new symbols. Is appearing in an industry character set
extension an official phrasing that you keep referring to?
It was either from the WG2 Principles and
This thread turns more and more absurd by the email! I apologize to people
on the list who have to tolerate this; it might be noisy and annoying, but
it is important.
Doug Ewell asked:
You mean the one where you said that Gmail has had ROBOT FACE for a long
time?
Let me use copy-paste for
Shervin Afshar shervinafshar at gmail dot com wrote:
Of course not. But that's been a stated condition for labeling
something as compatibility.
It *is* compatibility; go back and read my email where I mentioned
exactly where it was used.
You mean the one where you said that Gmail has had
Of course not. But that's been a stated condition for labeling something
as compatibility.
It *is* compatibility; go back and read my email where I mentioned exactly
where it was used.
↪ Shervin
On Tue, Feb 10, 2015 at 9:03 AM, Doug Ewell d...@ewellic.org wrote:
Mark Davis ☕️ mark at
I was responding to a point that Frédéric Grosshans made [1] about
these symbols being added for compatibility with Japanese telco usage.
That argument could be used for the original emoji set, but not for new
emoji; those are supposed to follow the regular criteria.
The compatibility
- Indentation codepoint, with no fixed defined graphical representation. For
indentation based programming languages.
That wouldn’t be compliant with existing languages and future languages might
use any existing character.
Because:
-- specific clients may want to show it different
I think this discussion is confusing the need for separate syntactic
functions
in formal language definitions with the need for *encoding* of characters.
The distinction between assignment and test for equality has been around for
decades in formal languages, and of course it is almost always
But then it would be incompatible from IDE to IDE, like Python is
incompatible using 2 spaces, 4 spaces and tabs.
It's the data that is important, not the software.
Specifically talking about Python, we should not solve what PEP 8[1] is
intended for in Unicode. Pythonistas and their IDEs are
Frédéric Grosshans frederic dot grosshans at gmail dot com wrote:
The including of emoji was a considerable debate here, with people
strongly against and strongly for. The trick is that they were already
used as digital characters by Japanese Telcos and their millions of
customers. They were
@ John D Burger:
And out of the sudden a war wages what counts as good editor. :D
@ Andre Schappo:
That's a good idea. We need it in the name of science and education. :D
William_J_G Overington:
Hi
You might like the following post.
Shervin Afshar shervinafshar at gmail dot com wrote:
There is no longer any requirement that the robot faces and
burritos appear first in any sort of industry character set
extension, with which Unicode is then obliged to maintain
compatibility.
Only if you don't consider existing usage and
Le 9 févr. 2015 20:27, Doug Ewell d...@ewellic.org a écrit :
Sorry, I can't let the compatibility argument go unchallenged again.
I stand corrected (and I should have known better! )
___
Unicode mailing list
Unicode@unicode.org
I said there was no longer a requirement *that the items appear first in
an industry character set extension*, right?
The issue is with your very rigid interpretation of the criteria for
encoding new symbols. Is appearing in an industry character set extension
an official phrasing that you
I like symbols a lot. But I know that I and a number of people have been
thinking that too much emphasis is being put on emoji.
Michael Everson * http://www.evertype.com/
___
Unicode mailing list
Unicode@unicode.org
Doug Ewell:
Most popularly requested, as a criterion for adding a character, is
absolutely new to Unicode. Earlier I wrote privately to a Unicode
officer about whether PERSON TAKING SELFIE and GIRL TWERKING and
PERSON DUMPING ICE BUCKET OVER HEAD would be ephemeral enough, and got
no reply.
Le 09/02/2015 13:55, Alfred Zett a écrit :
Additionally, people tend to forget that simply because Unicode is
doing emoji out of compatibility (or other) requirements, it does not
mean that now anything goes. I refer folks to TR51[1] (specifically
sections 1.3, 8, and Annex C).
[1]:
Shervin Afshar shervinafshar at gmail dot com wrote:
The issue is with your very rigid interpretation of the criteria for
encoding new symbols. Is appearing in an industry character set
extension an official phrasing that you keep referring to?
It was either from the WG2 Principles and
OK, I will now try to answer all of you in one mail, otherwise it gets
hard to overlook...
Shervin Afshar:
All of the requirements mentioned here can be (and are) implemented in
higher levels of software (like IDEs). IMO, there isn't any need for
adding new characters to Unicode to address
I can't count:
It can be argued — and was, repeatedly and persuasively — that
the initial collection of emoji in Unicode 6.1
6.0
But the additional emoji added to Unicode 6.2 and 7.0
6.1 and 7.0
--
Doug Ewell | Thornton, CO, USA | http://ewellic.org
There is no longer any requirement that the robot faces and
burritos appear first in any sort of industry character set extension,
with which Unicode is then obliged to maintain compatibility.
Only if you don't consider existing usage and popular requests as
requirement and precedence; for
On 9 Feb 2015, at 19:17, Ken Whistler kenwhist...@att.net wrote:
...
The use in C of = and == was badly designed
from the start, and is the source of bezillions of inadvertent programming
errors in practice.
It is the ample oversupply of implicit conversions in combination with the lack
of
It was either from the WG2 Principles and Procedures document, or some
other bit of Unicode/10646 folklore that I've read over the past 22
years of keeping up with Unicode/10646. I should look up the exact
wording.
Yes, please. I would like to have that policy noted for my future use.
Of
Frédéric Grosshans:
Le 09/02/2015 13:55, Alfred Zett a écrit :
Additionally, people tend to forget that simply because Unicode is
doing emoji out of compatibility (or other) requirements, it does
not mean that now anything goes. I refer folks to TR51[1]
(specifically sections 1.3, 8, and
On Sun, Feb 8, 2015 at 9:15 PM, Alfred Zett alfre...@web.de wrote:
Hello everyone,
is there such a unicode block for programming related codepoints?
Conventional search engines as well as wolfram alpha can't answer that, with
the former one leading to all the programming problems that
Le 08/02/15 21:15, Alfred Zett a écrit :
Hello everyone,
is there such a unicode block for programming related codepoints?
Conventional search engines as well as wolfram alpha can't answer
that, with the former one leading to all the programming problems that
occur...
If such a block
Le 08/02/15 22:32, Pierpaolo Bernardi a écrit :
On Sun, Feb 8, 2015 at 9:15 PM, Alfred Zett alfre...@web.de wrote:
[…]
-- unlike tabs or space, it wouldn't be whitespace
[…]
a Tab is exactly what you described.
Not exactly: a tab IS whitespace.
It may sometimes be displayed in a different
Hi Jean-Francois Colson,
I hope this doesn't mess up the mailing list.
- Indentation codepoint, with no fixed defined graphical
representation. For indentation based programming languages.
That wouldn’t be compliant with existing languages and future
languages might use any existing
Hi Pierpaolo Bernardi,
given that you did include my adress as well as the unicode adress I'm
doing the same.
On Sun, Feb 8, 2015 at 9:15 PM, Alfred Zett alfre...@web.de wrote:
Hello everyone,
is there such a unicode block for programming related codepoints?
Conventional search engines
All of the requirements mentioned here can be (and are) implemented in
higher levels of software (like IDEs). IMO, there isn't any need for adding
new characters to Unicode to address these issues.
Additionally, people tend to forget that simply because Unicode is doing
emoji out of compatibility
Le 08/02/15 23:07, Alfred Zett a écrit :
Hi Jean-Francois Colson,
I hope this doesn't mess up the mailing list.
- Indentation codepoint, with no fixed defined graphical
representation. For indentation based programming languages.
That wouldn’t be compliant with existing languages and
On Sun, Feb 8, 2015 at 11:27 PM, Alfred Zett alfre...@web.de wrote:
That was exactly my thought, so I figured it couldn't harm to have these
a Tab is exactly what you described.
No. It's only half of what I described.
It's still a typographical character that implies whitespace and may
Le 09/02/15 00:27, Konstantin Ritt a écrit :
My proposal on the other hand - if implemented right - introduces
some really intuitive looking and easy to input characters, snip
Easier than latin1, a layout one could find on [almost] every
keyboard? Good luck.
Latin-1 is not a keyboard
My proposal on the other hand - if implemented right - introduces some
really intuitive looking and easy to input characters, snip
Easier than latin1, a layout one could find on [almost] every keyboard?
Good luck.
Konstantin
2015-02-09 2:54 GMT+04:00 Pierpaolo Bernardi olopie...@gmail.com:
Le 08/02/15 23:07, Alfred Zett a écrit :
Hi Jean-Francois Colson,
- A codepoint for string literal quotes, that would spare one the
escaping.
I rarely escape quotes.
In a text, I use ’ (U+2019) as an apostrophe and «»“”‘’ as quotes, so
I don’t need to escape them.
When I use PHP to
39 matches
Mail list logo
