Support Go Templates / Hugo Template?

[cmahnke]

Hugo is a static site generator written in Go, some might have heard of it. It uses Go templating.

Before trying to add a definition (maybe as a PR) I would like to know what's the reason behind this sentence from the README:

When adding languages, follow the structure of existing entries, and use the language name defined by GitHub in languages.yml.

Does this action require somehow to have a language added to the referenced list before it will work? Neither Go templates nor Hugo templates are part of this list and declaring them as being Go themself might be a pragmatic approach but is wrong...

[alstr]

Adding support for a new language usually requires the language to be in GitHub’s languages file, to allow the action to determine the language based on the file extension.

A recent update to the action has added support for custom languages, so you can add your own language definitions in the workflow file.

[cmahnke]

@alstr Thanks for your reply.

I've defined my own file, referenced it in the LANGUAGES param as URL, but still get a error message:

Could not check layouts/partials/preview/preview-internal.html for TODOs as this language is not yet supported by default.

This message implies, that I need to turn on the language addtionally to its definition?

The file:

[
  {
    "language": "Hugo Templates",
    "extensions": [
      ".html",
      ".json",
      ".geojson",
      ".gjson",
      ".rss",
      ".scss",
      ".css"
    ],
    "markers": [
      {
        "type": "block",
        "pattern": {
          "start": "\\{\\{/\\*",
          "end": "\\*/\\}\\}"
        }
      }
    ]
  }
]

Note, that there are only block comments, line in CSS, so I left the section about line comments out.

Setting NO_STANDARD to true doesn't change anything either.

What am I missing?

[alstr]

The message indicates it can't find a matching definition for .html which seems to suggest it can't load the languages file.

Could you share your workflow file if possible?

Maybe @Christoph-Koschel who implemented this functionality will have a better idea.

[Christoph-Koschel]

I can look into it, but as mentioned above, if you could post your workflow file and the GH action log, it will be easier for me to understand/identify the error.

[cmahnke]

@Christoph-Koschel The workflow file is located at https://github.com/cmahnke/projektemacher-base/blob/main/.github/workflows/qa.yml The language file is at https://github.com/cmahnke/projektemacher-base/blob/main/.gotml.json This is the run of the action https://github.com/cmahnke/projektemacher-base/actions/runs/7772597134/job/21195210526

[Christoph-Koschel]

I have to say that I made a mistake in my implementation of custom languages. I thought that the ace_mode property was unnecessary, so I set it to an empty string. But it is used in the action, causing the parser to filter out the definition because it fails at the TodoParser._get_file_details method when it checks the property.

class TodoParser(object):
    ...
    def parse(self, diff_file):
        ...
        curr_markers, curr_markdown_language = self._get_file_details(curr_file)
        if not curr_markers or not curr_markdown_language: # "or not curr_markdown_language" cause this issue
            print(f'Could not check {curr_file} for TODOs as this language is not yet supported by default.')
            continue
        ...

What I don't really understand why the ace_mode is stored and passed in the Issue class (markdown_language property). Maybe @alstr can explain that for me?

There are two ways to fix this issue:

• First, we set the ace_mode to a non-empty string constant, e.g. 'text', which most languages have in the linguistic file.

• Or when defining a custom language, the ace_mode is a property that needs to be set by hand

I can't say which is the better solution because, as I said, I don't know how the ace_mode affects the output.

[alstr]

ace_mode is the language name for Markdown purposes, as explained here:

https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-and-highlighting-code-blocks#syntax-highlighting

It is used in the issue creation to apply the correct highlighting to the code block:

https://github.com/alstr/todo-to-issue-action/blob/1ac55ceb2092f8edadd3043c8c265c829003d98b/main.py#L124

If ace_mode is undefined, the action assumes that the language doesn't exist, and it doesn't know how to handle it.

Looking at the Linguist repo, it says Use "text" if a mode does not exist. That may be the best default value.

[cmahnke]

@alstr Does the suggestion to use text apply to the internals (for implementing custom languages) or should I set it in the syntax.json file (instead of "Hugo Templates" as language)?

[alstr]

It was something to change in the action's code rather than on your side. I've released an update now where the default for ace_mode is text; please could you let us know if that makes a difference?

[cmahnke]

@alstr Thanks, it works now as expected! I'm not sure if your interested in the configuration fragment, since Hugo templates aren't that widely used and there is a huge overlap with HTML / CSS etc. CC @jmooring