Open Graywaren opened 2 days ago
Regardless of how this is done, via aliases or other properties. This will be a lot more computationally expensive. Currently, the lists try to detect a link and display it as such. This FR would require the lists to parse the link, resolve it to a file, get the metadata for that file, and then figure out what to display.
Not sure on which issue to reply 😅
I am currently leaning towards simply implementing something like alias(true)
which would prefer the first alias if a file has aliases. It's simple. has no edge cases, is not very complex to use, and probably solves 95% of alias problems. Even if this slows down the rendering of links quite bit.
Heh, sorry about that. I wasn't sure whether or not to split things up because of the "single feature" notation in the template for requests >.> Feel free to just combine or ask me to combine them if that's better for you.
The alias thing does solve most of it, you're right. I figured it would be complex and expensive, but wasn't sure how much as I'm only just starting to learn js and such.
Would it be expensive/difficult to add unique classes or attribute class to the dom elements for the suggester items based on the file title? The list item cells that contain internal links do have the data-href attribute that contains the file title and therefore it's not too hard to select them with css to achieve the rest of the results of this, even if it's less flexible in the case of renaming a note. The suggester items don't have anything tying them to their notes or making them unique though.
Do you mean in the modal or in the suggester field? For the modal I am just reusing an existing Obsidian component, so if I want to change something there I probably have to rebuild the entire modal. Adding some extra classes or data attributes to the suggester field should be easy.
Ah, unfortunately I mean in the modal container.
'body > div.modal-container.mod-dim > div.prompt > div.prompt-results > div.suggestion-item`
Where that suggestion-item div having an attribute related to the file it was displaying the way the list item cells do (via the link having data-href) would be very handy.
Please fill out these Check-boxes
Is your Feature Request related to a Problem or Annoyance?
I use a lot of inline list suggester inputs to link to different notes, usually via optionQuery to a specific folder of notes, and often times I'd really like the list item cell to display something different than the title of the note, such as an emoji or abbreviation for a long title, be able to style it specifically easily with CSS, and have the suggester picker window to display the title different as well.
Describe the Feature you'd like
In thinking about the feature request I submitted here and the way that option(value, name) works I had the thought that it would be really neat if you could set the field for the metadata list items of the note with a metadata property on the note itself. Then when a meta bind list suggester queries a note, it would use the metadata properties to fill in the fields, the way that manually inputting them in option() would do. This becomes even more valuable with the option to add a description for the suggester picker and a custom css class.
For example, if I have a "Food Options" folder with the following notes with the listed properties: Coffee.md mb-list-name: "☕" mb-list-description: "☕ Coffee" mb-list-class: "brown"
Salad.md mb-list-name: "🥗" mb-list-description: "🥗 Salad" mb-list-class: "green"
Sushi.md mb-list-name: "🍣 " mb-list-description: "🍣 Sushi" mb-list-class: "red"
and I made a metabind inlineListSuggester that was querying the "Food Options" folder, the suggester picker would look like this:
and the inline list items would look like this:
where each would be linked to their respective note and the color is changed with a simple css snippet.
That would be amazing and offer a lot of flexibility I think, especially since it can be modified on the note, rather than needing to find every instance of an input where it was listed as a manual option to update it.
An advanced option would be to accept a link to images as the display as well, therefore offering the ability to have custom icons. (This could technically be achieved with css snippets using pseudo elements if not innate from the plug in though)
I'm not sure how difficult this would be to implement, possibly easier than having it automatically pick the first alias?, but I wanted to suggest it since I think it'd add a lot of power to this plug-in and input type.
Alternatives
No response
Additional Context
PS. Thanks for such an awesome plug-in. It's a huge part of how/why I use obsidian! The meta-bind embed is especially fantastic for daily-notes. 😸