Mono bent complex update of header, and extension of string parsing system

[Lomholy]

Free-form text area

Please describe what your PR is adding in terms of features or bugfixes:

Monochromator_bent_complex is updated regarding the changes to the parameter "plane_of_reflections". This is reflected in updates to the header as well. Other minor beauty changes are performed in the header.

The plane_of_reflection parameter could previously only be a string of planes, delimited by a semicolon between each plane. With this update, the option of having a single plane of reflection for all crystals is added. E.g. a three crystal definition of "Si111;Si111;Si111" can now be defined by "Si111".

---

Development OS / boundary conditions

Please describe what OS you developed and tested your additions on, and if any special dependencies are required:
MacOS Tahoe 26.2

---

PR Checklist for contributing to McStas/McXtrace

For a coherent and useful contribution to McStas/McXtrace, please fill in relevant parts of the checklist:

• My contribution includes patches to an existing component file

  • I have used the mcdoc utility and rendered a reasonable documentation page for the component (please attach as screenshot in comments!)
  • I have ensured that basic use of the component is OK (e.g. an instrument using it compiles?)
  • I have used the mctest utility to test one or more instruments making use of the component (please attach mcviewtest report as screenshot in comments)
  • I have used the mccode-clangformat tool to apply the standard McCode component indentation scheme
  • I have used the mcrun --c-lint "linter" and followed advice to remove most / all warnings that are raised

• My contribution includes patches to an existing instrument file

  • I have used the mcdoc utility and rendered a reasonable documentation page for the instrument (please attach as screenshot in comments!)
  • I have used the mctest utility to test the instrument (please attach mcviewtest report as screenshot in comments)
  • I have used the mcrun --c-lint "linter" and followed advice to remove most / all warnings that are raised

---

[willend]

@Lomholy mcdoc is not tolerant to all character sets. For best possible mileage you should use W3 / html specification of e.g. Greek characters such as $\mu$ and other non-ascii things like Š.

I’ve fixed it for you this time round - but this is one of the reasons that I insist on adding screenshots of mcdoc pages in the PR template… :-) (Hint to actually look at that mcdoc page…)

Also, I think the PR descriptive text above is mostly meaningful to yourself…

Is this one otherwise ready in your own view?

[willend]

[Lomholy]

mcdoc is not tolerant to all character sets. For best possible mileage you should use W3 / html specification of e.g. Greek characters such as μ and other non-ascii things like Š.

I’ve fixed it for you this time round - but this is one of the reasons that I insist on adding screenshots of mcdoc pages in the PR template… :-) (Hint to actually look at that mcdoc page…)

Hi @willend, Thank you for the help. I was wondering how I should write greek characters, and other non-standard characters.

This has illustrated your point with screenshots quite clearly - Will make sure to include them from now on :-).

Also, I think the PR descriptive text above is mostly meaningful to yourself…

The text on the PR has been updated - is it clearer now? I am still practicing the discipling of making clear PR texts ;)

Is this one otherwise ready in your own view?

Yes, with this one caveat...
I realised that my implementation might not work for some edge cases (When the planes_of_reflection identifiers are longer than 6 characters, of which only few are) - but I think this will be mentioned in an issue instead, and then I will address it in a separate PR, since I don't really have the time to look at it currently...

[willend]

Yes, with this one caveat...
I realised that my implementation might not work for some edge cases (When the planes_of_reflection identifiers are longer than 6 characters, of which only few are) - but I think this will be mentioned in an issue instead, and then I will address it in a separate PR, since I don't really have the time to look at it currently…

OK, I see. Then there are two options for the road ahead:

1. Let this PR ‘hang’ until you have time to address the suspected issue
2. Modify your code to error if you are in such an edge-case and add the related issue

Either way I want to avoid merging code with known (but not documented) issues. :)

[Lomholy]

Alright, then lets let it hang. I believe that I will have time within a month or so

[willend]

You might consider periodically updating the PR branch against main if time allows?

[Lomholy]

Will do!