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

wrap_comments breaks markdown formatting #627

Closed
mrmonday opened this issue Nov 18, 2015 · 5 comments · Fixed by #3083
Closed

wrap_comments breaks markdown formatting #627

mrmonday opened this issue Nov 18, 2015 · 5 comments · Fixed by #3083
Labels
a-comments only-with-option requires a non-default option value to reproduce poor-formatting

Comments

@mrmonday
Copy link

Given the following:

//! This is a list:
//!  * Outer
//!  * Outer
//!   * Inner
//!   * Inner with lots of text so that it could be reformatted something something something
fn main() {
}

rustfmt, with wrap_comments set to true, is reformatted as:

//! This is a list:
//!  * Outer
//!  * Outer
//!   * Inner
//! * Inner with lots of text so that it could be reformatted something
//! something something
fn main() {
}

Notice that the inner bullet point is no longer part of either list.

@mrmonday
Copy link
Author

I also encountered similar problems for code blocks within comments - I haven't reported a separate bug - should I?

@nrc
Copy link
Member

nrc commented Nov 18, 2015

There is already an issue for broken code blocks in comments. We have a lot of problems with comments right now :-(

@nrc nrc added the only-with-option requires a non-default option value to reproduce label Jan 16, 2017
@daboross
Copy link
Contributor

Another test case:

//! This example shows how to configure fern to output really nicely colored logs
//! - when the log level is error, the whole line is red
//! - when the log level is warn, the whole line is yellow
//! - when the log level is info, the level name is green and the rest of the line is white
//! - when the log level is debug, the whole line is white
//! - when the log level is trace, the whole line is gray ("bright black")

is reformatted as

//! This example shows how to configure fern to output really nicely colored
//! logs - when the log level is error, the whole line is red
//! - when the log level is warn, the whole line is yellow
//! - when the log level is info, the level name is green and the rest of the
//! line is white - when the log level is debug, the whole line is white
//! - when the log level is trace, the whole line is gray ("bright black")

completely breaking the list (it no longer even resembles a list).

(diff output)
-//! This example shows how to configure fern to output really nicely colored logs⏎
-//! - when the log level is error, the whole line is red⏎
+//! This example shows how to configure fern to output really nicely colored⏎
+//! logs - when the log level is error, the whole line is red⏎
 //! - when the log level is warn, the whole line is yellow⏎
-//! - when the log level is info, the level name is green and the rest of the line is white⏎
-//! - when the log level is debug, the whole line is white⏎
+//! - when the log level is info, the level name is green and the rest of the⏎
+//! line is white - when the log level is debug, the whole line is white⏎
 //! - when the log level is trace, the whole line is gray ("bright black")⏎

@Ekleog
Copy link

Ekleog commented Sep 13, 2018

With rustfmt 0.99.2-nightly (5c9a2b6 2018-08-07), getting the following diff:

 ///
-/// All the parameters ***except for `from_theater`*** should be inserted as sent by the remote
-/// theater, ie. as passed to [`Theater::send`] on the remote actor:
-///  * `from` is the sending (remote) [`ActorId`], as reported by the remote theater by theater-specific means
-///  * `to` is the receiving (local) [`ActorId`], as requested by the remote theater
-///  * `tag` is a tag that identifies the message type
-///  * `msg` is the (serialized) message
+/// All the parameters ***except for `from_theater`*** should be inserted as
+/// sent by the remote theater, ie. as passed to [`Theater::send`] on the
+/// remote actor:  * `from` is the sending (remote) [`ActorId`], as reported by
+/// the remote theater by theater-specific means  * `to` is the receiving
+/// (local) [`ActorId`], as
+/// requested by the remote theater  * `tag` is a tag that identifies the
+/// message type  * `msg` is the (serialized) message
 ///

Ekleog added a commit to Ekleog/erlust that referenced this issue Sep 13, 2018
Rustfmt currently cannot handle markdown in comments, cf. [1]. As a
consequence, the itemized list in inject would be broken by it.

[1] rust-lang/rustfmt#627
@scampi
Copy link
Contributor

scampi commented Oct 2, 2018

Maybe what could be done is to recognise lines with a leading itemization marker (* or -), which indicates that the line indent should be kept. The line can then be wrapped, taking into account the indent of the item.

Below is an example of what that could look like:

-/// All the parameters ***except for `from_theater`*** should be inserted as sent by the remote
-/// theater, ie. as passed to [`Theater::send`] on the remote actor:
-///  * `from` is the sending (remote) [`ActorId`], as reported by the remote theater by theater-specific means
-///  * `to` is the receiving (local) [`ActorId`], as requested by the remote theater
+/// All the parameters ***except for `from_theater`*** should be inserted as
+/// sent by the remote theater, ie. as passed to [`Theater::send`] on the remote
+/// actor:
+///  * `from` is the sending (remote) [`ActorId`], as reported by the remote
+///    theater by theater-specific means
+///  * `to` is the receiving (local) [`ActorId`], as requested by the remote
+///    theater
 ///  * `tag` is a tag that identifies the message type
 ///  * `msg` is the (serialized) message

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a-comments only-with-option requires a non-default option value to reproduce poor-formatting
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants