obsidian-latex-suite icon indicating copy to clipboard operation
obsidian-latex-suite copied to clipboard

Nested Brackets in the New Obsidian Update

Open H1410101 opened this issue 1 year ago • 6 comments

(I first explain my setup, which should allow replication of the issue as well as convey my motive.)

I have this snippet: {trigger: "()", replacement: "($0) $1", options: ""},.

What this allowed me to do previously was write "()", and press tab to be sent in the middle of the brackets. I could then write whatever I wanted, including brackets; this would behave as expected (I use | to denote cursor position): ()| -> press tab -> (|) -> write brackets -> (()|) -> press tab -> ((|)) -> press tab -> (() |) -> press tab -> (() ) |

however in the new Obsidian update, this workflow cannot be replicated. The following happens: ()| -> press tab -> (|) -> write brackets -> (() |

Note that this is with the bracket auto-pairing settings turned off in both cases. This unfortunately breaks my old workflow with parentheses. While there are workarounds, this still feels like a bug, so I am reporting it.

I would guess that whatever Latex Suite is using to move cursors is also marking the new bracket as an auto-paired bracket, although I'm not sure why the space makes it in to the replacement even without pressing tab.

Love Latex Suite, love the power it gives me, and hope that this is eventually fixed. Cheers!

H1410101 avatar Oct 16 '22 12:10 H1410101

This plugin comes with a snippet which will automatically turn ( into () and put your cursor inside it in math mode . That is, (->automatically->(|)->tab->()|. It also works when nested. If you want this also in text mode, simply delete the m option in the corresponding snippet.

Hope this will solve your issue.

proItheus avatar Oct 16 '22 13:10 proItheus

Yes, thanks for your help, @proItheus! Let us know whether this solves your issue.

artisticat1 avatar Oct 16 '22 14:10 artisticat1

It's not quite what I was trying to convey, because I was reporting deviation compared to pre-update behaviour, and I'm not sure if this is technically according to specification (this effectively automatic replacement happens even with no A option).

I wasn't really looking for a workaround, but thanks anyway! Your proposed workaround definitely works.

Regardless, I do believe it is a bug; though since it seems to be a relatively niche one with potential workarounds, I suppose it is not a big deal. I'll keep the issue open, but feel free to close it if it's not worth fixing, or if it's intended behaviour.

(P.S. For a bit more personal justification, I simply have a habit of writing full parentheses before filling its contents. It seems awkward to write just the ( without its sibling, and is a habit that doesn't adapt well to use outside of Obsidian and Latex Suite)

H1410101 avatar Oct 16 '22 16:10 H1410101

Ah, I see! This is indeed unintended behaviour. I believe the bug was introduced when I implemented #46. I'll try fixing it for the next release.

artisticat1 avatar Oct 16 '22 18:10 artisticat1

On second thought, this is actually intended behaviour – typing a ) is an alternative way of moving outside brackets (see #46). So, by moving your cursor outside the original pair of brackets, the plugin is behaving exactly as it should.

If this issue is important to you, I can consider adding an option to turn off said feature.

artisticat1 avatar Oct 16 '22 18:10 artisticat1

It seems I had forgotten to update the plugin for at least a month, whoops.

I see. Automatic tabout on closing parentheses does seem like a good feature to have. That being said, an option to disable it would be lovely - if it isn't too troublesome (which I really hope it isn't). I think the bug is with )) specifically, and this is most relevant in code and math instead of actual writing. Still, that seems like fixing something really niche with no overall improvement, so allow me to make some suggestions that are more time consuming to implement. :P

  1. An option in the plugin settings menu to enable or disable tabout with closing parentheses (or other bracket variant).
  2. A variant of the previous suggestion, a textbox in the plugin settings menu to trigger snippet tabout when writing certain characters. (allowing users to customize which characters it works for)
  3. Since I do see some potential in the feature, perhaps you could make it customizable by users? Allow us to write nested snippets that run only in the environment of other snippets, as a flag/option. Potentially even have a tag system for such "fake" environments, where snippets can createEnv and runInEnv. This would turn option 1 into a new line in the default snippet setup. (In the featureset I'm envisioning, the fake environment created by a snippet ends when cursor repositions of the form $n stop applying for that snippet)
  4. An option to disable the parenthesis tabout for specific snippets.
  5. Automatically disabling or deferring parenthesis tabout on writing opening parentheses.

Same disclaimer applies - I'm aware this is a very niche request, and has workarounds. I do think suggestion 3 is a powerful tool to have, and could be used to allow snippets to generalize the concept of matrix shortcuts. Still, might not be worth implementing, and not having 3 wouldn't change anything for my current setup. The most natural fix to combat the specific unintended consequence of not handing )) properly is suggestion 5. In any case, same as before, feel free to close.

Cheers!

H1410101 avatar Oct 17 '22 03:10 H1410101

So I'm not sure if this is helpful or not, but a quick update:

I have found a different workaround for my specific use case, which is the snippet: {trigger: "()", replacement: "($1)$0 $2", options: "A"} Which amusingly works better than my previous snippet back while it was still functional.

From this I assume that latex suite internally tracks which parentheses are to the right of $0.

Regardless, my current use case has been returned to its former functionality, with improvements, so I'm inclined to close this issue. Let me know if you think that the previous suggestions/"feature requests" are worth looking into, otherwise I'll just close this issue sometime in the next few days.

Thanks for your work!

H1410101 avatar Nov 03 '22 09:11 H1410101

Glad you found a solution to your problem! It seems your feature requests aren't of high priority for other users at the moment, so I'll go ahead and close this issue (though we can always revisit it in future).

artisticat1 avatar Nov 05 '22 11:11 artisticat1