Bug: MarkdownFileInfo.editor field access throws during initialization about obsidian-api

[lishid]

I think it might be better for us to just not initialize the editor with plugins, and then reconfiguring the editor with plugins after - accessing properties that are not ready is always a bad thing to do. I could make this patch but it would still cause plugins to crash when attempting to use editor without checking for null - rather probably easier to ensure it always exists.

[pjeby]

Sure. In Outliner's case it's actually checking for a null on the next line, but the Obsidian API throws an error there since it's not initialized. (I've suggested they work around for now by accessing editMode?.editor directly or try/catch, but I'm not sure how much the author is around -- looks like their last activity predates even 1.5.0 alpha.)

Outliner in fact sits in a setTimeout loop waiting for the editor field to be initialized, so your approach would allow them to drop that in a future release as well. (I'm assuming you mean that MarkdownFileInfo.editor would lose the optionality, or at least that the value supplied in the state field would be always have a valid .editor at extension init.)

[lishid]

Sure. In Outliner's case it's actually checking for a null on the next line, but the Obsidian API throws an error there since it's not initialized.

Yeah I understand; I think another plugin ran into the same bug as well.

[lishid]

I will send you a build to test the fix in discord.

[pjeby]

Closing since this appears to be fixed in 1.5.9 beta and 1.5.10 alpha.