Okay so I've spent a bit of time doing some fairly extensive testing, and it's mostly working, with the following caveats (trying to be thorough in documenting everything I've tried so far):

The biggest issue by far is related to one mentioned at https://github.com/tslmy/latex-input-iOS-macOS: "macOS seems to have its own logic handling upper cases in text substitution, which cause \alpha and \Alpha to both yield Α." It turns out to be much, much more complicated and confusing than that, and has honestly been doing my head in a bit...

At first, I found that it does actually treat \alpha and \Alpha as different sequences for me, correctly (and consistently) giving α and Α, on both macOS and iOS. So I thought, that's good, they must've made a change under the hood sometime after 2017, maybe everything just works now! However, when I tried typing \mathfrakl and \mathscrl in a test message ℍϵ𝔏𝐿☉, I got \mathfrakL and \mathscrL instead.

I thought maybe it preferred the capital version because that one came first in whatever lexicographic order the shortcuts are processed in, where uppercase comes before lowercase (it's actually the other way for how they're displayed in the replacements list, but that turns out to be a moot point). Nope: \barm and \barM both produce m̅. I then thought, surely it's the order they're listed in and thus imported from the plist then? Sure enough, \barm came before \barM while \mathfrakL came before \mathfrakl. (This hypothesis turns out to be incorrect too, as we'll see.)

I thought ok, if only recognizes when the capital is the first letter in the sequence (based on \alpha and \Alpha), we could use that to for example redefine \mathfrakL and \barM as \Mathfrakl and \Barm Unfortunately not so: \Beta and \beta both gave Β, immediately dashing my hopes.

At this point, I realized I needed to do some systematic testing. I typed out each of the following series of letters (manually, because copy-pasting a prefix like \mathfrak and typing the remaining letter doesn't trigger a replacement), repeating a few times to check consistency (i.e. that it's not choosing upper vs lower randomly), and got these outputs:

\Alpha to \Omega: Α Β Γ Δ Ε Ζ Η Θ Ι Κ Λ Μ Ν Ξ Ο Π Ρ Σ Τ Υ Φ Χ Ψ Ω -- Good, as expected because Greek capitals all come before Greek lowercase

\alpha to \omega: α Β Γ Δ ϵ ε ζ Η Θ ι Κ Λ μ Ν ξ ο π Ρ Σ ς τ υ Φ φ χ Ψ ω -- WTF?? I fail to see any rhyme or reason to this, it's not the letter length, for example, or even by common usage (hardcoded by some nerdy Apple engineer, idk I was clutching at straws), because lowercase \theta and \lambda are more common by far

\barA to \barZ AND \bara to \barz both: A̅ B̅ C̅ D̅ E̅ F̅ G̅ H̅ I̅ J̅ k̅ l̅ m̅ n̅ o̅ p̅ q̅ r̅ s̅ t̅ u̅ v̅ w̅ x̅ y̅ z̅ -- Started losing it at this point. I double checked that ALL the lowercase \bar come before the uppercase \bar in the plist (and they go \bara \barA \barb \barB etc. in the replacements list pane in macOS/iOS Settings), so we can basically throw out both those theories

\mathfrakA to \mathfrakZ AND \mathfaka to \mathfrakz both: 𝔄 𝔟 ℭ 𝔡 𝔈 𝔉 𝔤 ℌ ℑ 𝔧 𝔎 𝔏 𝔐 𝔑 𝔬 𝔓 𝔔 𝔯 𝔖 𝔗 𝔲 𝔙 𝔚 𝔛 𝔜 𝔷 -- Similar random distribution as Greek lower, obviously not correlated tho

\Bara to \Barz: A̅ B̅ C̅ D̅ E̅ F̅ G̅ H̅ I̅ J̅ K̅ L̅ M̅ N̅ O̅ P̅ Q̅ R̅ S̅ T̅ U̅ V̅ W̅ X̅ Y̅ Z̅ -- Hmm a potentially promising workaround? To be clear, I didn't manually add any of these shortcuts, this was macOS's auto capitalization at work

\Mathfraka to \Mathfrakz: 𝔄 𝔟 ℭ 𝔡 𝔈 𝔉 𝔤 ℌ ℑ 𝔧 𝔎 𝔏 𝔐 𝔑 𝔬 𝔓 𝔔 𝔯 𝔖 𝔗 𝔲 𝔙 𝔚 𝔛 𝔜 𝔷 -- My disappointment is immeasurable

The last two are based on the other repo author's idea: "One solution is to manually remove the uppercase versions from the listbox, as macOS automatically converts the replacement to uppercase when the first letter you type is capitalized." Removing all the \barA \barB, which I didn't do, would be necessary to allow \bara \barb to work. However, even if it DID work for \mathfrak like it did for \bar, I realized it could still only ever be a partial solution, as we have things like \rightarrow and \Rightarrow that don't have an lower to uppercase relationship (probably true for \mathfraka and \mathfrakA too, as far as macOS knows. Tho I wonder if the relationship is defined in Unicode?)

Sub-bug: dictionary.txt and thus dictionary.plist actually defines each of those twice: \rightarrow on lines 250 and 252 (identical, both →), and \Rightarrow on lines 384 and 547 (conflicting, ⇒ vs ⟹, I believe ⟹ should be assigned to \implies instead). I thought one would simply get overwritten, but no, both appear in the list:
I shouldn't be surprised it allows a one-to-many mapping tho, as I set a seemingly pointless omw → omw replacement just to override the omw → On my way! replacement that gets added back with each iOS update no matter how many times you delete it... but I digress. I also caught \phi as both φ and ϕ; the latter should be reassigned to \varphi (currently also φ). There are probably a few more duplicates like this, conflicting or not, that probably just slipped through the manual code review. Maybe create an automated script to check for such duplicates/conflicts? ~~I'll open a new issue about this~~ I see there is one already)

The last thing I tried was deleting the capital version of a shortcut (I arbitrarily I chose \mathscrK, its symbol is easy to visually distinguish from \mathscrk), and manually adding \Mathscrk to replace it, JUST in case the first letter theory still works (Greek lowercase letters should tell us it doesn't, but better check). Originally, both \mathscrk and \mathscrK produced 𝒦. After deleting \mathscrK, \mathscrk produced 𝓀, as expected, but so did \Mathscrk (macOS didn't auto-capitalize 𝓀 into 𝒦, as other repo author would've hoped). After manually adding \Mathscrk for 𝒦, we're back to both \mathscrk and \mathscrK producing 𝒦. I then even deleted and added back \mathscrk, in case it's recency of import/modification that determines priority, but nope, both still give 𝒦.

Oh I also tried turning off the macOS global auto-capitalization switch in keyboard settings but that didn't seem to affect anything.

(Minor) Text Replacement doesn't work in all apps on macOS, most notably for me Firefox, which I'm currently using (incidentally, that did make this comment infinitely easier to type). https://discussions.apple.com/thread/251199387 I already knew about that, but others may not, so I point it out in case they think the plist import didn't work if testing on an unsupported app (I myself forget briefly, and thought the same). It works everywhere shortcuts normally work on macOS (including all built-in apps), and potentially universally in all apps on iOS (don't sure though, just based on my experience).

At this point, I'm a bit stumped, and short of talking to an Apple engineer who has access to the code behind how text replacements are done, I'm not sure I can figure out either why the capitalization shenanigans are happening, or how to fix it. If other folks can try importing the plist to test and try to replicate the behavior I saw, that would be helpful.

I'm almost positive this issue is precisely why in https://github.com/clarkgrubb/latex-input: "The Mac LaTeX input source is case insensitive. In LaTeX, \Delta is used for Δ and \delta is used for δ, but the Mac LaTeX input source will nevertheless insist that you disambiguate. It does this with a pop-up window. Use the arrow keys to select the correct symbol and press RETURN." (The pop-up is exactly like typing Chinese/Japanese, which I'm used to.) That repo was also last updated in 2017, and it took some fiddling to install on the latest macOS, which I already did just last week. So I'm really only involving my Mac because macOS is the only way to import a list to sync to iOS.

But taking a step back for a second, how often am I (or is anyone for that matter) going to use \mathscrk and \mathfrakl? As for the Greek and bar letters (and probably some others macOS recognizes upper/lower pairs for), the suggested workaround of deleting the upper shortcut and typing e.g. \Beta and \Barm and using auto-capitalization, in the few situations it's needed, works perfectly fine, and I've already done so. And with LaTeX-input, I don't even need this on my Mac, just iOS.

I can understand if you decide not to officially support macOS/iOS in light of my findings, but I still think it could be useful for many people (I'll certainly be using it with said modifications.) Even though LaTeX-input exists, my earlier points about it being not maintained or updated, and less popular, still remain, not to mention the advantages/featurse mentioned in the other plist repo, e.g. not needing to switch input sources. If you do decide to go forward with merging the PR, I'd be happy to help add documentation/known issues, and/or do more testing.

Uh oh!

Any way to import this for iOS? #4

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions