Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a standard file extension #1503

Open
rxlecky opened this issue Nov 19, 2024 · 0 comments
Open

Add a standard file extension #1503

rxlecky opened this issue Nov 19, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@rxlecky
Copy link

rxlecky commented Nov 19, 2024

Is your feature request related to a problem? Please describe.
When using templates that define properties or links whose values are results of templater code expansion - a very common scenario - Obsidian has no way of distinguishing the used templater code from regular values. This makes the templater code clutter many different places in Obsidian, such as file link and property value suggestions, searches, tags, graph, etc. This is makes using those features more distracting, and their results less useful and relevant.

Describe the solution you'd like
Define a standard file extension for templater scripts, let's say .tp and add an option in plugin settings to register it with Obsidian to allow opening and editing such files directly in Obsidian. Note that this wouldn't stop the templates with .md from working, it would only add the option to use an alternative extension. Also, even though the custom file extension can be rergistered to open, edit and render in Obsidian just like any other markdown file, only files with .md extension are actually parsed by Obsidian for metadata caching, resolving the issue, while giving the exact same editing experience as any other standard markdown file.

Describe alternatives you've considered
There are multiple alternatives, none of which are ideal:

  1. Obfuscate markdown syntax:
    While this achieves the goal of preventing Obsidian from parsing templater code as markdown, it makes templates look more cluttered, more difficult to read, write and parse visually. It also disables all the (potentially) useful visual aids that the Obsidian reading and preview modes offer, such as rendering frontmatter as properties to verify correctness, and rendering markdown elements. All in all, this makes the process of working with templater scripts worse in pretty much all aspects, in exchange for better experience when working with your regular notes. This may still be worth it, since you will likely be working with templates much less then the regular notes but it's still not a great tradeoff to be making.

  2. Use a user-defined custom file extension:
    This would also resolve the issue but it has its own issues. Since Obsidian by default can only open .md files in its markdown view, this would require working with templater scripts in a separate editor. This adds a lot of friction to working with and iterating on templater scripts as it would require constant context switching. The benefits of the Obsidian markdown editor are also lost, just like in the previous case. Also, using a non-standard extension has its own downsides.

  3. Mark templates as excluded in Obsidian settings:
    Obsidian has a native setting to mark certain files and folders as excluded. However, marking templates only partially sovles the issue. It does hide the template notes from search results, graph view and unlinked mentions, but they still show up in quick switcher - albeit with a reduced priority - and fully show up in link and property value suggestions, as well as in tags pane.

  4. Use a separate plugin to register a user-defined custom file extension:
    There are community plugins that allow registering custom extensions with Obsidian and this solution pretty much ticks all the boxes. The only downsides are having to define and use a custom extension and having to use a separate plugin for such a simple functionality.

Additional context
On top of preventing Obsidian from parsing the templates, a standard file extension has other smaller benefits:

  • Templater outgrew the markdown file extension: Albeit originally used mainly for full file templates, mostly consisting of valid markdown syntax, templater is much more powerful now and supports a much wider range of use cases. Many templater templates nowadays consist of mostly javascript logic, with very little markdown peppered inbetween. In those cases, using .md is a bit misleading and frankly, just feels wrong, especially since the templater scripts can result in invalid markdown and/or embedded YAML syntax.
  • Custom file extension allows easy differentiation between notes and templates:
    This is helpful in multiple ways:
    • Allows recognition of templater files on first glance in file explorer
    • Makes it easy to include/exclude templater files programatically - for example, it would allow templater to automatically recognise templates without having to specify a templates folder, it would allow styling of templater scripts using CSS/styling plugins, etc.
    • Allows associating a different program with templater script files if the user prefers using a code editor instead of Obsidian for editing. Although this is already possible, it's up to the user to choose a custom extension, instead of using a standard one.
  • Benefits of standardised file extension: When users decide that they need to use an alternative extension for any reason, having a standardised extension is more useful compared to each user using their own custom one, especially given how active the templater community is in sharing templater scripts and snippets.
@rxlecky rxlecky added the enhancement New feature or request label Nov 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant