fix README table

[pratyush3757]

The feature table was broken and had description coming into feature column

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[ghost]

This change still does not fix this issue, as a single line is being split into more than one rows.

[ghost]

This can be fixed if we do not split a single line into multiple lines in the markdown code, as shown below:

| Feature                      | Description                                                                                                                                                             |
|------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| xUnit test framework         | GoogleTest is based on the [xUnit](https://en.wikipedia.org/wiki/XUnit) testing framework, a popular architecture for unit testing.                                     |
| Test discovery               | GoogleTest automatically discovers and runs your tests, eliminating the need to manually register your tests.                                                           |
| Rich set of assertions       | GoogleTest provides a variety of assertions, such as equality, inequality, exceptions, and more, making it easy to test your code.                                      |
| User-defined assertions      | You can define your own assertions with Googletest, making it simple to write tests that are specific to your code.                                                     |
| Death tests                  | GoogleTest supports death tests, which verify that your code exits in a certain way, making it useful for testing error-handling code.                                  |
| Fatal and non-fatal failures | You can specify whether a test failure should be treated as fatal or non-fatal with Googletest, allowing tests to continue running even if a failure occurs.            |
| Value-parameterized tests    | GoogleTest supports value-parameterized tests, which run multiple times with different input values, making it useful for testing functions that take different inputs. |
| Type-parameterized tests     | GoogleTest also supports type-parameterized tests, which run with different data types, making it useful for testing functions that work with different data types.     |
| Various options for running  | GoogleTest provides many options for running tests, including running individual tests, running tests in a specific order, and running tests in parallel.               |

Preview of the above table

Feature	Description
xUnit test framework	GoogleTest is based on the xUnit testing framework, a popular architecture for unit testing.
Test discovery	GoogleTest automatically discovers and runs your tests, eliminating the need to manually register your tests.
Rich set of assertions	GoogleTest provides a variety of assertions, such as equality, inequality, exceptions, and more, making it easy to test your code.
User-defined assertions	You can define your own assertions with Googletest, making it simple to write tests that are specific to your code.
Death tests	GoogleTest supports death tests, which verify that your code exits in a certain way, making it useful for testing error-handling code.
Fatal and non-fatal failures	You can specify whether a test failure should be treated as fatal or non-fatal with Googletest, allowing tests to continue running even if a failure occurs.
Value-parameterized tests	GoogleTest supports value-parameterized tests, which run multiple times with different input values, making it useful for testing functions that take different inputs.
Type-parameterized tests	GoogleTest also supports type-parameterized tests, which run with different data types, making it useful for testing functions that work with different data types.
Various options for running	GoogleTest provides many options for running tests, including running individual tests, running tests in a specific order, and running tests in parallel.

[pratyush3757]

@Rahul-Dixit

This can be fixed if we do not split a single line into multiple lines in the markdown code,

The thing is, this was the actual change which was done by the previous contributor in #4231
but the commit 60c3602 that was merged had the long lines wrapped around. Maybe it was formatted during CI.

And I couldn't find a way to make multi-line rows in raw md map to a single cell.

[ghost]

@Rahul-Dixit

This can be fixed if we do not split a single line into multiple lines in the markdown code,

The thing is, this was the actual change which was done by the previous contributor in #4231 but the commit 60c3602 that was merged had the long lines wrapped around. Maybe it was formatted during CI.

And I couldn't find a way to make multi-line rows in raw md map to a single cell.

@pratyush3757 I am not sure what caused it to happen. But since it is not possible to wrap long lines in markdown code (at least in GitHub Flavored Markdown), this is the only way to fix this issue. See this.

Additional References

1. Wrap long lines in markdown tables – Stack Overflow
2. Tables (extension) – GitHub Flavored Markdown

[pratyush3757]

@Rahul-Dixit
None of the sources you have linked provide a solution for raw github flavored markdown.

1. Markdown table with long lines - SO
   The answers tell to indent the markdown table delimiters for better raw text readability, or to use HTML for better parsing.
2. Wrap long lines in markdown tables – Stack Overflow
   The answer notes that the syntax does not offer any way to define when one row ends and another row begins for github flavored markdown.
3. Tables (extension) – GitHub Flavored Markdown
   There's no mention of multi-line tables.

As for what caused it to happen, it's probably a formatting step done in the CI pipeline before merge. So even if I do what you suggested previously, it'd be mangled during the merge again. Most formatting rules have a line length limit (often 80 characters).

I could, however, avoid a table altogether and make it a nested list.

[ghost]

@Rahul-Dixit
None of the sources you have linked provide a solution for raw github flavored markdown.

Because it isn't possible to achieve that using GitHub Flavored Markdown, and I made it clear in my last comment.

I could, however, avoid a table altogether and make it a nested list.

Yes, these alternatives may be used.

[dinord]

This was caused by internal auto-formatting when we imported the original change. I don't think a table is particularly useful here to justify maintaining any workaround. This PR looks good to me.