Sharing tab content

[PGijsbers]

cf. squidfunk/mkdocs-material#5702 (comment)

I think it would be nice to be able to share the same content between multiple tabs without duplication. E.g., instead of:

=== A
  foo

=== B
  foo

=== C
  bar

where "foo" is duplicated, have a syntax to re-use "foo". While I can group tabs manually, e.g.:

=== A, B
  foo

=== C
  bar

this doesn't work well with linked tabs, possibly requires re-ordering, and is visually different (one tab instead of two).
It would be great if it was possible to have some syntax for re-using the content across tabs, for example:

=== A
=== B
  foo

=== C
  bar

or

=== A
  foo

=== B copy A  # use a keyword

=== C
  bar

to generate three tabs (A, B, and C) where A and B have content "foo" and C has content "bar".
Personally I would prefer the latter as the former still requires re-ordering of the tabs, but anything that makes three distinct visual tabs while re-using the description between two works for me.

Context: I am writing documentation that can have different instruction for different operating systems, and I will use (linked) tabs to make it easy to navigate. However, frequently I find myself documenting the same steps for MacOS and Linux. It would help a lot with maintenance if this content only has to be written (or edited) once.

[facelessuser]

If we were to do anything like this, we would most likely do this in the new block tab format: https://facelessuser.github.io/pymdown-extensions/extensions/blocks/plugins/tab/. While we haven't stopped back porting some features to the === "tab" format, that format is not as flexible as the new format.

I imagine we would not implement multiple approaches to reusing content, but instead implement one explicit way that works in all cases.

So instead of back filling content to empty tabs and having ways to explicitly define where to copy content from, we would likely only implement the latter (demonstrating with new format):

/// tab | Title 1
content
///

/// tab | Title 2
    copy: 1
///

This approach would require the content to be declared before it is referenced.

This is just me thinking out loud. If we did this, the approach would of course be subject to changes, but I think this is likely the direction I would initially be interested in trying.

[facelessuser]

I do agree that such a feature may be helpful and desirable, but my biggest concern is that I will have multiple edge cases that will make maintenance difficult. If I just consider the extensions I support, I know I would need to make special, extension-specific logic to account for the way certain extensions work. I imagine this would be even worse if I were to consider all the extensions outside the default Python Markdown ones and the ones I support.

As an example, headers generate IDs for anchors using a known format. We could duplicate them, but then we'd have to update duplicate IDs, which is doable. But code blocks can generate IDs to link code lines, and that ID format is different from headers. Now I need special, extension-specific code to handle code block IDs.

I realize I'm getting into implementation details that outside parties do not care about, but it is important to state this to illustrate that the feature involves more than simply copying the content. There are ways to get around some of this, but they involve some other complications due to how Python Markdown does things. What I want to convey is that the maintenance burden for this may be more than I'm willing to support.

Really, what you need, is a special plugin that can preprocess a Markdown file, and has a syntax that can be parsed quickly and easily, irrespective of other extension syntax so you can duplicate the code before any other Markdown parsing occurs. Sort of like a template language, but for duplicating code with a specific Markdown file.

You could utilize something like Snippets to do this:

/// tab | Tab 1
<!-- -8<- [start: copy1] -->
Some content
<!-- -8<- [end: copy1] -->
///

/// tab | Tab 2
--8<-- "docs/src/markdown/index.md:copy1"
///

That's probably the best I could offer right now. Is this less hassle than just copying and pasting the content manually, I guess that is something the user would need to decide.

[facelessuser]

I will say that I'm fairly certain I could have this work for 90% of cases. Fenced code blocks, as implemented in Pymdown Extensions, already provide a mechanism allowing me to get at the original raw text. But if we implemented this, we'd still have to issue caveats stating that if you manually set an ID and duplicate it (maybe with raw text, attribute list extension, or some other 3rd party extension) you will have duplicate IDS that we will not dedupe. Also, we'd have to state that this feature may not be compatible with some other extensions and that we will not be providing support for specific 3rd party extensions that do not play nice with the feature.

[PGijsbers]

What I want to convey is that the maintenance burden for this may be more than I'm willing to support.

That much was clear, and I would fully respect the decision not to add a niche feature because of the additional (maintenance) work.
As an open source contributor/creator of a few other projects, I have been on the same end as well :)

Is this less hassle than just copying and pasting the content manually, I guess that is something the user would need to decide.

I would still use it, but I can imagine it would turn off some people.

Ps. I don't know whether I should close the discussion or not. Please close it if appropriate.

[facelessuser]

I would still use it, but I can imagine it would turn off some people.

The Snippets approach can already be done today, see extension here. It does implement recursion protection, but the initial Markdown buffer does not have a file associated with it, so it can reference itself, it just can't do nested references to itself. Also, including a file that then references itself won't work. I imagine if it became a problem, we could allow a user to set their own recursion limit, but it hasn't been a problem yet.

[PGijsbers]

Ah, sorry, I misunderstood. Thanks!