Hi Brett,
I'll give some further context to what we are doing at CDS.
Our product's repository contains a lot more than just IRIS objects and it is entirely feasible that a developer can spend days working in C# without opening VSCode. Rather than insisting that developers open VSCode specially and Import and Compile all routines and classes every time the developer does a git checkout or git pull (anything that affects the repo files), we created hooks to automate the process.
The reason we chose Git hooks were threefold. Firstly, we have approximately 15,000 IRIS routines and classes. It takes several minutes to import and compile ALL of these files. A Git hook is clever enough to know which specific files have changed, and can just import and compile them.
Secondly, we have many routines and classes which, when saved, need to trigger something else to be built - like a mini install process. Say a developer is making changes to routine A, the developer will be happy enough to manually trigger the install process. But when routine A is committed to the repo and other developers start to pull the routine, it felt impractical to ask developers to remember to run the same install process.
Thirdly, we need to import routines before classes. This is because some of our classes are dependant and won't compile until the mini install process I mentioned above have ran first.
I'd love nothing more than to be able to just use the VSCode extension to keep our IRIS objects in sync with the file system, but as I've said, a lot of our developers won't even have VSCode open if they're developing new features solely in C#. And because we can't run our mini install processes as routines are changing, we are finding that classes won't compile.
Hopefully this explains why having VSCode monitor the file system for changes won't work for us. As Michael has mentioned, I think we need the setting to control whether saving a file within VSCode automatically imports and compiles, and an independant setting to control whether file system changes outside of VSCode automatically import and compile.
One other problem we found in testing was that the VSCode extension is opening files with exclusive locks. This causes the Git hooks to not be able to read the changed files. Even if we could just use VSCode to get around this problem, the dilema we have is that we can't turn off using our Git Hooks as VSCode won't always be running.
Mat
Hi Brett, thanks for getting back to me with an answer. As we have thousands of routines containing dot syntax I couldn't really leave this without a solution. For now we've built our own simple extension to implement OnTypeFormattingEditProvider. See https://vshaxe.github.io/vscode-extern/vscode/OnTypeFormattingEditProvider.html.
In our case all the method implementation needs to do is look at the previous line, assess how many dots the line begins with and populate the same on the new line. I can appreciate the difficulty you'll have with making this work for all scenarios in Object Script though.
Thanks Brett