[[syntax]] is processed in Markdown code blocks rendering #892

New Issue

GiteaMirror · 2025-11-02T03:40:35-06:00

GiteaMirror commented

2025-11-02 03:40:35 -06:00

Originally created by @jeromelebleu on GitHub (Jul 14, 2017).

I've got a README.md file which includes some kind of ini code blocks. As a subsection is surrounded by two squared brackets, it is evaluated and processed by Gitea as a link. The squared brackets are removed and the code blocks is thus modified... This is problematic since it produces wrong code blocks and can involves someone to make mistakes if he/she just copy & paste it.

For example, if I write the following:

    ```ini
    [[mediagoblin_private]]
    ```

... the produced HTML code will be:

<pre><code class="language-ini">mediagoblin_private
</code></pre>

From what I understand in reading the code and trying to alter this unwanted behavior, I found at least two solutions to prevent that:

do not replace the whole ... with the content text if it's not a link,
or just do not replace it when it's in an excluded tag.

I tried both solutions and they work. For the first one, I've just commented this line. For the second one, I've replaced this line by buf.WriteString(token.String()).

As I don't know which behavior could be the best - and if there are others, they have maybe both pro/con, I let you see...

Thanks in advance!

Originally created by @jeromelebleu on GitHub (Jul 14, 2017). I've got a README.md file which includes some kind of *ini* code blocks. As a subsection is surrounded by two squared brackets, it is evaluated and processed by Gitea as a link. The squared brackets are removed and the code blocks is thus modified... This is problematic since it produces wrong code blocks and can involves someone to make mistakes if he/she just copy & paste it. For example, if I write the following: ``` ```ini [[mediagoblin_private]] ``` ``` ... the produced HTML code will be: ``` <pre><code class="language-ini">mediagoblin_private </code></pre> ``` From what I understand in reading the code and trying to alter this unwanted behavior, I found at least two solutions to prevent that: - do not replace the whole [[...]] with the content text if it's not a link, - or just do not replace it when it's in an excluded tag. I tried both solutions and they work. For the first one, I've just commented [this line](https://github.com/go-gitea/gitea/blob/master/modules/markdown/markdown.go#L501). For the second one, I've replaced [this line](https://github.com/go-gitea/gitea/blob/master/modules/markdown/markdown.go#L620) by `buf.WriteString(token.String())`. As I don't know which behavior could be the best - and if there are others, they have maybe both pro/con, I let you see... Thanks in advance!

GiteaMirror added the issue/stale type/bug labels 2025-11-02 03:40:35 -06:00

GiteaMirror closed this issue

2025-11-02 03:40:35 -06:00

GiteaMirror commented

2025-11-02 03:40:36 -06:00

@dsamarin commented on GitHub (Mar 21, 2018):

Are there any solutions/hacks that do not require modifying the code?

@dsamarin commented on GitHub (Mar 21, 2018): Are there any solutions/hacks that do not require modifying the code?

GiteaMirror commented

2025-11-02 03:40:36 -06:00

@chinglinwen commented on GitHub (May 16, 2018):

This shell snippet got wrong too, the following code can't show correctly in gitea ( Gitea Version: 1.4.0 )

if [[ ${state} == 'stop' ]]; then
        check_down
        if [[ $? == 1 ]]; then
            check_user
        else
            echo "stop success"
            exit 0
        fi
    else

Result in gitea: is not shown.

@chinglinwen commented on GitHub (May 16, 2018): This shell snippet got wrong too, the following code can't show correctly in gitea ( Gitea Version: 1.4.0 ) ``` if [[ ${state} == 'stop' ]]; then check_down if [[ $? == 1 ]]; then check_user else echo "stop success" exit 0 fi else ``` Result in gitea: [[ ${state} == 'stop' ]] is not shown.

GiteaMirror commented

2025-11-02 03:40:36 -06:00

@stale[bot] commented on GitHub (Jan 26, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Jan 26, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 03:40:37 -06:00

@0x3333 commented on GitHub (Jan 28, 2019):

This can be closed, this issue is not in effect anymore.

@0x3333 commented on GitHub (Jan 28, 2019): This can be closed, this issue is not in effect anymore.

GiteaMirror referenced this issue

2025-11-02 11:51:14 -06:00

[PR #892] [MERGED] Fix public activity showing private repos #15638

Sign in to join this conversation.