In Visual Studio Code (1.22.2) when I add certain words to a YAML file they are syntax highlighted differently to what is expected.
For example both on and y are colored orange here. AFAIK, neither on nor y have any special YAML significance. This occurs for other keys and values also. I note this same color is used on values of true or false but here it is occurring for seemingly arbitrary values and also for keys. The same occurs after a restart with all extensions disabled so it's not some forgotten extension I don't think.
Is this some other file-type syntax-highlighter interfering? Am I missing something about YAML 'keywords'?
In YAML 1.1, there are actually many values recognized as booleans, and on and y belong to them.
See the type specification for !!bool in the YAML 1.1 type repository: http://yaml.org/type/bool.html
I wrote this overview of Types/Schema in YAML 1.1/1.2 a while ago, maybe this is helpful too:
http://blogs.perl.org/users/tinita/2018/01/introduction-to-yaml-schemas-and-tags.html
One of the bigger changes in 1.2 was that less values are recognized as booleans.
Related
As you can see, in C++ type declarations (string and new type), the colors of the types are in normal text color, which I find oddly peculiar, since it isn't the case for java source codes (even using the exact same theme).
I've tried customizing it in user settings:
But all that does is change the color of the type in the type definitions, not in the declarations.
I've also tried out various themes, but it's all the same.
Strangely, this doesn't happen for java source codes as shown in the image below:
I might be missing something. Maybe there's some field or attribute in the user settings that I should change instead of the 'type'.
Does anyone know how?
According to the Developer: Inpsect TM scopes command, the entire string x declaration has the same scopes:
source.cpp - the "base" scope for cpp files that everything in them has
meta.block.c - just tells you that it's inside of a block / {}
Consequently, there's not really anything to target with editor.tokenColorCustomizations, since that's based on scopes.
You could search for an extension that replaces the built-in CPP grammar with one that is better in this regard. Note that the only one I've found so far, Reloaded C/C++, doesn't help. Alternatively, you could search for a better grammar elsewhere - TmLanguage grammars are very commonplace and used in many editors, not just VSCode. Even GitHub uses them for their syntax highlighting.
The zinc spec says this:
If no output item is present, the implementation should print all the global variables and their values in a readable format.
However this does not appear to work with minizinc version 1.6.0:
G12 MiniZinc evaluation driver, version 1.6.0
I've tried the default command (minizinc) and mzn-gecode.
I'd really like to avoid repeating all the variable names in the output expression. What I really want is to have all decision variables output in some structured format (e.g. YAML), but I'd settle for some way to avoid this repetition.
To clarify: my model doesn't match the typical examples of CSP, e.g. there's no big array or matrix. It's just a fairly big (in relative terms) set of individual decision variables.
EDIT: bug created.
EDIT2: bug is now fixed in the minizinc 2.0 git repository so it conforms to the spec.
What I know, all FlatZinc solver just show a "----------" for every solution when there is no defined output item in the model. So it seems that the spec is wrong/obsolete on this part.
There have been some (more or less radical) changes regarding the output item during the years. In some early MiniZinc version it worked the way the spec described, and it was quite handy when modelling a problem (though it was very hard to get nice output). It was a real nuisance when the behaviour was changed so an output item was required for showing the result.
Interestingly, Zinc (the "big brother" of MiniZinc, http://www.minizinc.org/g12_www/zinc/ ) works as described i.e. shows all global variables when there is no output item. Perhaps the spec writers just forget to mention that MiniZinc differs.
I've got a rather big and verbose section of line-based configuration file. I'd like to use this section as template (assuming I going to preconfigure this section, test it and then replace actual values with $(make) $(macros)), substituting the key parameters (very few of them, really) effectively "cloning" this "template" with few customized parameters to the working config file. Can make do the work for me in the described case?
Please bear with me, I'm truly a make layman and even not sure if it is right tool in this case.
An example
I'm preconfiguring and testing something like:
<section0>
contains a lot of settings
which were tested and should
be exactly the same in every copy
except marked with trailing0
</section0>
I'm wondering that if convert tokens marked with trailing zero above to macros:
<$(section)>
contains a lot of settings
which were tested and should
be exactly the same in every copy
except marked with $(trailing)
</$(section)>
... wondering that I can utilize make to produce clones of premade configuration slightly customized with my data in place of macros:
<section42>
contains a lot of settings
which were tested and should
be exactly the same in every copy
except marked with trailing42
</section42>
<foo>
contains a lot of settings
which were tested and should
be exactly the same in every copy
except marked with bar
</foo>
Assuming "section42", "foo" and "trailing42", "bar" are substitutes for $(section), $(trailing) macros respectively.
You can use m4 preprocessor in your makefiles to do exactly that: expand macros in template files:
M4 can be called a “template language”, a “macro language” or a “preprocessor language”. The name “m4” also refers to the program which processes texts in this language: this “preprocessor” or “macro processor” takes as input an m4 template and sends this to the output, after acting on any embedded directives, called macros.
Create a file named section.m4:
$ cat section.m4
<section0>
contains a lot of settings
which were tested and should
be exactly the same in every copy
except marked with trailing0
</section0>
And have a rule in your makefile to expand macros in that template to produce section.cfg:
section.cfg : section.m4
m4 -Dsection0=foo -Dtrailing0=bar $< >$#
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.
why doesn't eclipse match the argument while doing code completion. In the following example it should have automatically matched the throwable. In stead it shows arg1 as the first option.
The autocomplete options in Eclipse for auto-completed method arguments, start with the parameter names found in the source distribution (that contains the class with the method). If no source distribution is available, then it will use the parameter names as indicated in the binary distributions i.e. in the compiled byte code. This is the default behavior
If you want to change this behavior of inserting parameter names from source code or binaries to inserting the best guessed arguments (including local variables), then you can configure the auto-complete options of Eclipse to do so, as shown in the following screenshot:
This will produce the desired result of automatically displaying the options containing the list of best-guessed arguments. This also seems to avoid suggesting parameter names:
I guess arg1 is thing you already typed. So the proposal eclipse can provide is trying to find something which start from arg1.
So it puts it as the first choice.
You can type t , and try Alt+/ , to see if this is the reason.