No, it does not. Minimum version selection means that the libraries will at least be that version, but it could be substituted for a later version if a transient dependency asks for such.
That I'm reading this blog post at all suggests there is a "market" for a single checksum/version manifest, which data is currently housed in go.sum . This is sad, but, Hyrum's Law and all that.
No it can't, unless someone is spelling it out, or singing it in a song where it is given two notes, or just hyper-correcting their speech based on their knowledge of writing.
Annoyed speech and such can break words into their morae for empahsis, which breaks up dipthongs.
E.g. angry Japanese five-year-old:
ga kkō ni i ki ta ku nā i!!! (I don't wanna go to school!!!)
"nā i" is not the regular way of saying "nai". The idea that "nai" has that as an alternative pronunciation is a strawman.
This kind of misconception seems not uncommon. There's an FAQ on NHK's website [1] that addresses the question of whether 言う(いう) is pronounced "iu" or "yuu". The answer is "yuu", and the article make it clear that: "It's not that [iu] is used for polite/careful speech and [yuu] for casual speech - there is no such distinction."
I think native speakers learn words by hearing them and seeing them written in hiragana, before learning the underlying rules, so they know "too" is written as とう, but might not realize that とう shouldn't be pronounced as "tou" or いう as "iu". These are at least less obvious than cases like は in こんにちは never being "ha".
Personally, if I heard someone say 塔 as "tou" or 言う as "iu", I probably wouldn't count it as incorrect, nor would I even notice the phonetic difference.
[0] https://www.bunka.go.jp/kokugo_nihongo/sisaku/joho/joho/kiju...
[1] https://www.nhk.or.jp/bunken/research/kotoba/20160801_2.html
If you know the word 方, that it is /ho:/, and you know that it has a う in it when written out, how can you not know that う stands for making the o long? The only vowel is the long o.
Japanese kindergarten kids can recognize hiragana words with "おう", correctly identifying it as /o:/. By the time they learn the 方 kanji they would have seen it written in hiragana upmpteen times, like AよりBのほうがいい and whatnot.
When I hear /ho:/ in a certain context, "ほう(方)" immediately comes to mind, without noticing that what I heard was a long o. To me it's just the う sound. And if someone pointed to their face while saying /ho:/, I'd think it's the お sound as in "ほお(頬)".
Feel free to try listening yourself though:
頬, note that it has multiple pronunciations but we only care about hoo: https://forvo.com/word/%E9%A0%AC/#ja
方 https://forvo.com/word/%E6%96%B9%E3%80%80%EF%BC%88%E3%81%BB%...
In some cases though there is still a clear difference in pronunciation for most speakers, ex 塔 vs 遠
As a native Japanese speaker, this example is eye-opening. I hadn't even realized that the u in 方 is pronounced as /o:/ — I believe most Japanese people haven't either, despite unknowingly pronounce it that way.
Also, I have no idea how to Hepburn-romanize 方 vs 頬, 負う vs 王, and 塔 vs 遠. If I had to romanize, I would just write it as whatever the romaji input method understands correctly (hou/hoo, ou/ou, and tou/too, in this case).
The ~2000 is the official count taught in schools, but the actually "commonly" used number in literature is around ~3000. And you actually want more than that, because people's names can use weird kanji which are used nowhere else.
On the other hand, the vast majority of kanji are actually composed of a limited set of "subcharacters". For example, picking a completely random one:
徧 ⿰彳扁
The '徧' is composed of '彳' and '扁' arranged in a horizontal pattern. Unicode even has special characters (⿰,⿱,⿶, etc.) to describe these relationships.So this actually makes creating a CJK font somewhat easier, because you can do it semi-algorithmically. You don't have to manually draw however many thousand characters there are, but you draw those "subcharacters" and then compose them together.
https://josephg.com/blog/electron-is-flash-for-the-desktop/
* Non-native UI toolkit
* Massive waste of resources (CPU, RAM, Battery, Disk). Consumption of 500 MB RAM for idle is the norm.
* Slow.
* Often issues with autonomous, local operation.
* Security -> Browser Engine
It is always better to use a well-working application with your native UI-Toolkit: * Linux: Evolution, Geary, K-Mail, Claws, whatever TUI application you prefer. And Thunderbird.
* macOS: Apple Mail or Thunderbird.
* Windows: Please. Stop using Windows. You harm other people. Start with using Thunderbird :)
The “Electron” from Signal is one of the best applications using Electron. It is fat. Even in this case people resist. Signal isn’t supporting a stable API but:
https://github.com/boxdot/gurk-rsTUI :)
Electron is used, when a company wants to save on developer. All users pay with suffering from bad UI and their hardware resources. In this case it is something nobody asked for?
> Put the following line in your .gitattributes file: *.docx diff=word
> This tells Git that any file that matches this pattern (.docx) should use the “word” filter when you try to view a diff that contains changes. What is the “word” filter? You have to set it up [in .gitconfig].
https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute...