[Feature] Generic User Configurable Code Fence Interpreter #5871

CameronKramr · 2023-10-16T17:17:25Z

Idea:

Allow the code-fence language selector to feed the content inside a code-fence to a user-configurable interpreter/processor. The user interface should be similar to how mermaid is currently implemented, but configurable with a locked-down config file.

Example Markdown:

``` LANG
example input to generic processor
```

Search/resolution order:

flowchart TD
UserConfigs-->DevConfigs-->SyntaxHighlighter

This way certain trusted configurations could be pre-packaged with Typora and overridden/added to by users. Pre-packaged interpreters could be things like Mermaid, or any one of the many requests on #1138.

Config Example:

LANG={
     <!--executable location / text-->
    Exec=/path/to/LANG/processor
    <!-- options to use while executing the executable-->
    options= Options to execute the custom processor with
    <!--text to prepend the input stream. Can be used for setting themes in target executable for example-->
    pre=Text to prepend to input
    <!--Analog to the intro/pre string in case that's needed-->
    post= Text to post-pend to input
    <!--Tells Typora how to use the output product-->
   outputType= img
    <!--Tells typora to wait for the output-->
    blocking=True
}

Different output types could improve functionality. For example, if there was a stream interface for video, a user could procedurally generate/collect video that could be displayed in Typora. Could also specify a location for output products / execution along with many other variables.

Example Execution:

/path/to/LANG/processor Options to execute the custom processor with "Text to prepend to input" + "example input to generic processor" + "Text to post-pend to input" -o ./temp/some-temp-output-file-collection-location/output.jpg

Example Rendering:

After executing the custom processor, the output.jpg file would then be rendered into the final document as an image in this example.

![LANG_OUTPUT](./temp/some-temp-output-file-collection-location/output.jpg)

If the output product was some additional markdown, that could be rendered as well (with care to prevent deep recursion).

Justification:

Gives users black-box functionality that Typora staff don't need to implement.
Provides automatic support for text-based graphing tools such as mermaid (latest version), Markvis, and other home-brewed programs.
Reduces the expectation on Typora team to integrate the most up-to-date features of different text->graphics packages.
Invisible to users who don't care/use feature.
Maintains minimalism and impact since code-fence-based rendering already exists in a "fenced-off" version like how Mermaid currently is integrated.
This is not a "plug-ins plz" request since the renderer does not operate on the document, and the renderer has no knowledge of the document other than the text the user provides in the code fences. This means that the minimal implementation doesn't need an extensive (expensive) API to be useful.
This is different from HTML scripts since the syntax is simpler and more generic.
This feature would not be incompatible with vanilla markdown.
Many features required to implement appear to exist in some form.
This feature would provide a generic frame-work for implementing more baked in-features and help with development

Security Concerns:

Giving markdown files the ability to execute programs by rendering them has security implications similar to macros in office programs. One additional security concern would be if an underlying executable had some exploitable bug. I think that guarding the configuration file and letting users know that the feature is potentially dangerous should encompass most concerns. Security is not my expertise.

Ideas for Addressing Security:

Write protect configuration files with elevated permission.
white-list file list -- Default behavior is to not run custom code-fence renderers
Default feature to disabled
Warning text before enabling and adding files to white-list

Closing:

I've really enjoyed using Typora because it is minimalistic, fast, and intuitive, but it is held back by a lack of user definable extensions. Using functions defined by code-fences that don't automatically know how to execute (since the executable configuration context is locked-down and local) would be a great compromise between a complete extension environment and what we have right now: nothing at all. This feature would provide a unique way to interact with markdown that other markdown editors don't offer, and since this feature leverages code-fences, it would not make markdown files naturally incompatible with vanilla markdown. Furthermore, it would relieve the burden on the Typora team to update and integrate third-party libraries. For example, Mermaid is currently 2 updates behind in Typora, and #1138 has a long list of awaiting integrations going back 5 years. As far as security is concerned, there is a limit to how much anyone can protect people from themselves. Naturally disabling and warning users who enable/whitelist files is probably as secure as a feature like this could be, and people susceptible to an attack by this vector, are also susceptible by many other vectors ("Please download, enable, and run my Microsoft macro..."). Lastly, this feature is not explicitly out of line with the vision of Typora since code-fence based rendering is how current offerings like Mermaid are interfaced with.

The text was updated successfully, but these errors were encountered:

BarkenBark · 2023-11-03T08:00:58Z

Very nice, would love to see this!

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[Feature] Generic User Configurable Code Fence Interpreter #5871

[Feature] Generic User Configurable Code Fence Interpreter #5871

Uh oh!

[Feature] Generic User Configurable Code Fence Interpreter #5871

[Feature] Generic User Configurable Code Fence Interpreter #5871

Comments

Idea:

Example Markdown:

Config Example:

Example Execution:

Example Rendering:

Justification:

Security Concerns:

Ideas for Addressing Security:

Closing:

Uh oh!