[swift-evolution] [Meta] Let's talk TouchBar + Unicode

[Xiaodi Wu]

-1. I'm all for full and complete Unicode support in Swift so that each
person can use their native language to the fullest. But there is value in
saying that the working language for Swift evolution is U.S. English, the
working language for the Swift standard library API is U.S. English, and
the working character set for the core language facilities is ASCII. We've
discussed and rejected union operators in the stdlib; it was a heated
discussion, but we simply can't revisit API naming every six months. The
same argument about the touch bar can be said for iPad soft keyboards.

On Fri, Oct 28, 2016 at 7:35 PM Jonathan Hull via swift-evolution <
swift-evolution at swift.org> wrote:

> Given that Swift supports unicode, and it looks like this TouchBar will
> make typing relevant characters/symbols much more accessible/discoverable,
> I think we should move forward with the assumption that we will be able to
> type (somehow) whatever symbol we feel best represents something, and we
> should start looking for opportunities to use this where it makes sense.
>
>
> The big issue is how to provide similar support for pre-touchbar devices
> (and non-Apple devices), and there are lots of options (of which I will
> list just a few below):
>
> • Have emojis and symbols in the autocomplete list when appropriate by
> typing human readable names (i.e. ‘Dog Face’ instead of U+1F436, or ‘union’
> for ∪).  Optionally, we could have an easy symbol (e.g. $ or ^) which hints
> to the autocomplete that we might want a symbol (similar to how typing @ in
> Facebook brings up an autocomplete list of friends).  Thus typing ‘^u’
> would bring up '∪' near the top of the list (and you could continue typing
> ‘^union’ if needed to disambiguate)
>
> • Allow autocomplete when using the short code (e.g. :dog: for 🐶)
>
> • Have a bar along the bottom of the screen (kind of like the one which
> shows up when a keyboard is docked with an iPad) which maps to the function
> keys, and has similar options to what the TouchBar would have.
>
> • For those using just a text editor, utilities like TextExpander (or the
> built in text expanding capabilities of OS X & other platforms).  Pretty
> much every platform has a built in way to type unicode/emoji.  It may not
> be the easiest, but hey, that is true of many platforms in general.  There
> typically exist utilities to make it easier.
>
> .
>
> My main point, is that we should proceed as if everything we want to do in
> terms of input is possible, and trust that the Xcode team (and other IDE
> developers) will do what is required to make it work (or will speak up in
> particular cases to tell us we are headed in the wrong direction)… as
> opposed to assuming that things are impossible and not pushing the limits
> at all.
>
> Note: I am not saying we should use these things frivolously… just that we
> shouldn’t be afraid to use them when they make a lot of sense (We have
> previously rejected several proposals because they are hard to type on one
> kind of keyboard or another).
>
> Thanks,
> Jon
>
> PS.  I am also ok having some overlap (e.g. both the union operator and
> ‘formUnion’, where one maps to the other) while technology is
> disseminating.  They can always go through a depreciation cycle later if we
> decide to consolidate.  I just don’t think we should wait, because then we
> will never start...
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161029/a702ba19/attachment.html>