Add support for Definition Lists

Feature requests
61

Another vote in favor of definition lists.

62

I wish I could implement this myself! Please, support Markdown DL!

2 Likes
63

+1 from an avid fan. A critical semantic tool missing from regular Markdown’s toolbox, imho, and I think it’s shameful that CommonMark doesn’t yet incorporate it.

1 Like
64

Please, support Markdown Extra! I need better footnotes as well!

1 Like
65

+1 Definition Lists

66

a definite +1 for this.

1 Like
67

This thread is three years old, I guess I shouldn’t hold my breath?

1 Like
68

Sounds interesting, just what would be the benefit versus writing this kind of list manually?

Maybe i don’t get the point, but you could add definition lists simply by using templates or Quickadd capture macros.

69

this is my super-sad glossay with unrendered definition list: 95_glossario - KRUR

70
71

It’s a markdown standard

72

And another +1. Definition lists are an important function, especially when using Markdown for notes.

1 Like
73
  • My attitude: +1 for this
  • Why:
    • Key-value pairs are essential as a knowledge representation construct
    • Indenting ↹ and boldening, sometimes callouts that live in list items as workarounds are not as clean
1 Like
74

+1 (emphatic)

I regularly run into the most basic use case for definition lists when note taking: I am often exposed to acronyms (especially) or words, the meaning of which I have to discover. Once I’ve discovered the meaning of an acronym or word, I embed a definition in my note or documentation for future reference.

Additionally, and as many others have stated, I have found that the definition list formatting makes for an excellent FAQ or Q&A section in notes or documentation.

I’m using HTML to achieve this for now, but it’s extremely cumbersome to create and edit compared to the markdown implementation.

2 Likes
75

+1 from me as well. This is a common use case for me and the definition list syntax is perfectly suitable for this. It’s a big omission.

I get that supporting CommonMark is important, but that doesn’t mean you can’t support any other features on top of it.

1 Like
76

+1
I wanted to implement a plugin for it myself, so I can make a move from joplin, but turns out parser plugins are not supported. It’s a common and straight-forward feature of markdown that has decently well-defined format.

Portability-wise, it is unlikely to cause problems. And we already have callouts/admonitions that from what I’ve seen are implemented differently in every parser. Compared to callouts, deflists are not something to worry about, and they degrade more gracefully to plain text as well.

77

On the other hand, it is worth considering that while the attention gets dispersed through different markdown feature requests, implementing parser plugin API would indirectly solve all of them.

It really deserves more spotlight, and I think it would not be unreasonable to assume that all the support given to various markdown feature requests applies to parser plugin request as well, which would make it far more valuable than either of those individual features.

Developers of core obsidian have to consider a lot of factors when deciding which syntax to support, but extensions would allow users to pick and choose what they need as opt-in, without any implications to the portability of core obsidian.

1 Like
78

Sigh… sad to see this isn’t working. A (likely useless) +1 from me.

1 Like
79

2024 now and would like to see this added

2 Likes