espressif / developer-portal

Developer Portal
https://developer.espressif.com
MIT License
7 stars 14 forks source link

feat: tabs shortcode #68

Closed horw closed 1 month ago

horw commented 1 month ago

Hello, in this PR, the tabs functionality from the Learn template was added. You can find more information about it at https://learn.netlify.app/en/shortcodes/tabs/ close #66

horw commented 1 month ago

There is example how it works image image image

f-hollow commented 1 month ago

@georgik PTAL

f-hollow commented 1 month ago

@horw All the requirements listed in #66 are fulfilled. Thanks a lot for implementing the tabs, everything works without a hitch!

@georgik merged an article with the following fragment:


  1. Clone Sample Project:

    Let's clone the project and configure TOOLCHAINS environment variable with the version of the installed Swift 6.

    • Linux:

      git clone git@github.com:apple/swift-embedded-examples.git --single-branch --branch main
      cd swift-embedded-examples/esp32-led-strip-sdk
    • macOS

      git clone git@github.com:apple/swift-embedded-examples.git --single-branch --branch main
      #export TOOLCHAINS=org.swift.600202406111a
      export TOOLCHAINS=$(plutil -extract CFBundleIdentifier raw /Library/Developer/Toolchains/swift-latest.xctoolchain/Info.plist)
      cd swift-embedded-examples/esp32-led-strip-sdk

To test the tabs, I tried to place the Linux and macOS code into a tabbed code block. To make the tabbed code block indented as the original code blocks in the article, we need to add 4 spaces before tabs/tab shortcode tags. That is fine. However, we cannot indent the code block content by more that 6-7 spaces, because markdown treats lines preceded with 8 and more spaces as code by default, so the ```bash and ``` tags become part of the visible code and no highlighting is supported in this case.

All in all, if we want a tabbed code block, we can indent shortcode tags, but we shouldn't indent the content of tabs to retain highlighting for specified languages:

1. **Clone Sample Project**:

   Let's clone the project and configure `TOOLCHAINS` environment variable with the version of the installed Swift 6.

    {{< tabs groupId="config" >}}
      {{% tab name="Linux" %}}
  Linux code block
      {{% /tab %}}
      {{% tab name="macOS" %}}
  macOS code block
      {{% /tab %}}
    {{< /tabs >}}

This comment describes the issues I came across, but it is not the issue with tabs implementation. It is the markdown's syntax peculiarities. So we should not indent the tab content by more than 6 spaces.

igrr commented 1 month ago

but we shouldn't indent the content of tabs to retain highlighting for specified languages:

Can we automatically un-indent the tab content by the same amount by which the {{% tab %}} itself was indented? When we do {{ $.Parent.Scratch.Add "tabs" (dict "name" $name "content" . ) }}, can we define a helper function which will unindent content?

f-hollow commented 1 month ago

but we shouldn't indent the content of tabs to retain highlighting for specified languages:

Can we automatically un-indent the tab content by the same amount by which the {{% tab %}} itself was indented? When we do {{ $.Parent.Scratch.Add "tabs" (dict "name" $name "content" . ) }}, can we define a helper function which will unindent content?

In the same tab, we are quite likely to be adding chunks of content in markdown with varying indentations, such as multi-level lists:

    {{< tabs groupId="config" >}}
      {{% tab name="Linux" %}}
List:

- Item
  - Subitem

    Another paragraph in the subitem.
      {{% /tab %}}
    {{< /tabs >}}

In my opinion, writing this content without initial indentations (like above) will result in fewer syntactic errors, as opposed to preceding each line of content with a fixed number of spaces (in this case, 8):

    {{< tabs groupId="config" >}}
      {{% tab name="Linux" %}}
        List:

        - Item
          - Subitem

            Another paragraph in the subitem.
      {{% /tab %}}
    {{< /tabs >}}

The latter fragment looks more appealing from the coding style perspective, but adding the right number of spaces is harder, which increases the likelihood of introducing errors.

I suggest that we try using the tabs as they are for now and revisit Ivan's suggestion later.

georgik commented 1 month ago

Nice solutions, works great. One Must be careful about indentation. IMO in case of tabs this is acceptable. The following snippet works (just remove backslashes, I put it there to avoid tripple quote rendering.)

{{< tabs groupId="config" >}}
    {{% tab name="Linux" %}}
Linux code block
\`\`\`c
#include "c"
int a= 2;
void main() {
    return 0;
}
\`\`\`
    {{% /tab %}}
    {{% tab name="macOS" %}}
macOS code block
    {{% /tab %}}
{{< /tabs >}}

LGTM. Let's merge it on Monday.

f-hollow commented 1 month ago

@horw Thank you for your contribution!

Also, thanks to all the reviewers!

I will merge this PR.