rubberduck-vba / Rubberduck3

COM add-in for the VBIDE
GNU General Public License v3.0
89 stars 17 forks source link

Create an RD3 workspace folder structure #69

Closed BZngr closed 11 months ago

BZngr commented 1 year ago

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 an IWorkspaceInfo interface that exposes readonly host document properties and IDirectoryInfo objects related to key Workspace folders.

WorkspaceService.cs contains a function to create the Workspace file system and a function that almost creates a WorkspaceFolder[]:

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 a WorkspaceFolder[]. This is because (AFAICT) the only option to create a OmniSharp.Extensions.LanguageServer.Protocol.Models.WorkspaceFolder is as follows:

new WorkspaceFolder()
{
     Name = $"{<Host Document Name>}(Saved/Working)",
     Uri = <DocumentUri created from workspace folder path>
},

This creation/initialization syntax requires C# 9.0 or greater because the WorkspaceFolder.Name property is defined as public string Name { get; init; } = null; which uses an 'init-only' setter. (Same is true for WorkspaceFolder.Uri). Using C# 9.0 looks like it requires .Net 5.

For now, the WorkspaceService functions are all public static though I expect the declarations should change when the classes/functions are integrated into the Initialize process. Also, since the Client kicks off the initialization process (AIUI), the classes are located in the Rubberduck.Client.LSP project - they may belong elsewhere.

BZngr commented 1 year 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:

  1. Generating the DotRd FileSystem for a vbide client
  2. Exposing a function to provide the necessary data for the vbide-client to create a 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.