SYSTEM INFO:
Obsidian version: v1.5.12
Installer version: v1.4.16
Operating system: Darwin Kernel Version 22.6.0: Mon Feb 19 19:48:53 PST 2024; root:xnu-8796.141.3.704.6~1/RELEASE_X86_64 22.6.0
Login status: not logged in
Insider build toggle: off
Live preview: on
Additional information
Please see the previous post for gifs of the behaviour.
Please fix this. It’s been over a year since it was first brought to your attention (on the discord, then again on the forum a little less than a year ago), and I am not the only person this affects. Any Mac user who uses text replacements will be affected by this. Turning off text replacements for the entire OS is not an option since I, like many, require it for accessibility.
If the issue cannot be fixed, please implement an app-level text replacement option to turn off all text replacements within Obsidian only. This happens with no other app.
I really hope it will be possible to add the “turn off text replacements” option. At this point, I would think it’s the best option in terms of possible implementation.
Moving to Help because this isn’t a bug, and as mentioned in the prior thread you can work around it by disabling auto pairing of brackets in Obsidian. Also, MacOS has keyboard shortcuts for at least some of the things you’re using text expansion for. https://www.makeuseof.com/mac-copyright-symbol/
If you like, you can post a feature request for the setting that you want.
In the previous thread, it was discussed that turning off the auto pairing of brackets does not fix this situation. There are other shortcuts I use for accessibility issues that are not covered by MacOS’s keyboard shortcuts, nor do I think it makes sense that should I have to turn them off system wide for one application.
OK, that should have been mentioned in the bug report itself.
I don’t have time to experiment myself but I’ll move this back to bugs for now.
This is a long shot, but as a workaround perhaps the Text Snippets plugin might in some configuration interfere with the built-in text replacement enough to make it behave as expected.
Please note in the first example of me writing the word exact a popup appears (in the lower right) of what the text replacement would be. I then hit escape and it closes that popup and permits me to write the rest of the word.
The second line is just me typing the keyword to activate the replacement: exa
The following lines are me attempting to type exact the way a person normally would, one letter at a time without stopping in the middle to press escape. This is the undesired behavior, and not standard behavior for MacOS.
Here is a second video in which I demonstrate the expected behavior.
The first line I type the keyword, hit space, and the text replacement fills in.
The second line I type the keyword, hit escape, and the text replacement prompt disappears.
The following lines I type the word normally. This is the part that matters: continuing to type another word that has a keyword as part of it (like exact contains the keyword exa) does not activate the text replacement.
I also wanted to apologize: I realize that this bug report did not include the full set of issues this presents: not just with the (c) type keywords or those like it, but any keyword made up of letters commonly found in other words. I’m sorry for the confusion.
Ok, this has nothing to do with brackets and links.
I am not familiar with MacOSX built in text replacement, but not using a magic prefix (like :exa) and using space to accept the substitution seems unusual and a recipe for creating problems.
Also it’s not clear to me why in the first two cases you get the little suggestion window but you don’t in the latter cases. Or do you need to explicitly pause after you type the keyword to get the suggestion trigger?
That being said, kindly open chrome (later you can try with safari) and go here and see if it happens. You can even try while composing an email in Gmail in Chrome.
To answer your questions, I understand there might be a best practice for designing keywords, but to change my entire library of keywords at this point is infeasible for me. As for the space to accept the substitution, that is not a choice I’ve made but a standard set by the OS.
As for the suggestion box appearing or not, if in the latter example I do not wait at all but simply type exa followed immediately by a space, the suggestion box does not appear but the replacement occurs. If I continue to type a word past the exa, it does not effect the replacement.
Is Chrome absolutely necessary? I don’t have chrome on this machine nor access to a machine that already has it, and would prefer to not have to install it to troubleshoot, but will if I need to. I will mention that other Electron apps are hit and miss with the ability to control whether text replacements are utilized or not, which I do believe is the most likely solution to implement. The only other Electron app I know of that explicitly permits turning it off or on is Simplenote:
Yes, you need to try with Chrome, because Obsidian is based on electron/chrome.
Also, in troubleshooting steps, you are asked to download and reinstall Obsidian, please do it.
Ah, I see. I knew it was Electron in some form, but it seems the Mac app is either Electron or native depending on how it’s acquired. The one I had was not Electron; after downloading the Electron version, I found this:
Using the site you linked, within the text box the text replacement does not occur at all, even following the usual MacOS standard (keyword, space). The popup with the replacement did not appear. I tested this on Safari as well (where the text replacements do work) and it did not work either. I do not know why this is.
I just happened into a chance to test this, and in my experience the issue is limited and can be cured with a setting change.
I often use “q” as my prefix because it’s uncommon, and easier to type on mobile than punctuation. So I setup the trigger “quar” for an upward-pointing arrow (↑), then realized that I will hit this bug when I type “quarter”. That didn’t happen, but I was on iPad so I moved to Mac (14.4.1), and (after making sure the replacement setting had synced) it didn’t happen there either. It did happen if I typed punctuation after the trigger, like “quar.” — but I think that’s expected behavior.
@paris Your debug info looks incomplete. Did you test in Restricted Mode (or the Sandbox Vault)? This is mine:
SYSTEM INFO:
Obsidian version: v1.5.12
Installer version: v1.5.8
Operating system: Darwin Kernel Version 23.4.0: Fri Mar 15 00:12:41 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T8103 23.4.0
Login status: logged in
Catalyst license: none
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: off
Plugins installed: 0
Plugins enabled: 0
RECOMMENDATIONS:
none
Hi, Cawlin, yes, all my tests were done in a Sandbox vault; there are gifs above of the behavior in the Sandbox. The example keystroke that I tested with (a brand new one, in case it was something with the age of my text replacement triggers) was exa which autocorrects to example text that breaks. I have now tested this on two Macs, and it continues to happen.
Here’s the more complete debug info.
SYSTEM INFO:
Obsidian version: v1.5.12
Installer version: v1.5.12
Operating system: Darwin Kernel Version 22.6.0: Mon Apr 22 20:54:28 PDT 2024; root:xnu-8796.141.3.705.2~1/RELEASE_X86_64 22.6.0
Login status: not logged in
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on
The way text replacement is done is something we have no control over, we are passively subject to it. This is something that should be fixed upstream by either Electron/Chrome or MacOS.
