adam/vscode-front-matter
1
0 Fork 0
mirror of https://github.com/estruyf/vscode-front-matter.git synced 2026-11-04 09:32:21 +01:00
Code Issues 77 Packages Projects Releases Wiki Activity

Enhancement: Multiselect-field for custom taxonomy #94

New Issue
Closed
opened 2026-10-05 02:25:08 +02:00 by adam · 6 comments
adam commented 2026-10-05 02:25:08 +02:00
Owner
Copy link
Copy source

First, thanks for this great extension! Se we were looking for something like this for a long time now.

We have a lot of repetitive content where accurate spelling and capitalization is important. We want to avoid different spellings between all documents.

It would be great to be able to create and use custom taxonomy collections (e.g. "tags.customers", "tags.acronyms") to leverage the power of UI multiselect fields (as with regular tags/categories).

It would certainly be possible for us to create all of this only via tags and categories, but the collections would quickly become too cluttered and overcrowded.
Another possibility would be to solve each collection via a choice field. However, it would be great to have the respective collection not hardcoded so that a (not very tech-savy) editor has the possibility to add terms independently.

Maybe I just haven't found the setting I need yet. In this case it would be great if you could point me in the right direction.

First, thanks for this great extension! Se we were looking for something like this for a long time now. We have a lot of repetitive content where accurate spelling and capitalization is important. We want to avoid different spellings between all documents. It would be great to be able to create and use custom taxonomy collections (e.g. "tags.customers", "tags.acronyms") to leverage the power of UI multiselect fields (as with regular tags/categories). It would certainly be possible for us to create all of this only via tags and categories, but the collections would quickly become too cluttered and overcrowded. Another possibility would be to solve each collection via a choice field. However, it would be great to have the respective collection not hardcoded so that a (not very tech-savy) editor has the possibility to add terms independently. Maybe I just haven't found the setting I need yet. In this case it would be great if you could point me in the right direction. <!-- github-sync-id:1008713257 -->
adam closed this issue 2026-10-05 02:25:08 +02:00
adam commented 2026-10-05 02:25:09 +02:00
Author
Owner
Copy link
Copy source

So if I understand you correctly, you want a structure as follows:

{
  "tags": [
    "customers": [
      "Customer 1",
      "Customer 2"
    ]
  ]
}

If so, this is indeed something that isn't supported yet. It would require an enhancement to the tag picker + tags and category logic.

So if I understand you correctly, you want a structure as follows: ``` { "tags": [ "customers": [ "Customer 1", "Customer 2" ] ] } ``` If so, this is indeed something that isn't supported yet. It would require an enhancement to the tag picker + tags and category logic. <!-- github-comment-id:928901548 -->
adam commented 2026-10-05 02:25:10 +02:00
Author
Owner
Copy link
Copy source

Dear Elio,
wow, that was a quick reply. thank you!

Yes. Indeed that was my initial thought.

But after sleeping over it, it seems that it would be easier and make more sense to have a structure like this:

{
    "frontMatter.taxonomy.tags": [
        "Tag 1",
        "Tag 2"
    ],
    "frontMatter.taxonomy.categories": [
        "Cat 1",
        "Cat 2"
    ],
    "frontMatter.taxonomy.custom": [
        "Custom 1",
        "Custom 2"
    ],
    "frontMatter.taxonomy.more": [
        "More 1",
        "More 2"
    ]
}

This way there would be no need to deal with a subtree hierarchy.

I believe that one benefit and great power in using your extension lies in the possibility to manage repeating content. There is little added value in having a pure string-field. When editing I have to look up the repeated content I want to insert in some different place, copy it and then add it to the field. This could also be done in plain markdown without a hassle (even for non tech-savy editors). But having the possibility to choose from a list ( e.g. an author, an acronym, ...) and to be sure the spelling is right, and also edit this list without hardcoding it, might produce a great benefit.

So far I only used vanilla js and never did anything in typescript, yet. But maybe, if you could direct me, this would be the ideal point in time to jump on the ts-train and learn it...

Thanks for your time and effort!

Dear Elio, wow, that was a quick reply. thank you! Yes. Indeed that was my initial thought. But after sleeping over it, it seems that it would be easier and make more sense to have a structure like this: ``` { "frontMatter.taxonomy.tags": [ "Tag 1", "Tag 2" ], "frontMatter.taxonomy.categories": [ "Cat 1", "Cat 2" ], "frontMatter.taxonomy.custom": [ "Custom 1", "Custom 2" ], "frontMatter.taxonomy.more": [ "More 1", "More 2" ] } ``` This way there would be no need to deal with a subtree hierarchy. I believe that one benefit and great power in using your extension lies in the possibility to manage repeating content. There is little added value in having a pure string-field. When editing I have to look up the repeated content I want to insert in some different place, copy it and then add it to the field. This could also be done in plain markdown without a hassle (even for non tech-savy editors). But having the possibility to choose from a list ( e.g. an author, an acronym, ...) and to be sure the spelling is right, and also edit this list without hardcoding it, might produce a great benefit. So far I only used vanilla js and never did anything in typescript, yet. But maybe, if you could direct me, this would be the ideal point in time to jump on the ts-train and learn it... Thanks for your time and effort! <!-- github-comment-id:929155704 -->
adam commented 2026-10-05 02:25:11 +02:00
Author
Owner
Copy link
Copy source

Thanks for your feedback.

Just in case to have a better config IntelliSense, the following might make it easier and better supported:

{
  "frontMatter.taxonomy.tags": [
      "Tag 1",
      "Tag 2"
  ],
  "frontMatter.taxonomy.categories": [
      "Cat 1",
      "Cat 2"
  ],
  "frontMatter.taxonomy.custom": {
    "custom": [
      "Custom 1",
      "Custom 2"
    ],
    "more": [
      "More 1",
      "More 2"
    ]
  }
}

This way the frontMatter.taxonomy.custom property can be laid out in the schema.

Usage on the field can be achieved by setting the type property to taxonomy (new) and taxonomy property (new) to the name of your taxonomy key.

Don't be afraid of TypeScript, you might fall in love with it once you start using it 🤓.

For this change to happen, the following needs to be changed:

  • package.json: Introduce a new setting + object schema
  • settings.ts: Add the new setting to the constants
  • ExplorerView.ts: Add the new setting to the getSettings method - this pushes the settings to the webview (panel)
  • metadata.tsx on the panelWebView: add a new TagPicker for the custom setting

Those would be the main steps to make it happen.

Thanks for your feedback. Just in case to have a better config IntelliSense, the following might make it easier and better supported: ```json { "frontMatter.taxonomy.tags": [ "Tag 1", "Tag 2" ], "frontMatter.taxonomy.categories": [ "Cat 1", "Cat 2" ], "frontMatter.taxonomy.custom": { "custom": [ "Custom 1", "Custom 2" ], "more": [ "More 1", "More 2" ] } } ``` This way the `frontMatter.taxonomy.custom` property can be laid out in the schema. Usage on the field can be achieved by setting the `type` property to `taxonomy` (new) and `taxonomy` property (new) to the name of your taxonomy key. Don't be afraid of TypeScript, you might fall in love with it once you start using it 🤓. For this change to happen, the following needs to be changed: - `package.json`: Introduce a new setting + object schema - `settings.ts`: Add the new setting to the constants - `ExplorerView.ts`: Add the new setting to the `getSettings` method - this pushes the settings to the webview (panel) - `metadata.tsx` on the `panelWebView`: add a new `TagPicker` for the custom setting Those would be the main steps to make it happen. <!-- github-comment-id:929278329 -->
adam commented 2026-10-05 02:25:11 +02:00
Author
Owner
Copy link
Copy source

Another option is to use the currently supported choice field which you can set up in your default or custom content type.

https://frontmatter.codes/docs/content-types

The downside right now is that it doesn't support multi-select, but that can be a nice enhancement.

Another option is to use the currently supported `choice` field which you can set up in your default or custom content type. https://frontmatter.codes/docs/content-types The downside right now is that it doesn't support multi-select, but that can be a nice enhancement. <!-- github-comment-id:930240550 -->
adam commented 2026-10-05 02:25:12 +02:00
Author
Owner
Copy link
Copy source

Thank you for your effort!

Yes indeed. We went with a combination of choice, tags and categories for now.
Thank you & stay safe!

Thank you for your effort! Yes indeed. We went with a combination of `choice`, `tags` and `categories` for now. Thank you & stay safe! <!-- github-comment-id:930263740 -->
adam commented 2026-10-05 02:25:13 +02:00
Author
Owner
Copy link
Copy source

That is great to hear @lucasdon! I'll work on the multi-selection option for the choice fields.

That is great to hear @lucasdon! I'll work on the multi-selection option for the choice fields. <!-- github-comment-id:930264731 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/vscode-front-matter#94