mvextensions
[FEATURE] Auto-detect and set BASIC language
Other languages rely on a file extension to determine the language. With BASIC we have no such common conventions. Examples:
- foo.java
- bar.cs
- baz.php
This is a proposal to auto-detect BASIC code.
There are two ways that I know of which can be used.
First, when the workspace includes a recognized file, it can trigger the activation of an extension. So if we include a file like ".mvbasic", this extension would activate, and we could default to opening all files in this workspace with BASIC language handling.
Second, whenever a file/document is opened in a VSCode TextEditor object, an event is fired. We can hook that event and use a function to determine if the file is a BASIC program. Avoiding random scans for words like COMMON, CRT, PRINT, READ, GOSUB, etc, I propose we standardize on using a comment as a definitive marker. So for example if the text * MVBASIC is found anywhere in the document, then we can assume it's a BASIC program.
The first option is the simplest and requires almost no effort from the user/developer. However it does clutter the workspace with an extra file, which may not be desirable for some.
The second option is best for one-off programs that get loaded, outside the context of an entire workspace. So if you drag/drop a program from anywhere, or load via FTP, etc, it will be recognized. This is also helpful if coding is coming from two different environments - language processing should be specific to the document currently active - the text inside a document should override the workspace spec.
Because both of these options have merit, I think both should be implemented.
Further, it would help to have an automated way to select the MVBASIC dialect for a code module. Again, this can be done at the workspace level, looking for files named .uvbasic, .qmbasic, .d3basic, etc. And for in-program cues: * UVBASIC ... * QMBASIC etc.
If this is approved, unless someone else wants to tackle it, I think I can handle it.
If this functionality is already included. OOPS! Sorry! :face_with_head_bandage: :laughing:
95% of what I edit are Basic files, so my settings.json has:
"files.associations": {
"*.py": "python",
"*.sql": "sql",
"*.txt": "plaintext",
"*": "mvon"
},
So if it's not explicitly something else, for me it's BASIC ;_) It's also a quick "Ctrl-K M, mv ENTER" away too, usually after the first save...
I would prefer cluttering the workspace with an extra file - for my usage that would be a one-time event, and I have other settings files that do the same (e.g. sftp). The idea of the comment strings reminds me of emacs mode selection comments (https://www.gnu.org/software/emacs/manual/html_node/emacs/Choosing-Modes.html#Choosing-Modes) which have always seemed really ugly to me. I don't like having to put that in every program.
For the dialect question, isn't a third option to have a dropdown in the settings? That would be fine for most people that don't edit code for multiple systems regularly, but I can see why folks that support multiple platforms might prefer the comment.
Re: the dialect/flavor selection, see #14. The idea at the moment is to make the flavor selection a configuration setting for the extension, which would mean you'd be free to set globally or at the workspace level. The big impediment at the moment is that some of the language specification occurs within the package.json file and we'll need to find a way to extract that to the server.ts to load it dynamically. It boils down to how you go about registering languages with VS Code, and the trick here is that we're registering one language, "MultiValue Basic", but leaving significant elements of that language up to a dynamic configuration.
FWIW: There are a handful of BP files in our application, and it was easy to add their names and associations to the files.associations section of my settings.json file. This way I don't need extensions on the BASIC program file names and I don't have to associate all files without extensions to mvbasic.
Hand-crafting file.associations is a one-off solution, can't be a standard. If that's the solution, we can write a program that loops through a BP file to generate a huge JSON config.
When VSCode loads a file, it fires an event on the TextEditor object, passing the document and its ID as parameters. Using these we/I can code different kinds of logic and then users can select their choice of file detection method(s).
@ianmcgowan I wouldn't ask colleagues to do anything to all of their code items. I was suggesting that the inline marker is just one option from which someone could choose if it suits their purposes. The workspace file is another option, and both can be used if desired.
As I think about it, this ticket is pretty much a duplicate of #14, but it's a specific proposal to solve that problem. I might create a branch for this ticket as a POC, and if the solution is acceptable then we can apply it to the other ticket to close that one. Otherwise, if there are Other solution options, like manipulation of the file.associations, maybe we can discuss them with up/down voting and possibly processing in other tickets. It's FOSS, multiple solutions are the norm. :)
@MVDBMS-Solutions Wrote,
If that's the solution, we can write a program that loops through a BP file to generate a huge JSON config...
The config file just needs the names of the BP Directories (in Pick-speak, files) not the names of the Pick records (linux file names) -- I hope that's clear.
Just a note that I edited the above post to fix a formatting issue with the block quote. The quote and reply should display better now.
As mentioned previously, this is configured in the workspace and a default can be applied to ALL files that are opened without an associated file type. As an example, the workspace configuration would have the following: "file.associations": { "*": "mvbasic"}
as covered in section 5.9 of the documentation. The current revision of the documentation still refers to mvon as the extension type but that will be corrected in the next release.
That's a good option for those who want it. But I open a LOT of files outside of MV that don't have standard extensions, and I do NOT want them linted as mvbasic by default.
This extension needs to be a friendly citizen in an ecosystem of other extensions and developer preferences. It should not assume that all development is MV-centric. So really, it should not load immediately as a global extension, consuming memory when a developer is working on something completely unrelated to MV. I plan to submit that as another ticket later. It should, optionally, only be active when called upon - like any other well-behaved application.
This is why I'm proposing ways for us to tell the plugin what we want to do, rather than it making assumptions. Again, i know how to do this stuff, and I'm talking about adding options from which a user can select, not trying to limit options or remove anything that's already in place.
I found a vscode issue discussing this issue.
https://github.com/Microsoft/vscode/issues/23873
It mentions a "firstline" feature that could probably handle subroutines and "defined" programs via line 1: https://github.com/Microsoft/vscode/blob/2f76c44632b0d47ba97f66fbc158c763628e30b3/extensions/python/package.json#L13
Final references are to this issue: https://github.com/microsoft/vscode/issues/1800
It appears the final solution was a "API" option. I haven't had time to read deeper into it.
The solution is simple? I overcome it by including the entire directory or BP file:
"files.associations": {
"**/*.BP/*": "mvbasic",
"**/*.SB/*": "mvbasic",
etc.
Yes, for many users that works perfectly well and is recommended. My own system is defined as:
"files.associations": { "**/BP/*": "mvbasic"},
However, the original proposal is some type of auto-detection based on either a set of adopted file extensions (.mvbasic, .d3, .jbase, .bas, etc) and/or the contents of the file being edited. As discussed above, there are pros and cons.
I do this the other way around - 90% of what I edit are basic files with no extensions, and the other 10% do have an extension so:
"files.associations": {
"*.html": "html",
"*.js": "javascript",
"*.json": "json",
"*.md": "markdown",
"*.sql": "sql",
"*.ts": "typescript",
"*.txt": "plaintext",
"*.yml": "yaml",
"*": "mvbasic"
},
On Thu, Apr 23, 2020 at 2:05 PM Kevin Powick [email protected] wrote:
Yes, for many users that works perfectly well and is recommended. My own system is defined as:
"files.associations": { "**/BP/*": "mvbasic"},
However, the original proposal is some type of auto-detection based on either a set of adopted file extensions (.mvbasic, .d3, .jbase, .bas, etc) and/or the contents of the file being edited. As discussed above, there are pros and cons.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mvextensions/mvbasic/issues/38#issuecomment-618670305, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADD3D3FBUQQLMLSURZWWG3ROCUSBANCNFSM4IZTU24Q .