Custom rule for new line after/before MARK in SwiftLint - swiftlint

Could you help me?
I want to write custom rule for SwiftLint.
I would like to enforce putting one blank line before and after PRAGMA MARK: //
Example:
Error case
some code\n
// MARK - Smt\n
some code\n
Right case
some code\n\n
// MARK - Smt\n\n
some code\n\n
Thx in advance

I think you can try setting the regex to match "// MARK -" with newlines preceding it and coming after it.
To make sure SwiftLint only applies this to comments, you can set "match_kinds" to just comments on the SwiftLint yml file.

Related

Modx *id isnot =`` and isnot=`` not working

Hi can someone help me with the correct code for this statement because it is not working for me.
[[*id:isnot=`250` and isnot=`252`:then=`[[$qc-wrap]]`]]
A more performant syntax would be:
[[[[*id:isnot=`250`:or:isnot=`252`:then=`$qc-wrap`:else=``]]]]
Note: updated to reflect comment below. Include a hyphen in the else value, as this:
[[[[ ... :else=`-`]]]]
Also note: an empty else condition can be left off entirely.
I think using or rather than and is appropriate here.
This article is great for understanding MODX conditionals:
https://sepiariver.com/modx/modx-output-filters-if-phx-conditional-statements-tutorial/
And this one for understanding the syntax above and why it's more performant:
https://modx.com/blog/2012/09/14/tags-as-the-result-or-how-conditionals-are-like-mosquitoes/
You use wrong syntax, please fix as follows:
[[*id:isnot='250':and:isnot='252':then='[[$qc-wrap]]']]
Don't forget to replace ' with ` within this example
A simpler solution for this question is to use the :inarray output modifier to return an empty string, and use the :default output modifier to customize output for everything that doesn't match 250 or 252:
[[*id:inarray=`250,252`:then=``:default=`[[$qc-wrap]]`]]

How do I use the default 'legalCommentPattern" with SonarQube

I need a trailing comment in my code. Sonar keeps throwing this error. Unlike the public version, our Sonar says there is a way around this...
Parameters
legalCommentPattern
Pattern for text of trailing comments that are allowed.
Default Value:
^//\s*+[^\s]++$
This seems to suggest there is a way to add a comment to the EOL (which I need to do) but playing around in Regex pal I can't seem to figure it out.
How do I add a trailing comment that meets the legalCommentPattern. Or how do I change the value to allow for inline shorter comments.

How to format a WinMerge fllter to ignore part of the line

I would like WinMerge to compare the full text but exclude a variable substring.
Orientation="West" PhysicalAddress="2395226" DefFieldFrmt="Uf4d0" UnitCustomText="sec"
Orientation="West" PhysicalAddress="2395230" DefFieldFrmt="Uf4d1" UnitCustomText="sec"
In the lines above I want to ignore the PhysicalAddress="xxx" and locate the changed DefFieldFrmt="Uf4d1"
I have tried adding the filter:
PhysicalAddress=".*"
However this filters the complete line.
The actual text before and after the PhysicalAddress="xxx" will vary so I need a filter that says: match prefix and match suffix but ignore target variable substring.
Help please.
According to the documentation, is not possible to use the line filters for this:
When a rule matches any part of the line, the entire difference is ignored. Therefore, you cannot filter just part of a line.
However, since WinMerge's source code is on GitHub, it is possible to add a feature request for this to its list of issues.

Log parsing rules in Jenkins

I'm using Jenkins log parser plugin to extract and display the build log.
The rule file looks like,
# Compiler Error
error /(?i) error:/
# Compiler Warning
warning /(?i) warning:/
Everything works fine but for some reasons, at the end of "Parsed Output Console", I see this message,
NOTE: Some bad parsing rules have been found:
Bad parsing rule: , Error:1
Bad parsing rule: , Error:1
This, I'm sure is a trivial issue but not able to figure it out at this moment.
Please help :)
EDIT:
Based on Kobi's answer and having looked into the "Parsing rules files", I fixed it this way (a single space after colon). This worked perfectly as expected.
# Compiler Error
error /(?i)error: /
# Compiler Warning
warning /(?i)warning: /
The Log Parser Plugin does not support spaces in your pattern.
This can be clearly seen in their source code:
final String ruleParts[] = parsingRule.split("\\s");
String regexp = ruleParts[1];
They should probably have used .split("\\s", 2).
As an alternative, you can use \s, \b, or an escape sequence - \u0020.
I had tried no spaces in the pattern, but that did not work.
Turns out that the Parsing Rules files does not support
empty lines in it. Once I removed the empty lines, I did not
get this "Bad parsing rule: , Error:1".
I think since the line is empty - it doesn't echo any rule after
the first colon. Would have been nice it the line number was
reported where the problem is.

syntax highlighting between matching parenthesis

Say I hava a LaTeX document open in Vim, and I want to highlight every occurence of
{\color{red} ... }
(where the dots are supposed to symbolize some contents), that is, I want to have {\color{red}, } and everything between these highlighted. This I have done with
:syn region WarningMsg start=+{\\color{red}+ end=+}+
but I have the problem that, if I write something like {\color{red} some{thing} important}, then it is only {\color{red} some{thing} which gets highlighted, because Vim of course mathces the first occurrence of }. How can I make this Highlighting rule so that it skips matching curly brackets? Even multiple levels of such.
For clarity it is better to give each syntax region a bespoke name, and then link it to a standard colour group. I have renamed your original region redTeX.
You need to define a second region, innerBrace, defining the braces you want to ignore, and mark this region as transparent. Then redTeX should be marked to contain the transparent region, which it will then ignore.
syn region innerBrace start=+{+ end=+}+ transparent contains=redTeX
syn region redTeX start=+{\\color{red}+ end=+}+ contains=innerBrace
hi link redTeX WarningMsg
Note that in this case there is the added subtlety that redTeX itself matches as an innerBrace. I fixed this by marking innerBrace as containing redTeX.
Hope that makes sense!