Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Text after list is part of list incorrectly in API reference #1951

Closed
svick opened this issue Apr 18, 2017 · 3 comments
Closed

Text after list is part of list incorrectly in API reference #1951

svick opened this issue Apr 18, 2017 · 3 comments
Assignees
Milestone

Comments

@svick
Copy link
Contributor

svick commented Apr 18, 2017

It seems that when API reference remarks were imported, all plain lines (i.e. those not part of a list, a blockquote or a heading) had a single leading space added. The problem with this is that when such a line is right after a list, it is considered part of the last item of the list in markdown.

Consider MuxLogger (MSDN, docs.ms, source):

  • The lines "The MuxLogger registers loggers in the following way:" and "The MuxLogger unregisters loggers in the following way:" are indented by one space, which causes them to be incorrectly considered part of the preceding list.
  • Lines like "Any loggers registered before the build manager starts the build get the build-started event at the same time as the MuxLogger." are indented by 5 spaces and are correctly considered part of the preceding list. Changing the indentation to 4 spaces would not cause any issue.

I already have two PRs that deal with this issue (#1893, #1948), but it's so pervasive that I think a more global solution is needed.

My questions:

  • Is this something worth fixing globally (considering it would change many files at once)?
  • Should the indentation be fixed everywhere, or only where it causes an issue?
  • Would a PR by me be welcome, or do you have a better way to deal with this?
  • Would it make sense to fix other issues at the same time? If so, which ones?

I have also created a PR showing one possible solution: #1952.

@mairaw
Copy link
Contributor

mairaw commented Apr 24, 2017

The engineering team has given us a different solution for us to try. I'll open a new PR to see the results and we can compare.

@mairaw
Copy link
Contributor

mairaw commented May 2, 2017

My PR seemed to resolve the issue. Ok to close this @svick?

@svick
Copy link
Contributor Author

svick commented May 2, 2017

Yeah, closing this issue and the PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants