So i have these two configurations in my rubocop.yml file
Layout/SpaceAfterColon:
Enabled: true
Style/HashSyntax:
EnforcedShorthandSyntax: always
This shows missing space after colon when i try to use short hand syntax for hash or function call codeclimate shows missing space after colon issue.
If space is given, shows white space before comma issue or trailing white space issue depending on the context.
I would like to use short hand syntax, without seeing missing space after colon issue but have space after colon when not using short hand. white space before comma and trailing white space should also be enabled.
None of the combination of styles works.
apart from above settings
in project .rubocop.yaml
AllCops:
TargetRubyVersion: 3.1
Related
What's the correct term for the space between blocks of code? The best I have come up with is 'block delimiter' (as in code block delimiter)
Background
I'm writing some documentation and need to know what the space between blocks of code is called. I can see a very common pattern is to leave a single line gap (in other words, \n\n goes between the last character of the last code block and the first character of the next code block - examples here).
Question
What is the appropriate term for the space between the last character of a code block and the first character of the following code block?
Consider term padding line between blocks as inspired by ESLint's rule padding lines between statements:
Require or disallow padding lines between statements
(padding-line-between-statements)
This rule requires or disallows blank lines between the given 2 kinds
of statements. Properly blank lines help developers to understand the
code.
I'm really confused about this. I have same shortcode but different spacing which causes the second shortcode to fail.
[button link="#"]btn[/button]
[button link="#"]btn[/button]
They look identical but when runing on a compare tool, there's a difference in space before link.
Please see here:
http://www.diff-online.com/view/589710128ca13
How is that possible? Any idea? Thanks.
You can check what character it is at What Unicode Characters it is
You would have realized that the first one is:
U+0020 : SPACE [SP]
While second is:
U+00A0 : NO-BREAK SPACE [NBSP]
Just because they look same doesn't necessary mean they are same character.
I am trying to better understand the HTML whitespace processing model. Right now I'm comparing two HTML snippets:
<div>a <br>z</div>
and
<div>a<br> z</div>
The first snippet, when renered, yields two lines: "a " and "z" (So the first line has a trailing space.)
The second snippet yields two lines: "a" and "z". There is no leading space on the second line.
My question is: why? I'm currently using this http://www.w3.org/TR/CSS2/text.html#white-space-model as a reference. It states
If a space (U+0020) at the beginning of a line has 'white-space' set to 'normal', 'nowrap', or 'pre-line', it is removed.
All tabs (U+0009) are rendered as a horizontal shift that lines up the start edge of the next glyph with the next tab stop. Tab stops occur at points that are multiples of 8 times the width of a space (U+0020) rendered in the block's font from the block's starting content edge.
If a space (U+0020) at the end of a line has 'white-space' set to 'normal', 'nowrap', or 'pre-line', it is also removed.
If spaces (U+0020) or tabs (U+0009) at the end of a line have 'white-space' set to 'pre-wrap', UAs may visually collapse them.
A naive reading of this would indicate that, since a space that the beginning or end of a line is to be removed (when 'white-space' is 'normal'), the first of my snippets ought to result in no trailing space. But that isn't the case.
So what's going on?
My current theory is that the <br> is secretly counted as a "character" which, in the first snippet, prevents the trailing space from being at the "end" of its line. But I really have no idea.
EDIT: To be clear, I know how to use to create spaces at will. My question is about what rule (with regard to some spec) induces the above behavior.
Good question! I've confirmed the behavior in both Chrome and Firefox, and confirmed that it has nothing to do with <br>, as it's also triggered by an ordinary linebreak in white-space: pre-line conditions:
<div style="white-space:pre-line">a
z</div>
I've sent an email to the list asking for clarification on this issue, and inquiring whether we should change the spec to match implementations, or file bugs on browsers to match the spec.
I ran into a bug in a mime parsing library where it blows up on subject lines that contain foreign characters beyond a certain length. It turns out that it would convert the subject into a Quoted-Printable MIME "Encoded-Word" and then try to word-wrap the whole thing to 78 characters. Because MIME-Word encoding has no spaces (they are replaced with underscores) it failed to wrap.
Example line being wrapped:
Subject: =?UTF-8?Q?lalalla_=E7=84=A1=E6=AD=A4=E7=84=A1=E6=AD=A4=E9=A0=85=E7=9B=AE=AE=AE=AE=AE=AE=AE=AE=AE?=
I thought I might contribute a patch to the library to wrap the line correctly but I couldn't find a reference as to how to break up a MIME-Word as part of a word-wrapping algorithm.
The RFC 5322 says to word-wrap at spaces but doesn't provide any guidance about what to do if there's a string of characters with no white-space that exceeds the target width.
Anyone know the correct action to take here?
Just split the line where you need to, and continue with a 2nd wrapped line. For example:
Subject: =?UTF-8?Q?lalalla_=E7=84=A1=E6=AD=A4=E7=84=A1=E6=AD=A4?=
=?UTF-8?Q?=E9=A0=85=E7=9B=AE=AE=AE=AE=AE=AE=AE=AE=AE?=
Just be sure to make sure the 2nd (and following) wrapped lines start with either a space or a tab.
hth,
--Dave
I am url encoding a string of text to pass along to a function. However, it encodes the second space in a double-space as "%A0". This means that when I decode the string, the "%A0" is displayed as a question mark in a black box.
I really just need to be able to remove the extra space, but I'd like to understand what is causing this and how to handle it correctly.
For example:
Something Something else
Encodes to:
Something+%A0Something+else
%A0 indicates a NBSP (U+00A0). + indicates a normal space (U+0020). The NBSP displays as a replacement character (U+FFFD) because the encoding of the character does not match the encoding of the page, so its byte sequence is not valid for the page.
A quick Googling shows that %A0 is the non-breaking space character or in html. A + is the form-encoding for a standard space character.
Source
The problem you're having is that the second "space" is not really a space, it's a character that that font doesn't have a glyph (I think that's the term) to represent (hence the black box with the question mark). %A0 is the escape code for that character. Your code is technically handling it correctly, I think the problem is with whatever is generating the string in the first place.
If I refer to the chart on this page, %A0 is not a space. %20 is the space caracter's encoded value.