I don't have one anymore to test though, but I used to use the mac layout on Linux for a while exactly for composing using alt.
Or maybe this has changed (back) in a recent OS update? I'm running 12.0beta on this machine.
The dead-keys like Opt-E for acute only work with a small set of letters in the standard US keyboard layout, although it's possible for a different layout to support more -- subject to the combinations existing as precomposed characters in Unicode. (For other combinations, you'd need to enter a combining accent after the letter, and rely on the font to supports placing it properly.)
edit: Looks like it's supposed to work, I don't know what I'm doing wrong: https://help.ubuntu.com/community/GtkComposeTable
edit: hold on, that's only in Firefox. Anywhere else, comma+c does 莽 and apostrophe+c does 膰
If you鈥檙e not in en_US you can find other locales and their Compose sequences in the nls directory.
Yet your sentence, clearly written in English, contains all these characters.
You are supposed to be able to type them if you write in English. Also, if you are in polite company, it's alright to drop the occasional Greek word. So here we are: if you can fully write in English, you can use all these characters.
Ascii-only is the modern equivalent of all-caps. Something archaic, still used by old people with hopelessly limited input devices.
Forgive me if the above is incorrect, but in case it is:
The majority of your world's fellow humans, wishing to be comp developers, already spent months or years (combined) of their individual lives in order to learn English as non-native-speakers to do just that.
Your "whining" (yes, it's intended to be somewhat impolite, but I don't think it's unreasonable given the above) that, in case 膯 becomes the next-gen well-known programming tool, you'll have to spend maybe a couple of hours to update your keyboard mapping or learn some other way of quickly typping '膯' invokes 0 of my (and many others') empathy. Though many were helpful to suggest you how to do that quickly/correctly.
I hope my words will be deemed as 'fair enough given the context' :)
And would the onus not be on the screen reader to not produce gibberish for a simple letter?
> creating a lookup table for all the unicode material out there might've been considered impractical or performance-hitting for the developers.
just doesn't ring true to me in any way for current software. I understand that people can be using older software, which is why I strive to restrict myself to ASCII as much as possible for the widest possible support for my users, but my software also supports unicode identifiers, up to and including a whole unicode table to talk about confusables[1]. And not all TTS software "ignores" characters, which is why people advice against using 饾憮饾憥饾憶饾憪饾懄 unicode because it doesn't get read as text but instead each character is described individually. (This is also something that TTS software should support for their users' sake, but I digress.)
To be clear, it is reasonable to be practical and cater to the software as it exists, but that doesn't mean that we shouldn't ask for better software.
[1]: this is thanks to the crate unic-udc containing this information: https://github.com/open-i18n/rust-unic
I use such characters every day because my native language has them, so maybe that's why my tooling is naturally chosen/adapted to support it.