Can anyone clarify the exact algorithm used for the VS code multi-line problem matcher? Specifically curious what the behavior is when there are more than 2 patterns defined.
The context is that I'm trying to write a multi-line problem matcher in VS Code for a rollup task. A sample of the output would look like:
(!) Plugin typescript: #rollup/plugin-typescript TS2345: Argument of type 'FirstType' is not assignable to parameter of type 'SecondType'.
Types of property 'PropertyOne' are incompatible.
Type 'FirstType' is missing the following properties from type 'PropertyOne': X, Y
src/main/pathToFile/file.ts: (174:37)
I've tried a number of options. Here's the most recent attempt:
"pattern": [
{
"regexp":"^[(][!][)](.*)$",
"message": 1
},
{
"regexp":"^\\s+(.*)$",
},
{
"regexp": "^([^:\\s]+):\\s+\\((\\d+):(\\d+)\\)$",
"file": 1,
"line": 2,
"column":3
}],
I would expect this to match the output described, but it doesn't match at all.
If I remove the first pattern, I'm able to get a match, but this doesn't give me all of the information I need.
Related
I'm trying to make a custom syntax highlighter for my own markup language. All the examples are complicated, missing steps and are very, very hard to understand.
Is there anything that fully documents how to make a syntax highlighter?
(for VSCode, by the way)
For example, this video https://www.youtube.com/watch?v=5msZv-nKebI which has an extremely large skip in the middle and doesn't really explain much.
My current code, made with Yeoman generator is:
{
"$schema": "https://raw.githubusercontent.com/martinring/tmlanguage/master/tmlanguage.json",
"name": "BetterMarkupLanguage",
"patterns": [
{
"include": "#keywords"
},
{
"include": "#strings"
}
],
"repository": {
"keywords": {
"patterns": [{
"name": "entity.other.bml",
"match": "\\b({|}|\\\\|//)\\b"
}]
},
"strings": {
"name": "string.quoted.double.bml",
"begin": "`",
"end": "`"
}
},
"scopeName": "source.bml"
}
Synopsis
I'm not sure at what level you're approaching the problem, but there are basically two kinds of syntax-highlighting:
Just identify little nuggets of canonically identifiable tokens (strings, numbers, maybe operators, reserved words, comments) and highlight those, OR
Do the former, and also add in context awareness.
tmLanguage engines basically have two jobs:
Assign scopes.
Maintain a stack of contexts.
Samples
Lets say you make a definition for integers with this pattern:
"integers": {
"patterns": [{
"name": "constant.numeric.integer.bml",
"match": "[+-]\\d+"
}]
},
When the engine matches an integer like that, it will match to the end of the regex, assign the scope from "name", and then continue matching things in this same context.
Compare that to your "strings" definition:
"strings": {
"name": "string.quoted.double.bml", // should be string.quoted.backtick.bml
"begin": "`",
"end": "`"
},
Those "begin" and "end" markers denote a change in the tmLanguage stack. You have pushed into a new context inside of a string.
Right now, there are no matches configured in this context, but you could do that by adding a "patterns" key with some "match"es or "include"s. "include"s are other sets of matches like "integers" that you've defined elsewhere. You can add it to the "strings" patterns to match integers inside strings. Matching integers might be silly, but think about escaped backticks: You want to scope those and stay in the same context within "strings". You don't want those popping back out prematurely.
Order of operations
You'll eventually notice that the first pattern encountered is matched. Remember the integers set? What happens when you have 45.125? It will decide to match the 45 and the 125 as integers and ignore the . entirely. If you have a "floats" pattern, you want to include that before your naïve integer pattern. Both these "numbers" definitions below are equivalent, but one lets you re-use floats and integers independently (if that's useful for your language):
"numbers": {
"patterns": [
{"include": "#floats"},
{"include": "#integers"}
]
},
"integers": {
"patterns": [{
"name": "constant.numeric.integer.bml",
"match": "[+-]\\d+"
}]
},
"floats": {
"patterns": [{
"name": "constant.numeric.float.bml",
"match": "[+-]\\d+\\.\\d*"
}]
},
"numbers": {
"patterns": [{
"name": "constant.numeric.float.bml",
"match": "[+-]\\d+\\.\\d*"
}, {
"name": "constant.numeric.integer.bml",
"match": "[+-]\\d+"
}]
},
Doing it right
The "numbers"/"integers"/"floats" thing was trivial, but well-designed syntax definitions will define utility groups that "include" equivalent things together for re-usability:
A normal programming language will have things like
A "statements" group of all things that can be directly executed. This then may or may not (language-dependent) include...
An "expressions" group of things you can put on the right-hand-side of an assignment, which will definitely include...
An "atoms" group of strings, numbers, chars, etc. that might also be valid statements, but that also depends on your language.
"function-definitions" probably won't be in "expressions" (unless they are lambdas) but probably would be in "statements." Function definitions might push into a context that lets you return and so on.
A markup language like yours might have
An "inline" group to keep track of all the markup one can have within a block.
A "block" group to hold lists, quotes, paragraphs, headers.
...
Though there is more you could learn (capture groups, injections, scope conventions, etc.), this is hopefully a practical overview for getting started.
Conclusion
When you write your syntax highlighting, think to yourself: Does matching this token put me in a place where things like it can be matched again? Or does it put me in a different place where different things (more or fewer) ought to be matched? If the latter, what returns me to the original set of matches?
We are using Orion Context Broker as our database.
Recently, We have meet an requirement that user want to find a City by name of this City container a keyword.
For example:
We have city name likes this. Hanoi, Madrid, London, Barcelona, Paris, Lyon.
If user type: "on", we should show Lyon, London.
The city object like this.
{
"type": "City",
"isPattern": "false",
"id": "city1",
"attributes": [
{
"name": "name",
"type": "string",
"value": "London"
}
]
}
So I am wondering if any queryContext filtering can help us to sort out this case.
I have done some research and there is no good sounds on this.
Many thanks.
You can use idPattern in GET /v2/entities which value is a regular expression. Thus the following query:
GET /v2/entities?idPattern=on
should return any City with the "on" substring in its id.
EDIT: if you want to apply a pattern to the value of some attribute, then you have to use q query parameter and the ~= NGSIv2 Simple Query Operator. Something like this:
GET /v2/entities?q=colour~=or
I have figured out that we use ~= operation to do that.
Please see the follow quote.
Match pattern: ~=. The value matches a given pattern, expressed as a regular expression, e.g. color~=ow. For an entity to match, it must contain the target property (color) and the target property value must match the string in the right-hand side, 'ow' in this example (brown and yellow would match, black and white would not). This operation is only valid for target properties of type string.
http://telefonicaid.github.io/fiware-orion/api/v2/stable/
Section: Simple Query Language
Many thanks.
I am trying to match errors of this format generated by an IAR ARM compiler for the VSCode ProblemMatcher...
"d:\test\helloWorld.c",646 Warning[Pe223]:
function "printf" declared implicitly
With regex101.com I am able to match the first line message with this regex...
^"(.*)",(\d+)\s+((Warning|Error)\[Pe\d+\]):$
Alas, when put into my tasks.json file with the correct escape slashes. The vscode prompts that error in task.json. error in task.json
"problemMatcher": {
"owner": "cpp",
"fileLocation": "absolute",
"pattern": [
// The regular expression for IAR ARM compiler. Example to match:
// "d:\test\helloWorld.c",646 Warning[Pe223]:
// function "printf" declared implicitly
{
"regexp": "^"(.*)",(\\d+)\\s+((Warning|Error)\\[Pe\\d+\\]):$",
// The first match group matches the file name which is relative.
"file" : 1,
// The second match group matches the line on which the problem occurred.
"location": 2,
// The third match group matches the message
"message" : 3,
// The fourth match group matches the problem's severity. Can
// be ignored. Then all problems are captured as errors.
"severity": 4
},
{
// The next line matches the message.
"regexp": "^([^\\s].*)$",
"message": 1
}
]
}
Then, I removed the "", and it became,
^(.*),(\\d+)\\s+((Warning|Error)\\[Pe\\d+\\]):$
At last, I receive output in the Problems tab after running the task that will generate these errors in the terminal of VSCode. The warning message and line number are correct. But the file does not match, and can't jump to file.
OK, I found the answer from https://learn.microsoft.com/en-us/visualstudio/ide/using-regular-expressions-in-visual-studio
\" Match a double quotes
So the correct regexp is,
"regexp": "^\"(.+?)\",(\\d+)\\s+((Warning|Error)\\[Pe\\d+\\]):$",
I have a somewhat similar business problem to - Gremlin filter by count
, but I'm running on OrientDB 3.0.16
This query:
g.V().hasLabel('skill').
groupCount()
Returns from OrientDB, as expected:
{
"result": [
{
"com": 1,
"netcompactframework": 1,
"netremoting": 2,
"netframework": 3,
"net": 1,
"netclr": 1
}
],
"elapsedMs": 18
}
I tried to apply an unfold and where filter after it:
g.V().hasLabel('skill').
groupCount().
unfold().
where(select(values).is(gt(1)))
But I get an error:
{
"errors": [
{
"reason": 501,
"code": 501,
"content": "java.lang.UnsupportedOperationException: Cannot convert netremoting=2 - class java.util.HashMap$Node to JSON"
}
]
}
It seems that problem is with unfold() as OrientDB is trying to convert the map entry string into JSON and fails
Any ideas?
Is this an OrientDB specific issue? Maybe there is another way to perform the same logic in gremlin?
That looks like a serialization error of some sort, but I'm not sure of the circumstance under which you are operating to get that problem. When you unfold() a Map, it gets converted to Java Map.Entry and returning that seems to be a problem for the serializer which along the way encounters the internal class HashMap$Node. I think you can work around this problem by folding back to a Map:
g.V().hasLabel('skill').
groupCount().
unfold().
where(select(values).is(gt(1))).
group().
by(keys).
by(select(values))
I would be curious to know what circumstances cause you to get that error. Standard GraphSON serializers in Gremlin Server should be able to handle HashMap$Node so it's curious that you'd be getting this problem at all.
I have the latest of JsDoc (3.4.3), and as per the documentation of JsDoc, I added array of unknown tags, but got slapped with error of unknow tag
The #foo: tag is not a known tag.
"allowUnknownTags": [ "foo", "usage", "test" ]
Am I missing something ?
Am I expected to write customTag plugin ?
allowUnknownTags takes a boolean, not an array.
[...]
"tags": {
"allowUnknownTags": true,
"dictionaries": ["jsdoc","closure"]
},
[...]
See this question & answer "create custom tags with jsdoc" for more about defining your own tags in a custom dictionary*.
*: Maybe... I don't really know, but it seems about right.
http://usejsdoc.org/about-configuring-jsdoc.html