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 these issues.
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.
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]: http://www.unicode.org/reports/tr51
You know, the fact that this consortium ever took emoji into
consideration immediately justifies to include everything everyone ever
wanted. There is no such thing as important data including emoji. :)
Jean-Francois Colson:
I need a few tens of characters for a conlang I’m developping. ☺
Except two or three control characters don't make a con language.
Also, if you don't like con languages in Unicode, what's this:
http://unicode.org/charts/PDF/U1F700.pdf
The problem is that Unicode only encodes characters which are
effectively used today or which have been used in the past. It doesn’t
encode characters which could perhaps be used in a hypothetical new
programing language in the future.
So you want the font encoding scheme to be a limitating factor for new
things?
Pierpaolo Bernardi:
How would your proposed character be displayed as plain text?
There is no such thing as plain text.
Even line breaks and tabs are a matter of interpretation. It's just that
they usually have typographic semantics, even in programming editors,
with all the side effects.
In very simple (and with that I mean shitty or not even remotely
programming oriented) editors, it may show like a control character, like ␄.
Browsers and any editor passing the "based on scintilla" complexity mark
of course should display something that makes more sense, like an arrow
or ⍈ plus surrounding space.
Unicode is a standard for plain text. If you require a special IDE
for your programming language then why use plain text at all?
Because binary custom encoded databases or blob files are the death of
interoperability.
Konstantin Ritt:
Easier than latin1, a layout one could find on [almost] every
keyboard? Good luck.
Also:
Jean-Francois Colson:
Hard to input? Not harder than the new symbols you’d like to propose.
That’s only a matter of keyboard layout and input method.
Indent by pressing tab and insert the literal thing by pressing ".
Nothing changes, the IDE/editor does the work on the fly.
Just that you have clean semantics, interoperability and customizability.
Beat that, APL. Where you would >10 key bindings or an annoying software
keyboard.
I’ve never used APL so I don’t remember the meanings of its symbols,
but couldn’t ⍘ U+2358 APL FUNCTIONAL SYMBOL QUOTE UNDERBAR or ⍞ U+235E
APL FUNCTIONAL SYMBOL QUOTE QUAD work as “string litteral quotes” in a
new programming language?
That's a good idea.
That still leaves the indentation character, which is harder than that,
because one would want a control character with certain semantics.
E.G.: For programming editors it would make sense to only allow it after
line breaks and convert other occurences into tabs.
If the IDE inputs your new character when you press tab, then your new
character is a tab…
Not if it detects the beginning of a line.
Best regards
A. Z.
_______________________________________________
Unicode mailing list
Unicode@unicode.org
http://unicode.org/mailman/listinfo/unicode
