# Syntax: Escape hatch for unicode haters

**URL:** <https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363>\
**Category:** Internals & Design\
**Tags:** syntax, unicode\
**Created:** [January 4, 2024, 11:55pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363 "2024-01-04T23:55:47Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [January 5, 2024, 3:08pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/21 "2024-01-05T15:08:13Z")

</div>

> [@sijo](#):
>
> Do you actually use an editor that doesn’t support `\alpha<TAB>` when writing Julia code?

No, vscode, repl and jupyter all support it.

I do write tiny snippets in the browser / github / slack, and grep and meld (for `git mergetool`). These are the points where my software stack is lacking because I did not adopt the emacs operating system.

I heard from @Tamas_Papp about how he deals with unicode in git merge conflicts (emacs ftw). Do your git mergetools support `\alpha<TAB>` @sijo @mbauman ?

I can figure out a tab-completion. But I will forget it 5 minutes later unless it stares me into the face, as latex source files do, or unless they stared me into the face for many years, as many latex sequences did.

In sum, using unicode in julia is just not worth it for me, I can use `in`, `xor`, `union` instead of \in, `$\xor$` (you see me struggling putting that char into my browser input box right now!) or \cup, at the price of some more parentheses.

Most APIs are light on unicode, so can be used without too much annoyance.

Rare real PRs to projects that use unicode are also not an issue, if somebody is asked to review it then I can take the pain to format it. I will suffer when rebasing / solving merge conflicts.

Quick edits or quick `@eval` to try something out cen be very annoying though. That would become simpler if the parser could do unicode escaping.

Same with interacting with code on discourse. If it contains unicode, I will either take the time to completely refactor the code, or I will not interact at all.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [January 5, 2024, 3:09pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/22 "2024-01-05T15:09:13Z")

</div>

> [@foobar\_lv2](#):
>
> Otherwise, the set of programming languages that permit full unicode variable or operator space is pretty limited, as far as I know.

Most modern languages support unicode identifiers these days:

- Python ([2. Lexical analysis — Python 3.3.7 documentation](https://docs.python.org/3.3/reference/lexical_analysis.html#identifiers))
- Rust ([Identifiers - The Rust Reference](https://doc.rust-lang.org/reference/identifiers.html))
- Swift ([Documentation](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/lexicalstructure/#Identifiers))
- Go ([The Go Programming Language Specification - The Go Programming Language](https://go.dev/ref/spec#Identifiers))
- C# ([C# identifier names - rules and conventions - C# | Microsoft Learn](https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/identifier-names))
- Raku ([identifiers | Raku Documentation](https://docs.raku.org/syntax/identifiers))
- Java ([Charsets and Unicode Identifiers in Java - DZone](https://dzone.com/articles/charsets-unicode-identifiers-in-java))
- Ruby ([Coding Ninjas Studio](https://www.codingninjas.com/studio/library/identifiers-in-ruby))
- C++ ([Identifiers - cppreference.com](https://en.cppreference.com/w/cpp/language/identifiers))
- Heck, even C99 has rudimentary support… but as the oldest one here, it ironically allows `int \U03B1 = 2;` while leaving `α = 2;` implementation defined. ([Identifier - cppreference.com](https://en.cppreference.com/w/c/language/identifier)).
- Javascript also allows unicode as well as using unicode escapes in identifiers somewhat similarly to C ([Valid JavaScript variable names in ES5 · Mathias Bynens](https://mathiasbynens.be/notes/javascript-identifiers))

Of the languages I thought of here, only Perl, R, and Fortran don’t seem to support unicode. And only C and Javascript support using `\U` or `\u` escapes. None support latex- or html-like entity names.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [January 5, 2024, 3:19pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/23 "2024-01-05T15:19:21Z")

</div>

Incidentally, while the examples in this topic are about LaTeX math, note that Unicode has been a boon to speakers of languages other than English.

I am not sure which other languages you speak/write, but maybe you are aware of the mess with various encodings etc that preceded unicode and specifically utf8.

“Hating” Unicode is a very English-centric view.

---

<div class="post-metadata">

**Author:** ![sijo](https://avatars.discourse-cdn.com/v4/letter/s/da6949/32.png) [@sijo](https://discourse.julialang.org/u/sijo)\
**Post date:** [January 5, 2024, 3:25pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/24 "2024-01-05T15:25:38Z")

</div>

> [@foobar\_lv2](#):
>
> Do your git mergetools support `\alpha<TAB>` @sijo @mbauman ?

I use vim for that so yes.

You give a good example with the Julia Discourse: I also find it annoying that Unicode aliases are not available there. I copy-paste from a Julia REPL in these cases, not ideal but still worth it for me.

Personally I would be annoyed to encounter Julia files that use e.g. `a \\xor b` instead of `a ⊻ b` (I find it ugly and less readable). And there’s no easy fix for Unicode lovers: To see nice looking code I would have to configure all the _viewers_, which are much more numerous and typically more difficult to configure than editors (not sure how I would do it in my browser for example).

---

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [January 5, 2024, 3:31pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/25 "2024-01-05T15:31:26Z")

</div>

> [@Tamas\_Papp](#):
>
> But (again), other IDE’s support LaTeX entry just fine. I think VS Code does, too, but I have no personal experience with it.

I’m not saying that IDE support for julia or latex is bad.

I’m saying that it is perfectly possible to edit latex sources or 90+% of julia sources with e.g. `nano` or whatever textbox `meld` uses.

But it is extremely painful to edit julia sources that go heavy on unicode without IDE-like tooling.

The editing experience without specialized tooling is part of the of “plain” in “plaintext”.

> [@sijo](#):
>
> The second goal is trickier, but as I understand your proposal doesn’t adress it completely either: even if the language improves support for unicode aliases, this won’t help you find `α` when you’re using `less` or other tools…

Yep, it doesn’t completely solve it. But it allows for projects to locally enforce auto-formatting in either direction (normalize away all escape sequences, or normalize away all non-ascii identifiers/operators). Then the “marketplace of github” could figure out which way is better for more people. I could start quick “try something out” sessions by `git clone ...` followed by hypothetical `juliafmt --escapeUnicodeSyntax .`.

> [@sijo](#):
>
> To see nice looking code I would have to configure all the _viewers_, which are much more numerous and typically more difficult to configure than editors (not sure how I would do it in my browser for example).

Interesting dichotomy, thanks for pointing that out. More viewers than editors, but the pain from bad editor is larger than the pain from bad viewer.

I think most syntax highlighting is powerful enough to display `a \\xor b` in the other way that would require touching the mouse to copy-paste from the REPL.

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [January 5, 2024, 9:43pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/26 "2024-01-05T21:43:35Z")

</div>

> [@foobar\_lv2](#):
>
> The editing experience without specialized tooling is part of the of “plain” in “plaintext”.

This just tells me that many editors are too primitive support plain text. I frankly find that unacceptable, and think that sort of editors should be abandoned.

(BTW, my name contains several non-ascii characters, and I’m sick of the lagging support in many systems.)

---

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [January 6, 2024, 2:37pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/27 "2024-01-06T14:37:35Z")

</div>

> [@Tamas\_Papp](#):
>
> Incidentally, while the examples in this topic are about LaTeX math, note that Unicode has been a boon to speakers of languages other than English.
> 
> I am not sure which other languages you speak/write, but maybe you are aware of the mess with various encodings etc that preceded unicode and specifically utf8.
> 
> “Hating” Unicode is a very English-centric view.

Sorry, I mis-spoke. Unicode in general, and specifically utf8, are awesome! Even though I very rarely need to leave latin-1 (German, English, occasional French), it used to be a mess.

And the unicode support in the julia runtime with `String` is really good, and I like the index-by-address that so many people are surprised by.

The problem is UI/OS design around input of foreign characters. “foreign” means “foreign to the user’s keyboard layout”, so my native German is foreign to me, in this context – good ergonomics for special characters is more important for me than good ergonomics for typing my native language.

OS / programming languages are already super US centric in this often overlooked way, starting with simple things like slash `/` as path separator in unix-like systems. It’s not like Germans were stupidly obstinate unix-haters when placing their slash, keyboard layouts evolved from typewriters that predate digital computers.

Latex has a very good solution: you can use utf8 non-ascii chars in source files, but you can also use the latex escape sequences.

Editors like emacs julia-mode can add sugar like displaying `\alpha` as \alpha, or emitting the utf8 character upon `\alpha<TAB>`. But editor support is not mandatory for editing latex sources, which is important for users who live in a more fragmented world of input-handlers, i.e. who don’t run the emacs operating system.

Afaiu no other language than latex has a good solution, besides “don’t use foreign characters in sections that you need to edit”. (html is very borderline)

That works really well if foreign characters are confined to string literals or source-code comments or niche projects that you don’t deal with.

Alas, the problem in the julia ecosystem is that use of foreign characters in relevant parts of source files is actually medium-wide spread.

And I see no significant appreciation in the community for the annoyances that this causes, and for the need of comprehensive tooling around this.

> [@mbauman](#):
>
> TeX — while Turing complete — isn’t really a programming language. It’s a typesetting engine.

This is not really about programming languages, it is about the ergonomics of the plain-text file format that are julia source files (`.jl`). Ergonomics are determined not just by the spec, but also available tooling, typical editing contexts (source control needed? 3-way merges common? is greppability important?) and typical real-world usage patterns (how typical is it to have to type/edit “foreign” characters?).

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [January 6, 2024, 3:35pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/28 "2024-01-06T15:35:36Z")

</div>

A post was split to a new topic: [Better explicit support for Unicode encodings?](https://discourse.julialang.org/t/better-explicit-support-for-unicode-encodings/108442)

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [January 6, 2024, 7:21pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/29 "2024-01-06T19:21:11Z")

</div>

The analogy with TeX only really makes sense to me if there existed `\commands` with unicode in them **and** there was an alternate way to call those. Your post isn’t about ways of _outputting_ unicode with ASCII stand-ins (which as you note Julia’s string syntax can do), but rather about ways to _refer_ to unicode identifiers using a secondary ASCII form.

As I noted above, nearly every modern programming language supports unicode identifiers without an ASCII “escape hatch”. Sure, perhaps Julia is an outlier in _how much_ it’s used, but you’ve encapsulated my thoughts — and where I think the solution belongs — quite well:

> [@foobar\_lv2](#):
>
> The problem is UI/OS design around input of foreign characters.
> 
> […]
> 
> This is not really about programming languages, it is about the ergonomics of the plain-text file format that are julia source files (`.jl`). Ergonomics are determined not just by the spec, but also available tooling, typical editing contexts

There are lots of ways to customize plain text editors and even OS-level keyboard entry these days.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [January 8, 2024, 1:36pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/30 "2024-01-08T13:36:41Z")

</div>

> [@foobar\_lv2](#):
>
> And I see no significant appreciation in the community for the annoyances that this causes, and for the need of comprehensive tooling around this.

Perhaps that is because they are aware of tooling that exists, and are using it. Maybe you could invest in exploring that too.

> [@foobar\_lv2](#):
>
> The problem is UI/OS design around input of foreign characters. “foreign” means “foreign to the user’s keyboard layout”

Most OSs these days do not require that you pick a single keyboard layout from a predefined list: you can extend, mix, switch, etc. I only know about Linux but I would be surprised if OS X didn’t have anything like this (and would be surprised if the Windows solution wasn’t convoluted and clunky 😉).

Insider a particular IDE that is actively maintained, there are usually zillions of solutions. Eg if you are not in a Julia source file in VS code, there is the generic

> **[Unicode Latex - Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=oijaz.unicode-latex)**
>
> Extension for Visual Studio Code - Insert unicode symbols for latex names

and similar extensions. Firefox has

> **[TeX to Unicode – Get this Extension for 🦊 Firefox (en-US)](https://addons.mozilla.org/en-US/firefox/addon/tex-to-unicode/)**
>
> Download TeX to Unicode for Firefox. Convert selected TeX to Unicode in input boxes by pressing 'Alt + W'. Also available in Chrome: https://golopot.github.io/tex-to-unicode/ . 
> Issues can be filed at https://github.com/golopot/tex-to-unicode .

and I am sure we could continue this list for various apps. Even if an app does not have that, you can quickly edit up some UTF8 text in your favorite editor and copy paste.

IMO Unicode entry is best handled by editors, and tweaking Julia (the parser) to support an alternate entry method that is convertd to UTF8 on the fly would be the wrong place to address this.

---

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [January 8, 2024, 2:41pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/31 "2024-01-08T14:41:12Z")

</div>

> [@Tamas\_Papp](#):
>
> Most OSs these days do not require that you pick a single keyboard layout from a predefined list: you can extend, mix, switch, etc. I only know about Linux but I would be surprised if OS X didn’t have anything like this

Here’s what I’m using: [The "U.S. International - Scientific" Keyboard Layout - Michael Goerz](https://michaelgoerz.net/notes/the-us-international-scientific-keyboard-layout/)

---

<div class="post-metadata">

**Author:** ![John\_Gibson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/john_gibson/32/5321_2.png) [@John\_Gibson](https://discourse.julialang.org/u/John_Gibson)\
**Post date:** [January 8, 2024, 2:45pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/32 "2024-01-08T14:45:52Z")

</div>

> [@goerz](#):
>
> Here’s what I’m using: [The "U.S. International - Scientific" Keyboard Layout - Michael Goerz](https://michaelgoerz.net/notes/the-us-international-scientific-keyboard-layout/)

Impressive!

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [January 8, 2024, 3:34pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/33 "2024-01-08T15:34:26Z")

</div>

Oh my goodness, that’s awesome. I’ve long used a [custom DefaultKeybindings.dict](https://web.archive.org/web/20160304044802/www.hcs.harvard.edu/~jrus/site/cocoa-text.html) file to achieve this (as well as adding additional emacs-like cursor/editing actions), but that only works in some applications.

It looks like your link to Ukelele is broken on your blog — it’s here: [Ukelele - SIL Language Technology - SIL Language Technology](https://software.sil.org/ukelele/)

---

<div class="post-metadata">

**Author:** ![jkopper](https://avatars.discourse-cdn.com/v4/letter/j/958977/32.png) [@jkopper](https://discourse.julialang.org/u/jkopper)\
**Post date:** [January 8, 2024, 9:15pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/34 "2024-01-08T21:15:02Z")

</div>

> [@Tamas\_Papp](#):
>
> > [@foobar\_lv2](#):
> >
> > And I see no significant appreciation in the community for the annoyances that this causes, and for the need of comprehensive tooling around this.
> 
> Perhaps that is because they are aware of tooling that exists, and are using it. Maybe you could invest in exploring that to

Counterpoint: Perhaps many people are sufficiently annoyed that they’re opting out of using Julia altogether.

I’m speaking here as someone with no horse in this race. I use Julia as a hobbyist, but the widespread usage of exotic unicode characters is by far the most aggravating part of the language. It truly would be enough to keep me from using Julia if I didn’t have independent interest in some Julia projects. It’s certainly enough for me to keep from bothering to use it professionally.

There are two reasons:

- I worry about being able to enter code.
- I worry about others being able to read my code.

As soon as you require users to have special tooling just to _type their code_, then you have lost a significant portion of developers. Tooling is for _improving_ the coding process, not _enabling_ it. If I can’t ssh into a terminal and edit code with whatever editor happens to be installed, then your language isn’t useful to me. This is a pretty common view, at least outside of the Julia community.

I understand the counter-counterpoint, that the language is targeting a specific set of users (the scientific computing community, basically) and if that community loves unicode function names, then maybe it’s best to design the language and tooling to facilitate that. But I can’t believe “Unicode haters” are truly that rare.

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [January 8, 2024, 9:49pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/35 "2024-01-08T21:49:55Z")

</div>

> [@jkopper](#):
>
> but the widespread usage of exotic unicode characters is by far the most aggravating part of the language.  
> […]  
> If I can’t ssh into a terminal and edit code with whatever editor happens to be installed, then your language isn’t useful to me.

Excuse me for asking, but where do you come across all these exotic characters? I have only ever seen them used very sparingly, and never have I been _forced_ to use it. What APIs are forcing this on the user?

I only use unicode where I feel it improves my code, but I’m not forced to use it anywhere.

> [@jkopper](#):
>
> There are two reasons:
> 
> - I worry about being able to enter code.
> - I worry about others being able to read my code.

The first point is relevant if you are required to use unicode by some API, but otherwise not.

The second point, I don’t understand, actually. Why would you worry about that if you only use ascii characters?

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [January 8, 2024, 9:54pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/36 "2024-01-08T21:54:36Z")

</div>

> [@jkopper](#):
>
> but the widespread usage of exotic unicode characters is by far the most aggravating part of the language.

While many people enjoy using Unicode symbols in their own code (which has happened _because_ it’s become so easy to type with common tooling!), and you’ll see it in a lot of examples and internal implementations, it’s much less common for it to be _required_ to access any API. I don’t recall any feature of the base language or standard libraries that _requires_ non-ASCII symbols, even if there is a Unicode shortcut.

Is there a particular Unicode-only API you’ve been aggravated by?

(The main external package I know whose API requires a _lot_ of Unicode symbols is the Gridap.jl finite-element library, which is a great package but in a specialized mathematical domain where the symbols make a lot of sense. So, while there are examples of such APIs in the Julia ecosystem, I wouldn’t call it “widespread”. It’s a decision that the developers of each package have to make for themselves.)

---

<div class="post-metadata">

**Author:** ![jkopper](https://avatars.discourse-cdn.com/v4/letter/j/958977/32.png) [@jkopper](https://discourse.julialang.org/u/jkopper)\
**Post date:** [January 8, 2024, 10:18pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/37 "2024-01-08T22:18:52Z")

</div>

> [@DNF](#):
>
> Excuse me for asking, but where do you come across all these exotic characters? I have only ever seen them used very sparingly, and never have I been _forced_ to use it. What APIs are forcing this on the user?

Julia Base contains `\circ`, `\leq`, `\in`, `\xor` and many others! My complaint is not that an API may force me to use unicode characters, but that I might have to interact with code that does. While many other languages do support (typically a _very_ limited set of) unicode characters, it’s very rare that people actually use those characters. In Julia, however, they’re everywhere.

Maybe I see code on the internet and I want to copy & paste it into an editor. Good luck to me! I’ll cross my fingers and hope it works.

Maybe I see code that I want to run written as it is in _this very thread_, with people (like me) actively struggling to type a symbol like ≠ (which I had to google and paste into this text box) so they write `\neq` instead and now I have to figure out how to get that input correctly into my code editor. It’s a usability nightmare

> [@DNF](#):
>
> The first point is relevant if you are required to use unicode by some API, but otherwise not.
> 
> The second point, I don’t understand, actually. Why would you worry about that if you only use ascii characters?

You’ve completely misunderstood. I may need to engage with unicode characters if I am working on a Julia project with other people. Even if an API doesn’t require me to use unicode, someone else working on the same codebase may opt to do so.

Imagine now that I too sometimes use unicode. If I change my coding setup for any reason, I may have difficulty working on my existing code (1). If a collaborator doesn’t have a similarly functional setup, then they may have difficulty reading my code (2)

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [January 8, 2024, 11:20pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/38 "2024-01-08T23:20:26Z")

</div>

As a non-ascii person, by name and language, I find the clinging to an outdated character set quite off-putting. The consequences of this attitude is a source of annoyance and uncertainty every time I book an international plane ticket. Anything that can work to spread the acceptance and use of unicode is great in my book.

I have little sympathy or patience with the anti-unicode view, it’s a great improvement to code quality at a small price. Tools that cannot handle this should be abandoned. Someone struggling to interact with unicode in general is a red flag to me.

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [January 8, 2024, 11:32pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/39 "2024-01-08T23:32:51Z")

</div>

> [@DNF](#):
>
> great improvement to code quality at a small price.

I think it is debatable that it is (i) an improvement, and that the (ii) price is small.

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [January 8, 2024, 11:37pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/40 "2024-01-08T23:37:00Z")

</div>

> [@PetrKryslUCSD](#):
>
> I think it is debatable that it is (i) an improvement, and that the (ii) price is small.

I’m presenting my opinion. It is most certainly a great improvement to code containing many mathematical expressions and symbols.

I have noticed hardly any cost at all.

If you don’t like it you are welcome to avoid using it. But the repeated criticism of those who find it pleasant and useful is getting increasingly annoying.

[Previous page](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363.md?page=1)

[Next page](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363.md?page=3)