obsidian-latex-suite
obsidian-latex-suite copied to clipboard
[FEATURE/BUG?] Prevent auto-snippets from activating inside of commands
Description of the Problem
I love this plugin so much! Seriously, this is the biggest help when taking notes, and I can't appreciate it enough.
The only problem is that when attempting to manually write a command, the auto-replace feature can be more of a hassle than a help. For example, if I want to write \cdots
, the "dot
" snippet will activate without fail, ending up with \\dot{c}s
. As well, if I type \int
, the "int" snippet activates, ending up with "\\int \, dx
", which isn't valid.
It doesn't seem like any of the snippets are designed with this in mind, so this seems more like unintended behavior than a feature.
Description of the Solution
When translating the snippets to RegEx objects, prepend an exclusion for backslash characters that exist in the preceding continuous string of word characters. Something like (?!\b\\\w*)
, except competently written.
Additional
- Problem: This will require the user to enter a space between symbols and backwards autosnippets.
- Solution: This is already accounted for by the "GREEK|SYMBOL" autosnippet variants.
- Possible alternative: Add a new exclusion group that excludes commands.
- However, this would require manually adding a flag to every single snippet save for a few. Maybe add a flag to specifically allow a snippet to activate inside a command instead of the opposite?
Some command cannot be written by hands like \subset because set is replaced by { }, only workaround I have for some command it is to use a copy/past or alternative command that are not snipped.
I've tried to get around this by adding a w
option, but even if \
is removed from word delimers, the snippet still seems to be activated when there is a \
before the trigger word.
For example, \alpha
will still be translated into \\alpha
with option mwA
, even if \
is removed from word delimers.
By the way, I don't quite understand the sequence \/
in the default delimers, for /
seems to be escaped considering \n
is a valid character.
I also think that this is the biggest issue with this, otherwise awesome, plugin.