FR: 'Other' entry for select and multiselect

[mayurankv]

For select and multiselect inputs, there should (in my opinion at least) be another option for 'other' inputs.

For select, this would just be click Other and it resolved into an INPUT[text] field For multiselect, this would be similar but allow unlimited additions of Other, each of which results into a text field. i.e. the other button just adds another line of text input which should also be removable.

The select part seems pretty easy to fit in but not quite sure how much work the multi-select would be. Thanks for this plugin!

[mProjectsCode]

This is certanly possible, but it is a bit more complicated as it seems. For this to work, the input field needs a different place to store persistent data, otherwise all options that are not contained within the declaration will be lost on rerender (note reopen and obsidian restart). I have done something similar to this for a different plugin. The input fields will need a unique id, that is persistent, so that the plugin can make the association between the input field and the stored data. Meaning it pobaply needs an id argument similar to this.

INPUT[input_type(id(some_uid)):bind_target]

[mayurankv]

Hmmm, I understand that that would be the case if it is not linked to a frontmatter field, but if it is, wouldn't the option be stored there? My request at least only wants the options to persist while they are being used. i.e. if I wanted to have a metadata field managing book genres, I don't want to have to have an extremely long and exhaustive list, I just want to list the main ones and then an other entry where I can put in any niche genre if required. If I then decided that one of the already listed genres is a better fit and change away from the 'other' option, then I would not expect that genre to remain, just that the option would return to its empty 'other' state.

Same for multi-select in that: unless the value is in the frontmatter, it doesn't need to be retained.

I'm not sure how that would work without frontmatter but tbh I'm not sure how the input is retained if not linked to frontmatter anyway aha.

---

Just to give an explicit example with a select block:

1. I have a book template with options: [Fantasy,Romance,Historical,Other]

2. I decide my latest book is in fact science fiction but I don't want to add science fiction to the suggested list, so I add it to the other entry resulting in the 'Other' selected with some custom text input - 'Sci-Fi' in this case.

The YAML looks like genre: Sci-Fi

3. I then decide Sci-Fi is pretty much Fantasy and change it back to Fantasy in the selector. Here is where I think we differ. I believe you expect Sci-Fi to remain as an option, I want Sci-Fi to revert back to the empty 'Other' entry and for the YAML to be: genre: Fantasy. No remnant that it was ever Sci-Fi remains.

I believe that wouldn't need an ID. SImilarly for multi-select, unless it is actively being stored in the YAML, it doesn't need to be remembered and thus wouldn't need an ID.

[mProjectsCode]

Ah, I see. Yes, that would be easier to do. Because of how the plugin works the transfer function between the input field and the frontmatter needs to be bijective. It seems like that is the case, so it should be possible. I will test around a bit in the next few days and see if I can come up with a working solution.

[mayurankv]

That sounds amazing! Let me know if there's anything I can do to help clarify.

[mProjectsCode]

You can kind of do this with the list input field in the next release.