FR: Custom editors

[MrMugame]

Custom editors (which would need a good name, maybe processor or manipulator or smth) are editors provided by a plug ,similar to a codeWidget, for specific file types. - Note that the file type is determined by the extension, not by some MIME type. This has the reason that sometimes formats aren’t distinguishable (many text based formats for example). This also makes it easy for the user to know which editor is going to be used with a file. - This would look something like this:

name: excalidraw
functions:
  excalidrawEditor:
    path: ./excalidraw.ts:editor
    editor: [".ecalidraw", ".ecldrw"]

The called method would then look something like this, again similar to codeWidget:

export async function editor(): Promise<{ html: string; script: string }> {
  // return excalidraw editor html/script
}

This should just return a barebones editor without a file yet[^1]. The file will be provided to the iframe via messages, which will then trigger a custom event on the iframe window. The specific events here will be:

• file_open: This event is dispatched when a file is opened, meaning it is called once the editor loads up and can also then be called to reopen a file, this means the editor iframe doesn’t have to be regenerated when switching between different files of the same type.
• file_change: This event is dispatched when the current file is changed. This will just pass the new changed file for now, maybe later we could update the files more granularly although live collaboration is not really a goal of silverbullet anyways
• editor_close: This event is dispatched when the editor is closed to give it time to save. The iframe internals will when answer back when finished (all event handlers ran) and the iframe will then be deleted. Depending on performance we could probably parallelize closing and opening.

Saving is handled via a global function either as an api call or a custom message. All this will integrate into the silverbullet experience pretty seamlessly. The attachment files for which an editor (provided by a plug) exists could just be added to the page navigator with some visual mark (or a custom navigator). [^2] This would obviously also need the features you already proposed, mainly attachment renaming and attachment deletion. There won’t be attachment creation, this will be handled by the plugs themselves using commands and syscalls (writeAttachment) if needed.

Advantages:

• Multiple editors/panels should be easy to implement
• Support for different markup formats (e.g. Asciidoc, Org)
• Editors for special formats like stl, pdf, jpg.
• Custom markdown editor using xterm and vim or monaco for the crazy will be possible
• Experience will be more contained and consistent as e.g. all pdfs will open in the specified pdf editor on your laptop, pc or anywhere else and you will also not have to use browser shortcuts to switch back to you silverbullet tab as you will always stay in silverbullet

Maybe I'm overlooking something really important here, maybe this idea is limited by performance issues, but I think this could be really powerful, especially for ''hackability"

[^1]: A performance issue here could be the object returned by the editor function as this can grow quite large. There could be something like a getAssetPath(...) function, which gets a path to an asset, which is provided by the server. This way all the libraries and stuff could be in assets which are just fetched from the server inside the iframe with normal <script src="..."/> tags. I don’t want to do any premature optimization tho.

[^2]: At some point this visual mark may also exist for markdown files and the markdown editor could be implemented using the api, I just proposed. This would make the editor replaceable, which I think would be pretty cool in terms of “hackability”. We could then also easily provide the components via a library to build other markup editors.

[zefhemel]

This sounds very cool :)