The "no-irregular-whitespace" rule prevents proper typography in comments outside English.

[tdd]

Hey there,

So I moved to Standard, and am advocating it. It finally got me to jump ship on semicolons, and I use this despite the "space before function decl/expr opening parens" rule, which I find fugly.

So thanks a ton for this cool tool!

But… The no-irregular-whitespace rule is messing with my comments. I'm a trainer among other things, and many of my codebases are for teaching purposes, with my audience being mostly French. In French, double punctuation marks (;, :, ! and ?) take a non-breakable space before them. French quotes (« and ») also use such spaces inside them.

But because of this rule, I can't use such spaces in my comment texts. So either I collapse these spaces, which looks and feels very weird to any French reader, or I use regular spaces, with the virtual guarantee that at least some of these will get wrapped at the beginning of lines in annotated code, looking terrible.

Isn't there a way to relax this rule for comment text? I can't find this relaxing mode in ESLint, but perhaps you know of a way? I get the rule inside code (and btw, it's relaxed within String literals), but inside comments? Who gives a damn?

Best,

[LinusU]

despite the "space before function decl/expr opening parens" rule, which I find fugly.

One very nice thing is that you can search your codebase for the definition of the function by searching for name (

Can you show an example of something that breaks? The following works for me:

// hello ; world

[feross]

@LinusU I think he's discussing special whitespace, like the non-breaking space character.   from HTML, if you've seen that. It's basically whitespace that's not the normal space character. Special characters that you can't see...

[feross]

or I use regular spaces, with the virtual guarantee that at least some of these will get wrapped at the beginning of lines in annotated code

In actual code comments, there's no issue because you explicitly control where the line breaks happen.

I assume you're referring to annotated source a la underscore. I think you can fix this trivially with a regular expression after you generate the docs.

That would allow us to keep this helpful rule in place for the 99.99% of cases where it actually catches issues.

[Flet]

I'm a little surprised that this rule does not allow it in comments. Especially since its mentioned in the source: https://github.com/eslint/eslint/blob/master/lib/rules/no-irregular-whitespace.js#L2
Perhaps the eslint folks would accept a patch?

In the meantime, its possible to disable it in individual files by putting this at the top:

/*eslint-disable no-irregular-whitespace*/

Will this work for you?

[tdd]

Hey Dan,

Indeed the source says so, but if you look closely, they strip in-string
errors, not in-comment ones.

Will send a PR upstream.

Thanks for your time!

On Mon, Feb 22, 2016, at 05:07, Dan Flettre wrote:

I'm a little surprised that this rule does not allow it in comments.
Especially since its mentioned in the source:
https://github.com/eslint/eslint/blob/master/lib/rules/no-irregular-whitespace.js#L2

Perhaps the eslint folks would accept a patch?

In the meantime, its possible to disable it in individual files by
putting this at the top:

/eslint-disable no-irregular-whitespace/ Will this work for you?

— Reply to this email directly or view it on GitHub[1].

Christophe Porteneuve
tdd@tddsworld.com

Links:

1. #430 (comment)

[tdd]

FYI, this is in eslint/eslint#5367

[Flet]

Thanks @tdd!

[tdd]

Hey @Flet, @feross and team. So this got dealt with in eslint/eslint#5367, which is on track for inclusion in the next ESLint release. However, to avoid making it a breaking change, it's subjected to a skipComments option that is false by default. I would very much advocate that StandardJS turns this on by default, though.

When ESLint releases a new version with that option in, I would like to make a PR here to use the latest ESLint and turn this option on for the rule. Does that sound good to you?

[tdd]

Hey @feross, following up on our discussion on Twitter, we hadn't closed the loop on this: I had done the work upstream in ESLint to make the rule accept an option for this (skipCmments) over a year ago, but had mistakenly closed this issue here, which made it drop from all our radars…

I believe it would be great if Standard would default to adding skipComments to the rule config…

See the issue I still get with 9.0 on a simple code with proper-French commenting:

Best,

[feross]

Sounds good, I added this to the v11 milestone.