Markdown: Heading auto id #9858

tim-gromeyer · 2023-02-14T19:58:00Z

As I mentioned in #9855, I don't like the default title ID. I also didn't want to use commands or give the title an ID as described here. That's why I created this PR to change the default title id. I have already tested it with HTML and PDF. It worked.

albert-github · 2023-02-14T20:07:55Z

I don't think this will work as there are other places in doxygen that rely on the autotoc_md.

tim-gromeyer · 2023-02-14T20:19:26Z

Ah, I found these places:

I'll make it WIP as long as this is not fixed.

tim-gromeyer · 2023-02-14T21:31:03Z

The tests have already specified Id's. Since the id now contains the title (instead of autotoc_md + the number) the ids in the tests are wrong.

see:

The tests fail because the id differs and that's the whole point of this PR. @albert-github Your opinion on this?

albert-github · 2023-02-15T08:01:28Z

My opinion is don't change, the procedure has been well thought about and one should as user (nearly) never link to automatically generated anchors as they might change, so they should only be used internally by / in the program.

albert-github · 2023-02-15T14:43:53Z

Did you try e.g. the example in the attached file: example.tar.gz
as far as I can tell this now throws the warnings:

.../intro.md:5: warning: found subsection command (id: 'introduction') outside of section context!
.../intro_2.md:5: warning: found subsection command (id: 'introduction-1') outside of section context!

tim-gromeyer · 2023-02-15T15:13:35Z

Yeah, this is due to this line: https://github.com/doxygen/doxygen/blob/master/src/docnode.cpp#L5687.
I'm still searching for a solution there.

tim-gromeyer · 2023-02-15T20:50:19Z

Does anybody know why we check for autotoc_md here

albert-github · 2023-02-16T11:27:51Z

The repository gives:

Commit: 5b5db5372a769fc15b29981164014b42815f9ae6 [5b5db53]
Date: Sunday, December 15, 2019 11:33:40 AM
Prevent writing automatic anchors to the tag file

Still I don't understand what the use case would be for this change, like as said before in #9858 (comment) the anchors should only be used internally.

tim-gromeyer · 2023-02-16T12:07:37Z

Still I don't understand what the use case would be for this change

For better compatibility with GitHub. In GitHub READMEs I often see that another section has been linked to. GitHib itself also generates ids for the headings. Doxygen also generates ids for headings, butt the name is different. You can assign an id by adding { #<your_id> }, but that doesn't work with GitHub. Example: https://github.com/jothepro/doxygen-awesome-css/blob/main/docs/tricks.md#diagrams-with-graphviz-tricks-graphviz

like as said before in #9858 (comment) the anchors should only be used internally.

I understand that but the standard ids of Doxygen limit the compatibility of READMEs between Doxygen and GitHub.

albert-github · 2023-02-16T13:08:23Z

I thought so, there are already a number of issues regarding the links in markdown files (see e.g. #8378 and the comment #8378 (comment)).
The major problem is the fact that links like (...)[...] are not standardized / the mechanism to be used is not described.

tim-gromeyer · 2023-02-16T14:40:27Z

The major problem is the fact that links like (...)[...] are not standardized / the mechanism to be used is not described.

I completely agree with you. We could implement the heading auto-identifier as GitHub has, and add an option to switch between the default (autotoc_md) and GitHub's. The option would prevent existing websites from breaking.

GitHub's and Pandoc's mechanisms are described here: mity/md4c#175

albert-github · 2023-02-16T16:54:10Z

Thanks for the link to the (in-official) description, it is the first time I see something like it.
When implementing something it should probably be as close as possible to the GitHub / pandoc conventions though, GitHub won't probably not understand some "pandoc" ids as . keeps it (what does GitHub do with it)?

It should also be taken into account that in doxygen link ids are global.

Note that with the tag reader it should bet taken into account that the read file might be from an older version of doxygen and thus can have autotoc_md... so that this needs to be filtered in the same way as before.

tim-gromeyer · 2023-02-16T19:38:41Z

When implementing something it should probably be as close as possible to the GitHub / pandoc conventions though, GitHub won't probably not understand some "pandoc" ids as . keeps it (what does GitHub do with it)?

GitHub removes the .. See here: https://github.com/tim-gromeyer/stackoverflow/blob/tests/README.md.
The implementation I made is pretty close to GitHub's. The only difference I know is that when the id is empty it falls back to autotoc_md.

Note that with the tag reader it should bet taken into account that the read file might be from an older version of doxygen and thus can have autotoc_md... so that this needs to be filtered in the same way as before.

I would add an option like HEADING_AUTO_IDENTIFIER which defaults to DOXYGEN and can also be set to GITHUB and maybe PANDOC. This would prevent any compatibility problems.

tim-gromeyer · 2023-02-17T13:11:39Z

@albert-github I added a option. Would you adjust the text or leave it like it is now.

tim-gromeyer · 2023-02-17T16:18:07Z

If anyone wants to test the GitHub implementation: https://godbolt.org/z/qcvrx1cff

doxygen · 2023-02-17T20:27:43Z

@tim-gromeyer when you are ready with your changes, can you squash your commits to make it easier to review. And please do not do unnecessary changes like sorting #include's

doxygen · 2023-02-17T20:31:28Z

src/markdown.cpp

 {
-  // Replace space with '-'
-  std::replace(str.begin(), str.end(), ' ', '-');
+  static std::string_view germanSharpS = "ß";


There are thousands of non-ascii characters, why is only this one getting a special treatment? You should assume the string has UTF-8 encoding, see utf8.h for helper functions.

For the ß, I know GitHub leaves it in the id, see https://github.com/tim-gromeyer/stackoverflow/blob/tests/README.md

Please also add in comment a list of rules to show how characters are replaced.

tim-gromeyer · 2023-02-17T20:52:39Z

And please do not do unnecessary changes like sorting #include's

I'm sorry for sorting your includes. My IDE does it automatically.

tim-gromeyer · 2023-02-17T21:34:34Z

@doxygen I finally squashed it! You can review it if you want to. Just ignore the pandocHtmlIdentifier. I couldn't get the function working and the code in the function is a total mess.

tim-gromeyer · 2023-02-17T23:26:15Z

Before anybody reviews, I'm currently working on an better approach using some helper functions from utf8.h

albert-github

Some quick remarks / comments / things to change / add

albert-github · 2023-02-18T11:31:04Z

src/tagreader.cpp

@@ -457,7 +457,6 @@ class TagFileParser
        case InMember:
        case InPackage:
        case InDir:
-          if (m_curString.endsWith("autotoc_md")) return;
          break;


Removing this line will give problems when a tag file is used from the 1.8.16 version of doxygen is used as here in the p1.tag file of the given example there is the line:

<docanchor file="md_intro" title="Description">autotoc_md0</docanchor>

I dont really understand this. As far as I can see it starts with autotoc_md, not ends with. It ends with 0 but thats not what we checked for.

I think you are right, probably a bug no one noticed, the tag file indeed gives quite clearly autotoc_md0 so it should be startsWith instead of endsWith.

Yeah and because it went unnoticed for so long I thought it's unnecessary and removed it. If you want I can add some code and check if we are in the doxygen Mode and than check if it starts with autotoc_md.

I think it is better to add the correct test.

I'll do it today tonight(about when I commited yesterday)

albert-github · 2023-02-18T11:33:10Z

src/definition.cpp

+  if (!m_impl->sectionRefs.empty()) {
    //printf("%s: writeDocAnchorsToTagFile(%d)\n",qPrint(name()),m_impl->sectionRef.size());


Please keep also consistent layout, in this case the { bracket not at the end of the line but on the next line.
(multiple places)

albert-github · 2023-02-18T11:41:48Z

src/definition.cpp

@@ -395,13 +395,13 @@ void DefinitionImpl::addSectionsToIndex()

 void DefinitionImpl::writeDocAnchorsToTagFile(TextStream &tagFile) const
 {
-  if (!m_impl->sectionRefs.empty())
-  {
+#define VECTOR_CONTAINS(x, y) (std::find(x.begin(), x.end(), y) != x.end())


As this define is used multiple times wouldn't it be better to have it as a global lambda or (template) function or in a global include file?

albert-github · 2023-02-18T11:44:29Z

src/docnode.h

@@ -1072,9 +1072,9 @@ class DocPara : public DocCompoundNode
    const HtmlAttribList &attribs() const { return m_attribs; }
    void setAttribs(const HtmlAttribList &attribs) { m_attribs = attribs; }

-  private:


For the private don't remove the spaces (consistency).

albert-github · 2023-02-18T11:51:39Z

src/markdown.cpp

 {
-  // Replace space with '-'
-  std::replace(str.begin(), str.end(), ' ', '-');
+  static std::string_view germanSharpS = "ß";


Please also add in comment a list of rules to show how characters are replaced.

albert-github · 2023-02-18T11:54:29Z

src/markdown.cpp

+    static QCString behaviour = Config_getEnumAsString(HEADING_AUTO_IDENTIFIER);
    QCString id;
-    id.sprintf("autotoc_md%d",autoId++);
+    if (behaviour == "DOXYGEN")


Don't test on the string value but on the enum value like is done e.g. for WARN_AS_ERROR in message.cpp.
Makes it also possible to use a switch statement with additional benefit that some compilers will warn when a value is not handled.

tim-gromeyer · 2023-02-18T16:10:29Z

Thank you for the review. I will change it next time when I have time again!

tim-gromeyer · 2023-02-18T21:46:43Z

I fixed 1 last bug I found, fixed the code formatting ans squashed it.

tim-gromeyer · 2023-02-23T16:14:18Z

I have now tested it too and it works!

albert-github · 2023-02-23T17:17:29Z

I see in the HTML directory some strange filenames appear when in the DOXYGEN mode i.e. the file name: autotoc_md0.html
whilst in the old situation this was: md_aa.html

The used source file aa.md:

# Some page

Some text

the used Doxyfile:

QUIET = YES

I don't think this is nice and that it should be corrected (even though it is an internal name).

Example: example.tar.gz

tim-gromeyer · 2023-02-23T18:44:08Z

Unfortunately I have no idea how to fix this, maybe I'll figure it out.

tim-gromeyer · 2023-02-23T18:48:54Z

@doxygen I found a bug(also in my version).
I wrote a comment unter the commit(113c1b5):
To reproduce:
index.md:

[TOC]

# Test {#test}

## Test

Doxyfile:

MARKDOWN_ID_STYLE = GITHUB

doxygen · 2023-02-23T19:21:11Z

@albert-github , @tim-gromeyer Thanks for the quick feedback. Commit e1ba6ae should address both issues.

tim-gromeyer · 2023-02-23T19:46:51Z

The error I found seems fixed, I'm glad I could help!

albert-github · 2023-02-25T14:19:51Z

Looks like I found 2 more problems. With the code:

# bun

Some text

## Table of Contents

- [bun](#bun)
  - [`Bun.spawn` – spawn a process](#bunspawn--spawn-a-process)


## `Bun.spawn` – spawn a process

`Bun.spawn` lets you quickly spawn a process. Available as of Bun v0.2.0.

I get the warnings:

README.md:7: warning: unable to resolve reference to 'bun' for \ref command
README.md:8: warning: unable to resolve reference to 'bunspawn--spawn-a-process' for \ref command

"bun" the first header is promoted to the page level (@page command) but this make the "bun" link not present. Probably an extra \ianchor bun is needed here

the "bunspawn--spawn-a-process", this is a bit a mean one as it looks like we have a minus sign here (octal 055) but in fact it is s special minus sign consisting of three bytes (octal 342 200 223). Looking at the resulting markdown code:

@page md__r_e_a_d_m_e bun\ilinebr

Some text

@section table-of-contents Table of Contents

- @ref "bun" "bun"
  - @ref "bunspawn--spawn-a-process" "`Bun.spawn` – spawn a process"


@section bunspawn-–-spawn-a-process <tt>Bun.spawn</tt> – spawn a process

<tt>Bun.spawn</tt> lets you quickly spawn a process. Available as of Bun v0.2.0.

we see that the special minus is not filtered out of the section label.

Example: example.tar.gz

albert-github · 2023-02-25T14:37:37Z

Another one, regarding numbers:

# Note

As of 3.0.0, the History.md file has been deprecated.
[Please refer to the full commit logs available on GitHub](https://github.com/chaijs/chai/commits/master).

---

2.3.0 / 2015-04-26
==================

some more text

give a lot of warnings like:

xx.md:1: warning: Unexpected character '3' while looking for section label or title

and one:

xx.md:8: warning: Invalid or missing section label

This is due to the fact that the translation of

2.3.0 / 2015-04-26
==================

is:

@section 230--2015-04-26 2.3.0 / 2015-04-26

where the label is:

230--2015-04-26

so starting with a number which is not (yet) supported.

Example: example_2.tar.gz

(Note: found in groupoffice package)

tim-gromeyer · 2023-02-25T18:51:14Z

Another one, regarding numbers:

I already know this one. That's why I didnt implement pandoc. There was just no way to test if it works.

The bug with the EN - is a tricky one indeed. I think by using the ASCII number(45 I think) instead if the dash we can avoid the issue.

doxygen · 2023-02-26T14:13:19Z

@albert-github with this commit I've tried to address the 2 "bun" related issues. The last issue with headers starting with a digit, I'm not sure yet if we can or want to support that (not allowed in HTML4 and XHTML).

albert-github · 2023-02-26T14:26:54Z

There are a number sides on the number issue:

to be honest I don't know what e.g. GitHub does with the labels starting with a number (didn't yet see an example, I only saw the header so far)
the warning given by doxygen, this is a bit of an annoying side effect of the MARKDOWN_ID_STYLE=GITHUB (as already used by Fossies)

As a solution I can think of:

in case a (potential) label starts with a number we do a fallback to a more specific doxygen label by prepending to the MARKDOWN_ID_STYLE=GITHUB label a specific term like, autotoc_md<number>_<label> where <number> is an increasing number so it is always unique and <label> is the MARKDOWN_ID_STYLE=GITHUB type label. {Probably also gives later on the easiest conversion when we know what GitHub does).

albert-github · 2023-02-26T14:32:23Z

I just found an example on GitHub in respect to numbers and they violate HTML4 / XHTML as in the example I found at
https://github.com/oven-sh/bun/blob/main/src/CHANGELOG.md the "label" 0.41.0 is translated into #0410.

tim-gromeyer · 2023-02-26T14:39:33Z

to be honest I don't know what e.g. GitHub does with the labels starting with a number (didn't yet see an example, I only saw the header so far)

It includes all the numbers, for example:

2.3.0 / 2015-04-26
==================

will be #230--2015-04-26.

0.41.0 is translated to #0410 because GitHub removes the dots because they are punctuation.

Maybe we can add an warning, that it might break HTML4 and XHTML compatibility

albert-github · 2023-02-26T14:47:28Z

I don't think it is a good idea to break HTML4 / XHTML compatibility I think it is better that we translate the (as example 0.41.0) like given before:

the definition place

0.41.0
-------

becomes

@section autotoc_md1_0410 "0.41.0"

usage place

[the chapter 0.41.0](#0410)

becomes

\ref autotoc_md1_0410 "the chapter 0.41.0"

tim-gromeyer · 2023-02-26T15:14:12Z

Sounds like a good idea, but would be harder to implement.
I would suggest removing the <number> from autotoc_md<number>_<label> as long as the reason is "so it is always unique". The GitHub label itself already has a number at the end if it occurs in multiple places.

albert-github · 2023-02-26T16:56:46Z

I agree that the <number> is not necessary as in case of multiple identical <label>s a number is appended. This brings me straight away with the next problem I encountered (also in the "bun" package). I tried to, quickly, reproduce the problem but got slightly different results based on the following example:
file_1.md:

The first file

# Upcoming breaking changes

file_2.md:

The second file

- [Upcoming breaking changes](#upcoming-breaking-changes)


# Upcoming breaking changes

Here we don't get any warnings but we don't jump to the right place but in the original example we get:

README.md:96: warning: unable to resolve reference to 'upcoming-breaking-changes' for \ref command
README.md:174: warning: unable to resolve reference to 'bundns---lookup-a-domain' for \ref command
README.md:219: warning: unable to resolve reference to 'prefer-latest' for \ref command

so again warnings (there are more warnings here but they are not really relevant for the case here).

As far as I can tell the problem arises from the fact that in GitHub the labels just have to be unique inside a file (and subsequent numbering is done just inside the file) whilst for doxygen the labels have to be globally unique.

Also in doxygen it is possible that a label is referred outside the file where it is defined but with GitHub this is not the case.

This is a hard problem, but probably an approach where the file name + path is incorporated into the label has to be chosen so that the labels remain unique over files and can be numbered inside the file.
The "mangling" probably has to be done at the place where the label is defined and used.

Note that the internal used labels have to be unique inside doxygen and that the translation from GitHub mangled labels to doxygen labels has to be done but that the translation the other way around is not necessary.

Small example: example_small.tar.gz
Original example: example.tar.gz

tim-gromeyer · 2023-02-26T17:44:08Z

Also in doxygen it is possible that a label is referred outside the file where it is defined but with GitHub this is not the case.

If I have understood you correctly, this is not quite right, see https://github.com/tim-gromeyer/stackoverflow/blob/tests/README.md

This is a hard problem, but probably an approach where the file name + path is incorporated into the label has to be chosen so that the labels remain unique over files and can be numbered inside the file. The "mangling" probably has to be done at the place where the label is defined and used.

This is indeed a difficult problem. Too difficult for me to solve it, because of the complexity of doxygen. But I think you are right. With the combination of the relative path and the filename it should be possible.

Note that the internal used labels have to be unique inside doxygen and that the translation from GitHub mangled labels to doxygen labels has to be done but that the translation the other way around is not necessary.

albert-github · 2023-02-27T09:16:22Z

Regarding the number problem I now also found a problem regarding a minus sign at the beginning, in fact the line:

### * tools/matchcompiler.py

translates into:

@subsection -toolsmatchcompilerpy * tools/matchcompiler.py

which is a correct translation, but doxygen does not like the - at the beginning of a label which results in:

cppcheck-2.10.2/tools/readme.md:3: warning: Invalid or missing section label

(Found by Fossies in the cppcheck 2.10.2 package)

tim-gromeyer · 2023-02-27T14:12:36Z

which is a correct translation, but doxygen does not like the - at the beginning of a label which results in:

Why does doxygen not like the - at the beginning? Is it some kind of validation that only valid identifiers are included? If so, we could skip checking in GitHub mode, since GitHub obviously doesn't care about XHTML and HTML4.

albert-github · 2023-02-27T14:16:26Z

The - is probably also not allowed in HTML4 and XHTML as the beginning of a label.

we could skip checking in GitHub mode, since GitHub obviously doesn't care about XHTML and HTML4.

But doxygen does care about XHTML and HTML4 as doxygen documentation is normally not read on GitHub but in a browser.

tim-gromeyer · 2023-02-27T14:36:36Z

The - is probably also not allowed in HTML4 and XHTML as the beginning of a label.

This might be true but the GitHub id mangling is HTML5 only. This should definitely be noted in the documentation.

But doxygen does care about XHTML and HTML4 as doxygen documentation is normally not read on GitHub but in a browser.

Yes, that's true, but can you name me a browser that doesn't support HTML5. That was an issue 8 years or so ago, but not anymore.

doxygen · 2023-02-27T21:10:16Z

I think it is a matter of defining the purpose of MARKDOWN_ID_STYLE=GITHUB.
If it is to

allow hand written GitHub pages to be (also) processed as-is by doxygen
allow cross-references between hand written pages and doxygen generated pages.

Then doxygen should not alter the anchors and links, support leading -s and digits, and also treat each page as a unique namespaces (at least for HTML). The consequence is then to only support HTML5, and when HTML4 or XHTML compliance is needed the user should switch back to the default MARKDOWN_ID_STYLE=DOXYGEN.

tim-gromeyer · 2023-02-27T21:28:34Z

I think it is a matter of defining the purpose of MARKDOWN_ID_STYLE=GITHUB. If it is to

allow hand written GitHub pages to be (also) processed as-is by doxygen

allow cross-references between hand written pages and doxygen generated pages.

I think both, at least partially.

Then doxygen should not alter the anchors and links, support leading -s and digits, and also treat each page as a unique namespaces (at least for HTML).

That sounds like a solution, a complex one.

The consequence is then to only support HTML5, and when HTML4 or XHTML compliance is needed the user should switch back to the default MARKDOWN_ID_STYLE=DOXYGEN.

That's exactly what I was trying to say!

albert-github · 2023-02-28T09:19:02Z

I think the purpose would be to: allow hand written GitHub pages to be (also) processed by doxygen. I explicitly left out the words "as-is".
I think doxygen should:

take the # page / section / ... lines and translate (as done now under MARKDOWN_ID_STYLE=GITHUB) to a label. In case the resulting label starts with a digit or a - sign the generated label should be prepended by a reserved word (like autotoc_md).
take the lines like [...](...) (as this is how GitHub refers to sections etc. where the part between ( and )is taken and when it starts with a # it is stripped away (might be more than one, I saw it once so far but I think this is actually a typo in the code but it works) and when the remaining string (i.e. the label) starts with a digit or a - sign the label should be prepended by the reserved word

I think in this way the labels will work in all of HTML4, HTML5 and XHTML. Not doing this will limit the usability quite a bit.

tim-gromeyer · 2023-03-01T08:10:14Z

This sounds like a good idea, and if I can help implement it, I'll give it a try.

Based on the comment doxygen#9858 (comment): ``` take the # page / section / ... lines and translate (as done now under MARKDOWN_ID_STYLE=GITHUB) to a label. In case the resulting label starts with a digit or a - sign the generated label should be prepended by a reserved word (like autotoc_md). take the lines like [...](...) (as this is how GitHub refers to sections etc. where the part between ( and )is taken and when it starts with a # it is stripped away (might be more than one, I saw it once so far but I think this is actually a typo in the code but it works) and when the remaining string (i.e. the label) starts with a digit or a - sign the label should be prepended by the reserved word ``` this feature has been implemented.

albert-github · 2023-03-01T10:09:04Z

Based on the ideas as given in #9858 (comment) github labels staring with a digit of - I implemented it in the proposed patch, pull request #9888

tim-gromeyer changed the title ~~Markdown: Change default title id~~ WIP: Markdown: Change default title id Feb 14, 2023

tim-gromeyer changed the title ~~WIP: Markdown: Change default title id~~ WIP: Markdown: Heading auto id Feb 17, 2023

doxygen reviewed Feb 17, 2023

View reviewed changes

tim-gromeyer force-pushed the markdown-title-identifier branch from 0e3f8bb to e16ce96 Compare February 17, 2023 21:30

albert-github reviewed Feb 18, 2023

View reviewed changes

tim-gromeyer force-pushed the markdown-title-identifier branch 2 times, most recently from d6cb80f to 1b45cae Compare February 18, 2023 21:07

tim-gromeyer force-pushed the markdown-title-identifier branch 2 times, most recently from 4b932a2 to ee6f48c Compare February 19, 2023 18:26

albert-github added the fixed but not released Bug is fixed in github, but still needs to make its way to an official release label Feb 23, 2023

albert-github mentioned this pull request Mar 1, 2023

issue 9855 Markdown: Heading auto id starting with digit of minus sign #9888

Merged

doxygen removed the fixed but not released Bug is fixed in github, but still needs to make its way to an official release label May 18, 2023

		if (!m_impl->sectionRefs.empty()) {
		//printf("%s: writeDocAnchorsToTagFile(%d)\n",qPrint(name()),m_impl->sectionRef.size());

Markdown: Heading auto id #9858

Markdown: Heading auto id #9858

Conversation

tim-gromeyer commented Feb 14, 2023 • edited Loading

albert-github commented Feb 14, 2023

tim-gromeyer commented Feb 14, 2023 • edited by albert-github Loading

tim-gromeyer commented Feb 14, 2023 • edited Loading

albert-github commented Feb 15, 2023

albert-github commented Feb 15, 2023

tim-gromeyer commented Feb 15, 2023

tim-gromeyer commented Feb 15, 2023

albert-github commented Feb 16, 2023

tim-gromeyer commented Feb 16, 2023

albert-github commented Feb 16, 2023

tim-gromeyer commented Feb 16, 2023 • edited Loading

albert-github commented Feb 16, 2023

tim-gromeyer commented Feb 16, 2023

tim-gromeyer commented Feb 17, 2023

tim-gromeyer commented Feb 17, 2023

doxygen commented Feb 17, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tim-gromeyer commented Feb 17, 2023

tim-gromeyer commented Feb 17, 2023

tim-gromeyer commented Feb 17, 2023

albert-github left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tim-gromeyer Feb 19, 2023 • edited by albert-github Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tim-gromeyer commented Feb 18, 2023 • edited Loading

tim-gromeyer commented Feb 18, 2023

tim-gromeyer commented Feb 23, 2023

albert-github commented Feb 23, 2023

tim-gromeyer commented Feb 23, 2023

tim-gromeyer commented Feb 23, 2023

doxygen commented Feb 23, 2023

tim-gromeyer commented Feb 23, 2023

albert-github commented Feb 25, 2023

albert-github commented Feb 25, 2023 • edited Loading

tim-gromeyer commented Feb 25, 2023

doxygen commented Feb 26, 2023

albert-github commented Feb 26, 2023

albert-github commented Feb 26, 2023

tim-gromeyer commented Feb 26, 2023

albert-github commented Feb 26, 2023

tim-gromeyer commented Feb 26, 2023

albert-github commented Feb 26, 2023

tim-gromeyer commented Feb 26, 2023

albert-github commented Feb 27, 2023

tim-gromeyer commented Feb 27, 2023

albert-github commented Feb 27, 2023

tim-gromeyer commented Feb 27, 2023

doxygen commented Feb 27, 2023

tim-gromeyer commented Feb 27, 2023

albert-github commented Feb 28, 2023

tim-gromeyer commented Mar 1, 2023

albert-github commented Mar 1, 2023

tim-gromeyer commented Feb 14, 2023 •

edited

Loading

tim-gromeyer commented Feb 14, 2023 •

edited by albert-github

Loading

tim-gromeyer commented Feb 14, 2023 •

edited

Loading

tim-gromeyer commented Feb 16, 2023 •

edited

Loading

tim-gromeyer Feb 19, 2023 •

edited by albert-github

Loading

tim-gromeyer commented Feb 18, 2023 •

edited

Loading

albert-github commented Feb 25, 2023 •

edited

Loading