Closed itsxallwater closed 5 years ago
Mike, Attached is a first pass of the jBASE version of the MVON Language file, in a zip, as JSON is not accepted.
There is a lot more to add, so I will be continuing with index number 78 onwards, probably in alphabetic order.
Mike
@mikes-zum this looks great so far! If you're feeling adventurous, as you get closer let me know if you'd like to submit the finished product as a pull request and I can help walk you through that.
Also to anyone following along, I played with GitHub comments and I've worked out how to inline JSON (or any code/text) and also put it behind a collapsible section so if that's of interest to anyone let me know and I'll post a peek behind the curtain.
Attached is a complete jBASE syntax file, currently without any "jabba" bits. It may need some more work, but is mostly complete.
How would I modify the MVON extension to use this syntax, or should I just use it to replace the MVON one for now?
Excellent, thanks @mikes-zum!
As far as using this new syntax, #14 sets the tone for what we'll be looking for to make this configuration driven. But yes for local usage if you wanted to override for now it would be a matter of replacing the \mvbasic\client\Syntaxes\MvLanguage.json
file with this one.
An updated version of the jBASE syntax with a TRIMS() function definition added.
Is the syntax being used correct? While the suggestions appear in Intellisense, they do not work like other languages. I've attached a screenshot of using the PHP function str_replace and how Intellisense works vs the above Iconv. Notice how the function helper stays on screen and finished the parenthesis during typing while it disappears and does not autocomplete with Iconv.
If there's no opposition, I'd like to go through and make some of the function details more useful. Example: Current Iconv Detail: ICONV(expression1, expression2) Suggested Iconv Detail: ICONV(subject, convCode)
Lastly, is there a reason the keys are in title case as opposed to upper case?
Hey @andrewcole50! Thanks for stopping by, extremely happy to have you joining the conversation here.
On the IntelliSense front, you're absolutely correct. We'll take a look at what can happen to cause the helper to stay until the entirety of the syntax that was matched is received.
On the function details, we're going to try to keep those definitions as standard to the documentation for the respective flavor of Pick for the purposes of the extension. That said, as we're in the thread for jBASE syntax I could see cause to improving even the jBASE documentation to inform on the parameters of the function in the manner you're suggesting. We happen to have one of the principal resources responsible for jBASE documentation contributing to the syntax and language definitions for this very ticket, @mikes-zum, so I'd like to get his opinion on adapting any of those changes.
Worst case, when push comes to shove and you find that the standard documentation can't/won't be amended for a language, we have hooks in the extension to allow you to configure custom word/definition value pairs. If that's not feature complete for the objective of customizing language definition, the important takeaway is that we're aiming to provide that customization ability for end users in these scenarios where what is the official provision is not precisely what you'd like.
Speaking on the casing, there is a setting in the config for using Camel Case for IntelliSense keywords. I'd ask you to try flipping that and reporting back on whether or not it resolves your scenario.
Again, thanks for taking the time to come and ask some great questions! I love seeing the community interaction!
On the function details, we're going to try to keep those definitions as standard to the documentation for the respective flavor of Pick for the purposes of the extension.
I would say that sounds like a great goal to work towards. Once that goal is completed I would suggest that the project should work towards either improving the upstream flavor's documentation (as it looks like we're going to do with Jbase =D ) or if that's not possible, fixing them within this project anyways in order to have a more useful and intuitive intellisense.
I took a little bit of time and went through JBC's docs and picked out the ambiguous function examples for functions I was familiar with. I've pasted the original and then my suggested replacements. I wanted to put these here so Mike would see them and can look them over and decide what to implement (if any) and to help get his gears working if some of my suggestions could be better.
CONVERT(expression1, expression2, expression3) => CONVERT(subject, search, replace)
COUNT(expression1, expression2) => COUNT(subject, delim)
DCOUNT(expression1, expression2) => DCOUNT(subject, delim)
EXTRACT(expression1, expression2 {, expression3 {, expression4}}) => EXTRACT(dyn.arr, field.num {, value.num {, subvalue.num}})
GROUP(Expression1, Expression2, Expression3, Expression4) => GROUP(string, delim, occurrence, extractCount)
INDEX(expression1, expression2, expression3) => INDEX(string, search, occurrence)
ICONV(expression1, expression2) => ICONV(subject, conv.code)
INSERT(expression1, expression2{, expression3 {, expression4 }}; expression5) => INSERT(dyn.arr, attr{, val {, subval }}; new.elem)
INPUT {@ (expression1 {, expression2 )}{:} Var{{, expression3}, expression4} {:}{_} {WITH expression5} {FOR expression6 THEN|ELSE statements} => INPUT {@ (col {, row )}{:} Var{{, length}, expression} {:}{_} {WITH delim} {FOR deciseconds THEN|ELSE statements}
LOCATE expression1 IN expression2{<expression3{,expression4}>}, {, expression5} {BY expression6} SETTING Var THEN|ELSE statement(s) => LOCATE string IN subject{<attr{,val}>}, {, field} {BY sort.exp} SETTING Var THEN|ELSE statement(s)
LOCATE(expression1, expression2{,expression3{,expression4}}; Var{; expression6}) THEN|ELSE statements => LOCATE(string, subject{,attr{,val}}; Var{; sort.exp}) THEN|ELSE statements
OCONV(expression1, expression2) => OCONV(subject, conv.code)
OPENPATH expression1 TO {variable} {SETTING setvar} THEN|ELSE statements => OPENPATH filepath TO {variable} {SETTING setvar} THEN|ELSE statements
READV variable1 FROM { variable2,} expression1, expression2 {SETTING setvar} {ON ERROR statements} {THEN|ELSE statements} => READV variable1 FROM { filevar,} record.key, attr {SETTING setvar} {ON ERROR statements} {THEN|ELSE statements}
READU variable1 FROM {variable2,} expression {SETTING setvar} {ON ERROR statements} {LOCKED statements} {THEN|ELSE statements} => READU variable1 FROM {filevar,} record.key {SETTING setvar} {ON ERROR statements} {LOCKED statements} {THEN|ELSE statements}
READVU variable1 FROM { variable2,} expression1, expression2 {SETTING setvar} {ON ERROR statements} {LOCKED statements} {THEN|ELSE statements} => READVU variable1 FROM { filevar,} record.key, attr {SETTING setvar} {ON ERROR statements} {LOCKED statements} {THEN|ELSE statements}
STR(expression1, expression2) => STR(string, int)
SWAP(variable, expression1, expression2) => SWAP(subject, search, replace)
TRIM(expression1 {, expression2{, type}}) => TRIM(subject {, remove{, type}})
WRITE variable1 ON|TO { variable2,} expression {SETTING setvar} {ON ERROR statements} => WRITE variable1 ON|TO { filevar,} recordkey {SETTING setvar} {ON ERROR statements}
WRITEU variable1 ON|TO { variable2,} expression {SETTING setvar} {ON ERROR statements} => WRITEU variable1 ON|TO { filevar,} recordkey {SETTING setvar} {ON ERROR statements}
WRITEV variable1 ON|TO {variable2,} expression1, expression2 {SETTING setvar} {ON ERROR statements} => WRITEV variable1 ON|TO {filevar,} recordkey, attr {SETTING setvar} {ON ERROR statements}
WRITEVU variable1 ON|TO { variable2,} expression1, expression2 {SETTING setvar} {ON ERROR statements} => WRITEVU variable1 ON|TO { filevar,} recordkey, attr {SETTING setvar} {ON ERROR statements}
I really like where you're going with this @andrewcole50! I'm going to bring this up internally because I think you've done a lot of fantastic legwork on this and it'd make a lot of sense for us to adopt.
Changes have been incorporate and will be promoted in next publish to the marketplace.
Is your feature request related to a problem? Please describe. Currently, the
client\Syntaxes\MvLanguage.json
file contains MVON# Basic syntax. We are looking to include jBASE syntax out of the box to have available as an option within the extension.Describe the solution you'd like An acceptable pull request for this issue would include a jBASE version of the MvLanguage.json file that can be included in the base package. This pull request need not concern itself with any of the plumbing for the extension to be able to dynamically load that syntax into place, we're simply looking for the syntax definition here.