Closed BZngr closed 11 months ago
The comments regarding non-vbide clients have made me start to think that the IWorkspaceInfo
interface is perhaps better named the IDotRdFolder
interface. The host document path is essential to defining the .rd
configuration for the vbide client, but non-essential for other clients.
Within a DotRd Filesystem
(a new term), the Workspace Filesystem
root is the 'Saved' folder Uri
. A non-vbide client should only care about the Workspace Filesystem
Uri
.
Admittedly, the above defers answering the question of how a non-vbide client connects to the Workspace FileSystem
. But, changing the interface name removes the reasonable interpretation that all clients are expected to know the host document Uri
in order to access the Workspace Filesystem
.
So, I'm proposing to change the IWorkspaceInfo
interface name to IDotRdFolder
:
As a result of changing the interface name, the PR would become specifically about:
DotRd FileSystem
for a vbide client WorkspaceFolder[]
to support server initialization.BTW: I'm open/hoping for alternative suggestions for the terms IDotRdFolder
and DotRd Filesystem
. That said, the names are fairly specific and descriptive.
Related to #25
Contains classes and functions to setup the
.rd
folder structure for RD3 based on #37 discussion.Calling WorkspaceService.SetupDotRdFolder(...) for an Excel host document located at
C:\MyExcelStuff\KillerApp.xlsm
results in creating the following folder structures:C:\MyExcelStuff\.rd\KillerApp_xlsm\WorkspaceFolders\Saved
C:\MyExcelStuff\.rd\KillerApp_xlsm\WorkspaceFolders\Working
There are two classes:
WorkspaceInfo.cs
defining anIWorkspaceInfo
interface that exposes readonly host document properties andIDirectoryInfo
objects related to key Workspace folders.WorkspaceService.cs
contains a function to create the Workspace file system and a function that almost creates aWorkspaceFolder[]
:public static void SetupDotRdFolder(IWorkspaceInfo wsInfo)
and,public static (string Name, string Folderpath)[] GetWorkspaceFolderTuples(IWorkspaceInfo wsInfo)
GetWorkspaceFolderTuples(IWorkspaceInfo wsInfo)
returns a(string, string)[]
rather than aWorkspaceFolder[]
. This is because (AFAICT) the only option to create aOmniSharp.Extensions.LanguageServer.Protocol.Models.WorkspaceFolder
is as follows:This creation/initialization syntax requires C# 9.0 or greater because the
WorkspaceFolder.Name
property is defined aspublic string Name { get; init; } = null;
which uses an 'init-only' setter. (Same is true forWorkspaceFolder.Uri
). Using C# 9.0 looks like it requires .Net 5.For now, the
WorkspaceService
functions are allpublic static
though I expect the declarations should change when the classes/functions are integrated into the Initialize process. Also, since theClient
kicks off the initialization process (AIUI), the classes are located in theRubberduck.Client.LSP
project - they may belong elsewhere.