[next] Horizontal Divider

[lorenzolewis]

When we have a module on one single page, the horizontal dividers could become repetitive (especially for shorter definitions). This gives a global option to disable the horizontal divider.

[tgreyuk]

Thanks. It might be that we just get rid of the dividers by default and make it easy for people to customise by overriding templates. I'll have a look. - I think we want to avoid having too many ui options.

[lorenzolewis]

What do you have in mind for allowing overriding templates? I'm doing some overrides on the some comment tags (to handle a custom @history and @SInCE rendering) so might be able to help out with testing and feedback on that if you'd like.

[tgreyuk]

What do you have in mind for allowing overriding templates?

Basically by overrding templates and partials in the theme context. Basically following the pattern of the defualt html theme. https://github.com/TypeStrong/typedoc/blob/master/internal-docs/custom-themes.md. I'll add an examples to the dir directory

I'm doing some overrides on the some comment tags

Interesting. Are you planning on hooking into converter event? I actually wrote a small plugin that hooked into a comment annotation that might be of interest. https://github.com/tgreyuk/typedoc-plugin-inline-sources

[lorenzolewis]

I've never looked into the actual TypeDoc events and how they all work, so I might have a read through and see. I was waiting for this project to get to a point that's a bit more stable with v4 and to get a better idea of things you'd like to have part of this, vs. things I need to build out as actual extensions.

If you have a main v4 issue you'd be open to tracking on I'd be happy to help any additional things there. A few I have are:

• Code block indentions (>) for member titles, signature titles, any others as required. I think this is currently an option in v3
• Horizontal divider per this PR
• For "Implementation of", "Inherited from", "Overrides", "Defined in", "Returns", and any others, if there is only one entry for a specific category, render it as "Defined in: file.ext:line:col" on one single line instead of a heading of "Defined in" and then the "file.ext:line:col" on a separate line below it. Again, for large pages it makes the page formatting a bit nicer. An example is below for "Defined in".
• For Enum kind children of a member, add an option to render it as a table

Let me know if any of those you'd be interested in having as part of this and I can throw a PR together

[tgreyuk]

All sounds reasonable. I'll get the next branch merged and then open a new general v4 issue, or perhaps track this stuff via a new GitHub discussion.

[lorenzolewis]

All sounds reasonable. I'll get the next branch merged and then open a new general v4 issue, or perhaps track this stuff via a new GitHub discussion.

Sounds awesome, give me a shout if you need anything!

[tgreyuk]

Have updated next branch with a couple of tweaks and fixed the tests so you are good to carry on. The next thing i will do is look at setting up the alpha release, even though we are quite far off, it would be good to just to get the process going.

As per previous comments:

Code block indentions (>) for member titles, signature titles, any others as required. I think this is currently an option in v3

I've added something around this in latest push but let me know if you have other ideas.

For "Implementation of", "Inherited from", "Overrides", "Defined in", "Returns", and any others, if there is only one entry for a specific category, render it as "Defined in: file.ext:line:col" on one single line instead of a heading of "Defined in" and then the "file.ext:line:col" on a separate line below it. Again, for large pages it makes the page formatting a bit nicer. An example is below for "Defined in".

Agree sounds good if you have an PR for this that would be good.

For Enum kind children of a member, add an option to render it as a table

I have some ideas on this too, ideally i'd like to expose the ability to display params / properties of any symbol as either a list or table style. Unless you have something concrete, hold off on this and I will get some ideas together to discuss.

I have started a discussion which i thought could potentially be a good place to continue the conversation. #372 .