fix: Don't strip new lines in dhautofunction

[jnumainville]

No longer removes newlines, residual from before we were using a table and they were messing with the formatting I believe

[dsmmcken]

That's not automatically going to fix it. HTML will ignore those new lines unless we preserve spaces.

You are already inserting it into the doc, which WILL preserve new lines as markdown.

I would just pull the description and returns parts from inside the and insert them directly above.

<insert description if exists> This will be treated as markdown here, so even links and stuff would work.

**Returns: ** <insert returns if exists>

<Paramtable withoth those two things/>

[jnumainville]

would that give you less control though if we wanted to change things?
and what about new lines within the parameters?

[dsmmcken]

It's still under "our" control, so it would be fine.

Are new lines in the parameters valid docstrings?

[jnumainville]

I wasn't precise - it doesn't give less control overall, it splits a task into two parts, giving less control in the next step after this script.
I see this step as take code -> output processed data that can be used to build the presentation layer.
So doing part of the processing for the presentation layer is creating a poorer abstraction by mixing concerns, and if we want to change both the format of, for example, the returns block and the parameters table, that's now done in two different spots.
If there's something I can do to make the new lines easier to process in the presentation layer building, that makes sense, but ideally it's still data.

New lines in the docstring parameters are valid

[dsmmcken]

That's the easiest way to get full md support in descriptions. You are inserting into the presentation layer.

inserting

{result.description}

*Returns:( {result.returns}

<ParamTable restults={results dict} />

doesn't seem that different to me.

and um. actually description and returns aren't params anyways.

[jnumainville]

My point is, currently, ParamTable handles all of the actual presentation.
ParamTable is meaningless without the presentation layer.
The suggested change would make it so some presentation is handled here, some presentation is handled elsewhere.
You are right in that it isn't much different, but it is an architectural difference, and I don't think the optimal change to make, because it adds overall complexity to the boundary, even if "easier" to do now.
But, if that's the direction we want to go, it's what I'll do.

My concern about newlines in params still remains.
See this example to clarify (note that in the code I've got in this PR there is a subtle regex bug currently, but below is what the parameters will look like)
{"name": "by", "type": "str | list[str] | None", "description": "A column or list of columns that contain values to plot the figure traces by.\nAll values or combination of values map to a unique design. The variable\nby_vars specifies which design elements are used.\nThis is overriden if any specialized design variables such as color are specified", "default": "None"}

[dsmmcken]

Embed it please. I acknowledge it's less ideal on your side. However it will be more performant on the front end as it avoids having the user waiting for it to be parsed.

[dsmmcken]

Are these
actually inserted in output?"

If so, it's markdown, new lines are respected.

Also should this output be conditional? If no return type or no description?

[dsmmcken]

I would expect output that looks more like this.

[jnumainville]

If you mean \n are respected they are not at least in this case. This is inserting a raw string (which is has to do because otherwise sphinx tries to escape characters it shouldn't) so it writes a raw \n, it doesn't create a new line.

Currently return_type and return_description are required. This can change but will require a bit more rework than just here.

[jnumainville]

I'll see if I can replace those <br /> with a different sort of new line in the post processing, but ideally I don't want actual markdown new lines until then because it makes the processing harder than it needs to be

[jnumainville]

done, that seems to have the needed output