I'm trying to create a syntax highlighter for vscode. I've been making progress. However, there is a sequence that I just can't seem to get working.
I'm trying to highlight some identifiers, only within a certain section of code. In the following example, it's the keywords public, private, and abstract. They should only be highlighted after following the introducer keywords 'fn' or 'class', and also being enclosed within brackets.
fn [public] MyFunction() {}
class [private, abstract] MyClass {}
I'm trying variations of the following:
"decorations": {
"name": "decorations.lang",
"match": "(fn|class)\\s*\\[\\s*([a-zA-Z0-9_, ]+)\\s*\\]",
"captures": {
"2": {
"name": "decorations.captures.lang",
"patterns": [
{
"name": "entity.name.function.decorator.lang",
"match": "\\b(public|private|abstract)\\b"
}
]
}
}
}
I checked that the "match" regex would match the above code. I used the following site:
https://rubular.com
The idea is to first match the stuff within the brackets, after seen one of the introducer keywords, and then do a submatch for the specific context keywords. When I check the tokens created, by using the vscode command Developer: Inspect Editor Tokens and Scopes, no match gets made for the stuff in brackets.
What is the correct setup to match those context sensitive keywords?
I rubber ducked myself. Right after I posted the question, the answer occurred to me.
The issue is that the highlighter definition has 2 sections, the "patterns" and the "repository".
{
"patterns": [...],
"repository": {...}
}
The patterns section, being an array, matches the entries in order. If another entry matches first, then rest are not tried. In my case, there was an entry matching the 'fn' and 'class' as keywords. After I moved the ref #decorations higher , within the 'patterns' section, it solved the issue.
However, that then creates an issue that the keywords won't get highlighted, in that case, because the context sensitive keywords are matched first. But, that's another problem.
Related
VIA Actions Console, not Dialogflow!
After several days I finally finished to create a Quiz that works like this.
Google Mini says: "What is the capital of France? A) Rome, B) Berlin or C) Paris ?"
In my scene i have two conditions.
scene.slots.status == "FINAL" && intent.params.choosenABC.original == session.params.antwort
AND
!(scene.slots.status == "FINAL" && intent.params.choosenABC.original == session.params.antwort)
So here, these conditions check whether the user says the correct letter coming from the session parameter "antwort".
Everything works smooth as long as the user says "A", "B" or "C".
But how can i compare a condition to what the user says?
In the above example i want the user to be able to say "Rome" or "Berlin" or "Paris" and the condition to check these entries.
Thanks in advance!
You have a number of questions packed in there, so let's look at each.
Does input.params.original exist?
In short, yes. You can see the documentation of the request Intent object and you'll see that there is intent.params.*name*.original. Your question seems to suggest this would work as well.
There is also intent.params.*name*.resolved which contains the value after you take type aliases into account.
I found some variables on a Dialogflow forum...
Those only work if you're using Dialogflow and don't make any sense when you're looking at Action Builder.
How to match
You don't show the possible value of session.params.antwort or how you're setting antwort. But it sounds like it makes sense that you're setting this in a handler. So one thing you could do is to set antwort to the city name (or whatever the full word answer is) and set letter to the letter with the valid reply. Then test both against original to see if there is a match.
But, to be honest, that starts getting somewhat messy.
You also don't indicate how the Intent is setup, or if you're using an Entity Type to capture the answer. One great way to handle this, however, is to create a Type that can represent the answers, and use a runtime type override to set what the possible values and aliases for that value are. Then, you can control exactly what the valid value you will use to compare with will be.
For example, if you create a type named "Answer", then in your fulfillment when you ask the question you can set the possible values for this with something like
conv.session.typeOverrides = [{
name: 'Answer',
mode: 'TYPE_REPLACE',
synonym: {
entries: [
{
name: 'A',
synonyms: ['A', 'Rome']
},
{
name: 'B',
synonyms: ['B', 'Berlin']
},
{
name: 'C',
synonyms: ['C', 'Paris']
}
]
}
}];
If you then have an Intent with a parameter of type Answer with the name answer, then you can test if intent.parameter.answer.resolved contains the expected letter.
Adding a visual interface
Using runtime type overrides are particularly useful if you also decide to add support for a visual selection response such as a list. The visual response builds on the runtime type override to add visual aliases that users can select on appropriate devices. When you get the reply, however, it is treated as if they said the entry name.
I'm seeing an error during parsing with the Python and JS parsers. I can't seem to find an example in the TOML repo about whether this should be accepted or not:
[[somearray]]
one.two = false # fails, '.' not allowed in key
I know I can express this as:
[[somearray]]
[somearray.one]
two = false # OK
The TOML readme offers this example (among others):
[fruit]
apple.color = "red"
apple.taste.sweet = true
which does not involve arrays but seems to legitimize this syntax.
I also observe that a plain file with this content:
apple.color = "red"
is rejected. In conclusion, until you enter "table mode" (so to say) with an actual bracketed table, keys can only be singles.
Now again, in the TOML readme it says (although in the tables section):
"Dotted keys define everything to the left of each dot as a table."
Obviously, if mainstream parsers choke on it, it's not a good idea to use it, but I'd like to understand if/why it's a known no-no. Is here some ambiguity I'm not seeing?
These cases are confirmed valid TOML, per the 1.0 spec, which adds many more examples: https://github.com/toml-lang/toml/blob/1.0.0/toml.md
The following is definitely valid Toml syntax:
[[somearray]]
one.two = false
It should result in a model that is equivalent to this Json syntax:
{
"somearray": [
{
"one": {
"two": false
}
}
]
}
It can be validated here.
Dotted keys should indeed define everything to the left of each dot as a table.
I can't create a queryPattern containing two Text fields, like so:
"parameters": [
{
"name": "text_a",
"type": "org.schema.type.Text"
},
{
"name": "text_b",
"type": "org.schema.type.Text"
}
],
"trigger": {
"queryPatterns": [
"add $org.schema.type.Text:text_b with $org.schema.type.Text:text_a",
"combine $org.schema.type.Text:text_b along with $org.schema.type.Text:text_a"
]
}
This will always result in a failure to match the intent (for example "add something with another").
However, I can use two Color types: If you change "Text" to "Color" in the above, and say "add red with blue" or "combine auburn along with green" then it matches and fires the intent.
I am creating deep-link intents only (i.e., commands, not a back-and-forth dialog), so I don't think DialogFlow will help me?
I suspect that the problem is that AoG is treating text parameters as "greedy", so a second parameter never matches because the first parameter has captured all the text. You don't see this with specific types, because it does more narrow matching for them.
You may actually try to use Dialogflow - it does work for deep linking Intents, although I don't know if it will behave the same way.
I have an entity called #spare_part and this entity has 4 values with the following example synonyms each:
both with synonyms filter, oil level indicator
not_defined with a synonym spare part
only_gear with synonyms valve, seal
whole_gear_box with a synonym complete set of gearbox
I want to be able to handle multiple entities given in the same input and address them later on, if needed. With this purpose I have coded the following in JSON editor:
{
"context": {
"sparepartrequest": "#spare_part.values"
},
"output": {
"generic": [
{
"values": [
{
"text": "You want an offer for the following parts: <?
$sparepartrequest.join(', ') ?>."
}
],
"response_type": "text",
"selection_policy": "sequential"
}
]
}
}
I have created a context variable called sparepartrequest as can be seen from the code lines above. For instance when the user says "I want an offer for a filter and a seal", the output of the bot is the following sentence:
You want an offer for the following parts: both, only_gear.
I don´t want the bot to prompt back the names of the values of the entity #spare_part, I rather want it to store the exact input of the user, for our case which would be filter and seal. So if the bot worked as I wanted it to, the output would look like the following:
You want an offer for the following parts: filter, valve.
Again, I believe that this can be handled with JSON Editor. Thank you !
Use two context variables. sparepartrequest as already done and sparepartrequest_literals as follows:
"sparepartrequest_literals":"<? entities['spare_part'].![literal].join(', ') ?>".
Then, in your text response call it by $sparepartrequest_literals to print the mentioned parts or use $sparepartrequest to refer to the detected values.
I have this data in one column in postgresql
{
"geometry":{
"status":"Point",
"coordinates":[
-122.421583,
37.795027
]
},
and i using his query
select * from students where data_json LIKE '%status%' ;
Above query return results but this one does not
select * from students where data_json LIKE '%status:%' ;
How can fix that
Of course the 2nd one doesn't find a match, there's no status: text in the value. I think you wanted:
select * from students where data_json LIKE '%"status":%'
... however, like most cases where you attempt text pattern matching on structured data this is in general a terrible idea that will bite you. Just a couple of problem examples:
{
"somekey": "the value is \"status\": true"
}
... where "status": appears as part of the text value and will match even though it shouldn't, and:
{
status : "blah"
}
where status has no quotes and a space between the quotes and colon. As far as JavaScript is concerned this is the same as "status": but it won't match.
If you're trying to find fields within json or extract fields from json, do it with a json parser. PL/V8 may be of interest, or the json libraries available for tools like pl/perl, pl/pythonu, etc. Future PostgreSQL versions will have functions to get a json key by path, test if a json value exists, etc, but 9.2 does not.
At this point you might be thinking "why don't I use regular expressions". Don't go there, you do not want to try to write a full JSON parser in regex. this blog entry is somewhat relevant.