Regression: Linting in Live Preview does not update metadata block display since 1.21.1 about obsidian-linter HOT 15 CLOSED

Nice. I will plan to proceed with that change then barring any feedback from other devs that it could cause issues.

from obsidian-linter.

Hey @chrisgrieser . I am not 100% sure what the issue would be there. I do know that I recently had to rework how I handle live preview changes and YAML updates are one of those things that did have a prettty big issue going back all the way to October.

I just made an update that I think fixes the issue with the value not being added properly. However, there is definitely some kind of delay between the change happening and when the value displays in Live Preview.

Can you confirm whether this issue is just the display for Live Preview taking a little while to update or whether this an issue with the value not being added in Live Preview?

Can you confirm with the main.zip from #969 whether this is happening in that version? If it is, then I definitely need to look into what is causing the issue.

Thanks!

Edit: swapped question.

from obsidian-linter.

yeah, the issue still occurs with the main.zip from #969

from obsidian-linter.

yeah, the issue still occurs with the main.zip from #969

Gotcha. I will have to reach out to the devs in OMG. I am not familiar enough with Live Preview or reading mode to know what causes the display update. I am guessing it is not instantaneous because I do not use the Obsidjan API directly to uodate the frontmatter.

from obsidian-linter.

As an update, I reached out to other devs and it sounds like this is not something the Linter can handle directly. I will do some more research on this, but based on conversations, it sounds like the following is happening:

The YAML gets updated via the Linter. This is eventually registered as an updaye by obsidian which then has to update its caches and redisplay the YAML values.

It sounds like it is possible to get around this by using processFrontmatter, but that will mean formatting how the data is in the YAML frontmatter may not be possible. It would just allow setting the actual values of keys and maybe sorting.

TLDR
More research is needed, but so far it looks like this is how Obsidian works when you do not use its API to directly modify the YAML values. Hopefully I am just mistaken on this though.

from obsidian-linter.

@pjkaufman, thank you for looking into this, and sorry for also logging this same bug in another ticket.

However, the oddity for me is that Linter has happily upated the properties section since this feature of Obsidian was released. It only seems to have been since the latest Linter update. So I am not sure if it is a case of how Obsidian works.

from obsidian-linter.

@pjkaufman, thank you for looking into this, and sorry for also logging this same bug in another ticket.

However, the oddity for me is that Linter has happily upated the properties section since this feature of Obsidian was released. It only seems to have been since the latest Linter update. So I am not sure if it is a case of how Obsidian works.

I can check the last release and see if it updates things immediately, but I was noticing a delay prior to that personally. However I can definitely look into it some more.

from obsidian-linter.

Based on looking at the code, I am only seeing 2 changes to how save works in Obsidian:

1. Lint on active file change runs custom commands
2. Adding a call to the original save callback intl the Linter

I can check what happens if I remove these and see if it is snappy again. Either that or just remove updates and see when it starts working as it is said to have done before.

My guess is the original save callback, but I am not sure.

from obsidian-linter.

Upon further investigation, the issue seems to be located in the logic for running the initial save callback in the Linter. I am going to double check with those from the OMG discord and see what their take is on this, but if I run the Linter save after the original save callback logic, then the Linter works. However if run the original save callback after running the file lint, then the the Linter's changes do not show up immediately in Live Preview. I want to do the former way to make this work, but I will need to check with other devs to see if there is a reason not to do this.

from obsidian-linter.

@chrisgrieser , @robertnwinter , would either of you be willing to install the attached main.zip contents to see if it fixes your issue? It should reverse the order in which things happen in the save callback order (this should only affect ctrl+s or :w from my understanding).

main.zip

from obsidian-linter.

looks like it is fixed with that main.zip

from obsidian-linter.

The potential fix for this has been merged into master. It should go out with the next release and be on master in the meantime. Please let us know if there is an issue with either of those.

Also, thanks for letting me know about issues like these. They can be hard to catch especially since I do not use Live Preview and I am pretty sure I cannot catch this issue here even with an integration test since the source would be correct, but the UI would be wrong (it may be possible to catch, but it would be pretty annoying to setup a test case for testing the UI values).

from obsidian-linter.

Also, with all of the main.zip files I have been creating, I am wondering if I should start creating beta releases as a part of BRAT. Do you think that would be of useful for testing potential fixes for things like this @chrisgrieser (I am not sure if you use BRAT, but thought I would ask since it might make things easier on you and others who report issues)?

from obsidian-linter.

well, I do not use BRAT (anymore) since I simply do not have much time for beta-testing anymore. But in general, I think BRAT support would be useful for fixing issues such as this one more quickly, yeah. Also, it's quite easy to set up, so there is no real downside to just add BRAT support

from obsidian-linter.

@chrisgrieser , @robertnwinter , would either of you be willing to install the attached main.zip contents to see if it fixes your issue? It should reverse the order in which things happen in the save callback order (this should only affect ctrl+s or :w from my understanding).

main.zip

@pjkaufman, sorry for not being able to test your zip, long day at work and only just getting to my leisure time. I see Chris has already tested this and you have a fix ready to roll. Glad you were able to solve for this as Linter is an essential part of my workflow.

Thank you for your efforts in delivering a great plugin and being so responsive to bug fixes.

from obsidian-linter.