jgm / pandoc

Universal markup converter
https://pandoc.org
Other
33.95k stars 3.35k forks source link

Allow inline attributes on reference links with md+link_attributes #8913

Open ag-eitilt opened 1 year ago

ag-eitilt commented 1 year ago

Currently, link_attributes enables attributes to be enabled inline for standard Markdown links, and for them to be centralized to apply to every usage of a reference link.[^reference] However, it doesn't allow for attributes to be added inline to a reference link, and https://github.com/jgm/pandoc/issues/2678#issuecomment-256023906 indicates that's a conscious decision.

[^reference]: I just learned about the latter, and am particularly excited about the possibilities it offers -- even if my NVim syntax highlighting doesn't treat it properly.

In the majority of cases, when the attribute applies to the link target, that does indeed make sense. However, there are also times when the attribute only applies to the content; or, rather, it provides a style hint which only makes sense when used with certain content but not others. The example I have in practice is a class I add to mark abbreviations, etc., which should be rendered in all-small-caps[^smallcaps] when I use the abbreviation as link text, but I also use the same link for the full form of the name -- [IPA][]{.cap}, but [International Phonetic Alphabet][IPA].

[^smallcaps]: The .smallcaps special handling is quite nice, but is the opposite of what I want -- that affects only the lower case, while I'm interested in only the upper case. font-variant-caps: unicase seems like it would do what I want, but is poorly supported.

I suppose the answer there is in the 'style hint' wording itself, and I should instead be using a combination of reference links and inline spans, but that just looks ugly: [[IPA][]]{.cap}, or even worse [[IPA]{.cap}][IPA]. I could also define separate [IPA]: ... {.cap} and [International Phonetic Alphabet]: ... references, and that's probably the solution I'll use going forward, but it would still be nice to be able to say 'this style is only ever applicable based on the context for this one specific instance of the link' without having to add the extra brackets.

(An even more helpful-for-my-use-case solution would be to expand the SmallCaps constructor with a boolean to track whether it should be all-small-caps/\cap vs small-caps/\sc, but even I'll admit that's likely too fine a distinction to make at the library level.)

jgm commented 1 year ago

Personally I'd just use a Lua filter to add the SmallCaps to links with content "IPA". Then your content is cleaner and you don't have to worry about forgetting to add the {.cap} sometimes.

ag-eitilt commented 1 year ago

Also a solution, certainly. However, I don't want to entrust that to a mechanical process (to my eye, JRR Tolkien should still have full caps) and I definitely don't want to have to maintain a separate whitelist, so I'm happy putting in a bit more manual effort to make sure everything looks nice. Good point on that there is already tooling to do that if people aren't as picky as I am, though!

jgm commented 1 year ago

In principle you could even make a filter sensitive to a list of strings given in the metadata, avoiding the need to hard-code a whitelist.

smallcaps:
- IPA