Support other file-types/file-extensions

[suliveevil]

When I try to open an org file, shellcommands fails:

/opt/homebrew/bin/emacs +{{caret_position}} {{file_path:absolute}}

About Obsidian
Version 1.0.0 (Installer 1.0.0)

MacBookAir10,1
Operating System: macOS 13.0 (22A5373b)

[suliveevil]

file:

https://github.com/redguardtoo/mastering-emacs-in-one-year-guide/blob/master/developer-guide-en.org

Obsidian plugin:

https://github.com/ryanpcmcquen/obsidian-org-mode

[Taitava]

Good catch!

I tried the plugin you mentioned and the file you linked. At a quick glance it looks like the file is opening up in a quite normal editor, so I guess implementing support for these kind of files should be possible. But I can only confirm it when I actually start working on this. I need to check what kind of editor class it is, is it something trivial that is easy to implement, or is it specific to the Obsidian Org Mode plugin. Will see.

I'll move this discussion to Ideas. 🙂

I don't know yet when I have time for working on this.

TODO:

• Research/implement support for other file types.
• Offtopic: Please raise an issue in GitHub: I need to change the error message to say create discussion instead of issue as that's the current workflow in this repository. 🙂 You created a discussion correctly, I just want to ensure others will do the same, too. 🙂

[Taitava]

Obstacles from Obsidian API

I tried to implement this now, but did not get far, as I couldn't get it working by following Obsidian API.

Current situation

Currently, SC expects to encounter a MarkdownView (a subclass of TextFileView) from which it can get an active Editor instance, which provides for example caret and text selection related details. What happens with Org Mode is that the current view is - obviously - not a MarkdownView, but an OrgView which is a subclass of TextFileView. Here is the class hierarchy as a list:

• EditableFileView
  • TextFileView
    • MarkdownView
    • OrgView
    • Other community plugins can provide even more...

What I tried

I started to change SC in a way that it would expect a TextFileView view instead of a more specific MarkdownView view. This would have made it theoretically compatible with both MarkdownView and OrgView. But, as I further researched TextFileView, I noticed that it doesn't contain a property named editor, which is required for SC to be able to get an Editor instance from the view. editor as a property is only available on MarkdownView.

What could be tried

As Obsidian API for TextFileView does not contain an editor property, there is no public API for getting an editor instance for anything else than Markdown files (well, I don't know about images, PDF's, audio/video files, or canvases). So, officially: can't do anything.

But if private API access is tolerated (SC does it in some cases, I have to admit), there might be a way. OrgView uses a property named codeMirror which is an instance of CodeMirror.Editor:

https://github.com/ryanpcmcquen/obsidian-org-mode/blob/4a9886d0c345328886f4a85a75ec25b12b1e658c/src/main.ts#L25-L28

I could make SC check if a view - be it whatever subclass of TextFileView - happens to contain obviously named editor properties (editor, codeMirror just to start with two) it could then try to use that property to get an editor instance.

There's still one small thing: MarkdownView.editor is an instance of Editor, which is - if I've understood correctly - a wrapper interface that encapsulates a CodeMirror editor. Then again, OrgView.codeMirror is a CodeMirror editor directly. SC is currently designed to work with the wrapper interface provided by Obsidian. I need to ensure compatibility with a direct CodeMirror editor interface, too.

I need to emphasize that this kind of private API access is unstable. Whatever update to the Org Mode plugin might change the OrgView.codeMirror property name, which would break SC's ability to access the editor without any prior notice. In other words, support could probably be implemented, but there would be no quarantee that it would work forever. I think it might still be viable to do.

Maybe this was a bit complicated story, but at least it cleared my thoughts on this feature.

[Taitava]

While speaking about the Org Mode plugin, it came to my mind to actually invite its author to this discussion, too. 👍

Hi @ryanpcmcquen! 🙂

I brought you to this discussion as this feature request towards my plugin affects your plugin, too. I'm not certain if the Shell commands plugin is familiar to you, but shortly: it allows executing system commands and passing data (e.g. currently selected text, or caret position) from the currently active editor view (which in case of *.org files is a view provided by your plugin) to command arguments.

I just wanted to ask what do you think about the possible private API access discussed in the What could be tried section above? 🙂 I assume there's no changes required on your plugins' side. I have to admit that I haven't yet tried to read the OrgView.codeMirror property, but I assume it would work.

[ryanpcmcquen]

I'm all for it!

[suliveevil]

Sorry for the late reply.

Obsidian's backlink is based on file/title while org-roam is based on the id (UUIDv4) of file/title, so I gave up to find ways to make Emacs(org-mode org-roam) and Obsidian work together.

After trying Obsidian-org-mode obsidian.el md-roam.el, I have moved/rewritten/converted 1/10 of Obsidian files (20000+) to org-roam nodes.

[Taitava]

Ok, if I understood correctly, you are migrating away from Obsidian. Perhaps this is a goodbye then, but nonetheless, this feature is worth implementing at some point. And in case you later happen to use Obsidian for something, I hope this thing is ready by then. 👋🙂

[suliveevil]

It's a long way to say goodbye to Obsidian.

I'm thinking about how to make each app recognize other app's backlinks, but it is clearly out of my capability.

Obsidian should not limit itself to MD file extension, this should be done by the official.