Gtk themes fixing error "Not using units is deprecated. Assuming 'px'." - gtk3

I've been doing researches to try to find how to fix the error:
(launcher:7412): Gtk-WARNING **: Theme parsing error: gnome-applications.css:23:20: Not using units is deprecated. Assuming 'px'.
on Gtk 3+ themes.
It seems to be that this error came when updating to Gtk 3.4. The best answer that i found was "must add px at the end of the line" they were talking about the css files that
has this kind of content..
}
.check:insensitive,
.check row:selected:insensitive,
.check row:selected:focused:insensitive {
background-image: url("assets/checkbox-unchecked-insensitive-dark.svg");
}

Rewritten due to new information:
In line 23, the border-radius rule needs a measurement unit. Change it to border-radius: 5px;. Similar with all the text-border, border-width etc. rules: they all need a unit. (In this case px, because that was the implicit default before.)
Note that after editing, you may have to log out of your Desktop Environment and log in again in order for the CSS to be reloaded.

I used these find and replace regexes in Sublime Text 3 to find and fix the 'no px' problems. I sincerely think I did it correctly. It seems to work fine. But I were you, I'd make backup files before running any sort of regexp system like this. If I'd thought ahead, I've had used 'sed -e -i.Backup', but the regexes aren't exactly the same.
FIND:
-(width|length|height|radius|border|spacing|padding): ([1-9][0-9]*);
REPLACE:
-\1: \2px;
Note that a simple 'whatever-length: 0;' is NOT altered. As zero is the same in all units.

Related

Is There Any Way to Disable Error Highlighting in Github?

Github highlights the second % in this line as an error:
fscanf(fp, "%d%*[^\n]\n", &ints[i]);
However, the code compiles perfectly and the removing the 'error' will cause the program to function incorrectly.
Is there any way to either disable this error highlighting or make Github recognize it as correct?
Update: pchaigno points out in the comments the section linguist#Overrides, where you can use for instance .gitattributes:
Add a .gitattributes file to your project and use standard git-style path matchers for the files you want to override to set linguist-documentation, linguist-language, linguist-vendored, and linguist-generated. .gitattributes will be used to determine language statistics and will be used to syntax highlight files. You can also manually set syntax highlighting using Vim or Emacs modelines.
$ cat .gitattributes
*.rb linguist-language=Java
Original Answer Jan. 2017
Since you cannot easily remove the GitHub highlight, you can try and use a similar workaround I suggested in "How to fix/ignore syntax error in github"
Try and add on the same line a comment with a '%' in it, in order for the lexer (used by the syntax highlighting engine Rouge and Pygment) to not propagate the "error" to all subsequent lines.
To complete VonC's answer, if you think the highlighting is incorrect, you can actually file a bug report or even fix it; All grammars github.com uses are open source!
How to find the grammar? To find the grammar used for syntax highlighting in your case, you can visit this page on the Linguist project. In front of each language (looks like C in your case), you'll find the repository where the grammar for that language lives (for C, github.com/textmate/c.tmbundle). You can open an issue there with your failing test case, or even better, try and fix it yourself.

Auto fixing warnings reported by ScalaStyle

Is there a way to get ScalaStyle (or any other automation tool) to fix some of the warnings it finds?
For example --
Line contains a tab (shock!!)
There should be a space before the plus (+) sign
File must end with newline character
At a stretch
Public method must have explicit type
As of right now, Scalastyle does not have a way to automatically fix errors. However, it looks like Scalafix might. This is from their documentation:
A scalafix “Rule” can report lint messages and provide auto-fix patches to violations of some kind of rule/coding style/convention/breaking change.
Sounds promising! I have not had a chance to use it yet, but since this question has gotten no replies in almost three years, it seemed worth adding this as a possible solution to your problem if anyone else has a similar issue.

Highlighting line which are not correctly formated [Eclipse]

So I have some formatting rule to follow, such as :
Space on each side of operator (*, =, +, %, etc)
No space at the end of a line
No more than 80 chars per line
Is there a way to highlight in red line containing formating error?
The eclipse auto-formating tool is no good because either :
It will change to many line (old code not written by me)
or it won't (only my code)
Because I must follow some "colorfull" guideline :
You must change formating error relative to operators in old code but nothing else
Your code must be correctly formated.
Any ideas?
Thanks
You can select which lines of code you want to format. The Eclipse formatting tool doesn't have to run across the entire file. To do this: select the lines you want to format, then press Ctrl-Shift-F.
You could try using the Eclipse Checkstyle Plugin.
You'll need to configure it with just the rules that you need (the default configuration is very strict, so create a new one with just the rules you care about).
This will highlight all lines with formatting issues. I don't think it's possible to ignore old code using the plugin.
Talk to whoever created that coding guideline. It does not make sense in the long run, because editing code in Eclipse will always apply all current formatting rules (which violates that guideline) or none, if you disable the formatter (which leads to you writing bad code).
If there is really no way around that guideline, then you should split your workflow into 2 phases: Reformat all existing code one time to fulfill that operator guideline. You may use any tool you like, even just a regular expression search and replace might be fine.
After that has been done, configure Eclipse to auto-format only changed lines, but always apply all formattings to each changed line. There is no good reason to not re-format the other 75 characters in an existing line of code, if you already touched 5 characters of it.

"unexpected '=' "

I try to compile this .coffee file into .js, but it gives me error:
In projekt.coffee, Parse error on line 122: Unexpected '='
here is the specific part:
#line122 -># quotes = ["The people who were trying to make this world worse are not taking the day off. Why should I? <br> -Bob Marley", "Don't worry about a thing, every little thing is gonna be alright<br> -Bob Marley", "Better to die fighting for freedom then be a prisoner all the days of your life.<br> -Bob Marley", "Herb is the healing of a nation, alcohol is the destruction of mankind<br> -Bob Marley", "When you smoke the herb, it reveals you to yourself.<br> -Bob Marley", "My music fights against the system that teaches to live and die.<br> -Bob Marley"]
quoteNumber = Math.floor(Math.random() * quotes.length)
$('#cytat').html '<p> #{quotes[quoteNumber]} <p>'.css
font-family : Finger Paint
ande here the whole code:
http://jsfiddle.net/BNMa7/
i dont really know whats going on since it tells me that '=' is unexpected, but it clearly defines an array. help...
There are multiple problems with this that we should address before the syntax error you're describing.
font-family is not a valid stand-alone key. You need to quote that in order to compile it correctly. Same with Finger Paint -- I don't know what's up with that.
String interpolation doesn't work with single quoted strings. You need to use double quotes if you want #{quotes[quoteNumber]} to be replaced with the quote at that index.
With these fixed, we still have a big problem with operator precedence:
$('#cytat').html "<p> #{quotes[quoteNumber]} <p>".css
'font-family': 'Finger Paint'
That's equivalent to:
$('#cytat').html("<p> #{quotes[quoteNumber]} <p>".css('font-family': 'Finger Paint'));
Which is probably not what you meant, since strings don't have a .css() method. Add parens around the .html() call to get it to the correct meaning:
$('#cytat').html("<p> #{quotes[quoteNumber]} <p>").css
'font-family': 'Finger Paint'
Now, finally, the syntax error. At first glance, this appears to be perfectly valid code, and the error message isnt' very helpful... but this code has a fatal mistake. Do you see it? There's nothing wrong with the sample you posted; this is only wrong in the context of the rest of the file. So what is it?
You've mixed tabs and spaces. Never mix tabs and spaces. The CoffeeScript compiler is apparently using a different tab width than your editor, so it freaks out, and gives you a crazy error message.
Consider using a text editor that will automatically translate tabs into (a consistent number of) spaces, or at the very least one that allows you to view invisible characters. I like Sublime Text, but there are plenty of options out there.

Flex does not remove yyunput even with suitable flags

I'm Flexing a file with the
%option nounput
Option and using the command line
flex --nounput
And flex version 2.5.35.
However, the cpp output still contains the line
#define unput(c) yyunput( c, (yytext_ptr) )
And this causes compilation problems with g++ since unput is not used.
Is there some way to fix this problem in a "clean" way? The two dirty ways are obvious:
Use unput in some useless way.
Remove the line automatically from the generated cpp file using some script.
(I tried to flag this question as "problem no longer reproducible" but the flag timed-out/aged away. I'm answering it so that it does not remain an open unanswered question.)
As mentioned by #akond:
I don't experience this problem. The version I am using is the same (flex 2.5.35). %option nounput does the trick for me.
I also tried this on version 2.5.4 and can confirm there is no issue. The option --nounput is no longer recognised or documented; however, the %option nounput remains in the manual.
The cpp output still does contain the line #define unput(c) yyunput( c, yytext_ptr ) but this does not seem to generate any g++ errors for me. Are you using -pedantic-errors or some other similar option perhaps?
Good program but badly out of date documentation.
I found that version 2.6.4 accepts the nounput option and does the right thing.