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

Do not break long urls in comments. #506

Closed
malbarbo opened this issue Oct 20, 2015 · 13 comments
Closed

Do not break long urls in comments. #506

malbarbo opened this issue Oct 20, 2015 · 13 comments
Labels
a-comments only-with-option requires a non-default option value to reproduce poor-formatting

Comments

@malbarbo
Copy link
Contributor

// https://github.com/rust-lang/rfcs/blob/master/text/0195-associated-items.md#encoding-higher-kinded-types

is format to this

// https://github.com/rust-lang/rfcs/blob/master/text/0195-associated-items.
// md#encoding-higher-kinded-types
@marcusklaas
Copy link
Contributor

What should we do with such comments?

@malbarbo
Copy link
Contributor Author

Leave it as it is. Break a url is bad because we cannot click it anymore...

@nrc
Copy link
Member

nrc commented Oct 20, 2015

We could try to break before the URL, if we are into breaking comments, otherwise leave as is.

@nrc nrc added the bug Panic, non-idempotency, invalid code, etc. label Oct 20, 2015
@chriskrycho
Copy link

Note that this also breaks in the case of the (style-guide-recommended) reference-style link, so this:

/// Here's a snippet talking about [higher-kinded types][1]. We might go on...

[1]: https://github.com/rust-lang/rfcs/blob/master/text/0195-associated-items.md#encoding-higher-kinded-types

becomes this:

/// Here's a snippet talking about [higher-kinded types][1]. We might go on...
///
/// [1]: https://github.com/rust-lang/rfcs/blob/master/text/0195-associated-
/// items.md#encoding-higher-kinded-types

I think the best solution is:

  • break before inline URLs if line-wrapping in comments of whatever variety
  • avoid wrapping at all in reference-style links

@hauleth
Copy link

hauleth commented Nov 7, 2015

There should be no breakings in reference-style links as this brakes formatting also:

/// Here's a snippet talking about [higher-kinded types][1]. We might go on...
///
/// [1]: https://short.example.link/ "Long description that will appear in hover on the link, this often contain description of page that is linked"

becomes this:

/// Here's a snippet talking about [higher-kinded types][1]. We might go on...
///
/// [1]: https://short.example.link/ "Long description that will appear in hover
/// on the link, this often contain description of page that is linked"

@nrc
Copy link
Member

nrc commented Apr 6, 2016

This gets left as is by default, but the bug still exists if we turn on comment formatting

@nrc nrc removed the bug Panic, non-idempotency, invalid code, etc. label Apr 6, 2016
@marcusklaas
Copy link
Contributor

Closed by #911.

@gnzlbg
Copy link
Contributor

gnzlbg commented Aug 2, 2016

When calling rustfmt on a file with:

//! For a quick overview see
//! [wikipedia](https://en.wikipedia.org/wiki/Bit_Manipulation_Instruction_Sets#BMI1_.28Bit_Manipulation_Instruction_Set_1.29).
//! The reference is [Intel 64 and IA-32 Architectures Software Developer's
//! Manual Volume 2: Instruction Set Reference,
//! A-Z](http://www.intel.de/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf).
//!

I get errors of the form:

Rustfmt failed at ...: line exceeded maximum length (sorry)
Rustfmt failed at ...: line exceeded maximum length (sorry)

Is this normal? Seems related to this issue but this issue is closed.

@gnzlbg
Copy link
Contributor

gnzlbg commented Aug 2, 2016

It also seems to fail when an URL is in a list in a comment. For example here:

/// # Intrinsic (when available BMI1)
///
/// - [`BEXTR`](http://www.felixcloutier.com/x86/BEXTR.html): Bit field extract (supports 32/64 bit registers).
///

That could be formatted to something like

/// # Intrinsic (when available BMI1)
///
/// - [`BEXTR`](http://www.felixcloutier.com/x86/BEXTR.html): Bit field 
///   extract (supports 32/64 bit registers).
///

@stouset
Copy link

stouset commented Oct 22, 2016

I don't think #911 fixes this, because you split on punctuation.

As an example, the following:

/// See the [https://download.libsodium.org/doc/helpers/memory_management.html#guarded-heap-allocations](libsodium)
/// documentation for all of the security guarantees provided by this
/// function.

is converted to:

/// See the [https://download.libsodium.
/// org/doc/helpers/memory_management.
/// html#guarded-heap-allocations](libsodium)
/// documentation for all of the security guarantees provided by this
/// function.

@nrc nrc reopened this Oct 24, 2016
@nrc nrc added the only-with-option requires a non-default option value to reproduce label Jan 16, 2017
@gnzlbg
Copy link
Contributor

gnzlbg commented Sep 28, 2017

Related: steveklabnik/rustdoc#178

Technically, markdown can handle URLs split over multiple lines, so rustfmt should actually follow markdown URL splitting style. rustdoc cannot currently handle this, but once that is fixed, this could be fixed too...


@malbarbo

Leave it as it is. Break a url is bad because we cannot click it anymore...

Why can't you click it anymore? Your editor should know that in Rust mode comments follow markdown, and thus recognize an URL even when its split across multiple line as long as the split follows markdown style.

@topecongiro
Copy link
Contributor

Triage: rustfmt no longer splits comments with URLs.

@detly
Copy link

detly commented Dec 18, 2022

@gnzlbg Do you have a source for this?

Technically, markdown can handle URLs split over multiple lines, so rustfmt should actually follow markdown URL splitting style.

I can't find anything about URL breaking in the original, or any of the popular, markdown "specs". It would be very useful in producing test material for related issues.

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

No branches or pull requests

9 participants