Github-Pages rendering at rubberduck-vba.github.io
rubberduck-vba / rubberduck3 Goto Github PK
View Code? Open in Web Editor NEWCOM add-in for the VBIDE
License: GNU General Public License v3.0
COM add-in for the VBIDE
License: GNU General Public License v3.0
Hi, Quick issue I will close soon
I'm trying to use this website https://sqliteonline.com/ to view the .db file https://github.com/rubberduck-vba/Rubberduck3/blob/main/Server/Database/Rubberduck.db. I want to know the schema of the db and just view how it is structured. I am able to view the tables but not the Views. The views I guess are higher level structures than the raw tables. If I use
SELECT * From Projects_v1
I get an error that the ID column is ambiguous.
Maybe we are not using the same flavour of SQL it expects? Any tips for viewing that file?
UI work to do around the Rubberduck Editor main window, at a high level.
Initializes LSP server (client: addin process)
Initializes VBA LSP client
Initializes JSON LSP client
Accepts workspace root and client process id as command-line arguments
Can load settings from file
Selectable/dynamic theming (JSON)
Docking panels (side, bottom)
Tooltabs
Document/editor tabs
Status bar UI
Menu bar UI
Floating/undocked document windows
Floating/undocked toolwindows
Base toolwindow UI ("ThunderFrame")
Document tab templates
MessageBox dialog +service
New Project dialog
Workspace Explorer toolwindow
Code (Project?) Explorer toolwindow
Settings dialog
Language Server toolwindow
Update Server Toolwindow
About dialog
Rubberduck needs a way to access the "dead code" tokens from the pre-compilation parse pass.
That way we could access the different possible declarations of a given definition (RD got 'em backwards I think), and thus support the LSP "definition" (or "declaration"?) requests.
Rubberduck 2.x assumed to be working with compilable code at all times, and would bail otherwise.
Rubberduck 3.0 reports syntax errors instead, so we get to analyze error nodes and still work out the identifier names here:
#If True Then
Sub DoSomething(ByVal Value As Long)
#Else
Sub DoSomething(ByVal Value As Variant)
#End If
'...
End Sub
There might be a way to recover these nodes as some ConditionalCompilationDeadCodeContext
, or to otherwise have a way to suppress the conditional compilation related "syntax errors" - so they don't consistently appear with red squiggles in the Rubberduck Editor. The error handler already filters some specific syntax errors to issue specific error messages, it's wouldn't be impossible to achieve the desired result via syntax errors.
Having this information also allows the LSP server to mark that code as "unreachable" for formatting purposes, so the editor can (should) render it dimmed/fainted. It also gives us multiple navigable definitions for that DoSomething
procedure and Value
parameter`. Only one of these definitions is ever "live", so identifier resolution and the semantic layer wouldn't necessarily need major tweaks to support this, I think.
Upon initialization, add-in client should set up a virtual workspace that can have virtual folders. Loaded documents should be in this virtual namespace when working in-memory.
Service needs to:
Load
and Unload
methods to synchronize the documents loaded in the workspace to and from the VBIDEImport
and Export
methods to synchronize the workspace with a physical folder in the file system (host document must be saved).FileSystemWatcher
to synchronize content.CreateFolder
, RemoveFolder
, and RenameFolder
methods.CreateFile
, RemoveFile
, and RenameFile
methods.The abstract interface IWorkspaceService
should be defined under Rubberduck.Client
and implemented under Rubberduck.Server.LSP
.
The document change notification is sent from the client to the server to signal changes to a text document. Before a client can change a text document it must claim ownership of its content using the
textDocument/didOpen
notification.
The notification sends an array of TextDocumentContentChangeEvent
objects, each representing a distinct change of state for a specific Range
in a given version of a given document. Client may send the full document every time, or send incremental edits (let's start with full-document only for now).
The editor may send didChange
notifications on an idle timer - that is, whenever the user stops typing for a certain (configurable) amount of time.
Alternatively (through editor settings), the user might prefer sending this notification manually; the editor UI should expose a command to do so - the flow is then similar to Rubberduck 2.x, where the parser state is manually refreshed; the command should send a content changed event for each document that was modified since the last synchronization.
👀 Follows Client console GUI app
Design a XAML control to be loaded into a settings tab in the LocalDb client console application, to be reused in the Rubberduck settings dialog.
LocalDb settings include server and console settings that are shared with other RPC servers; the UI for these settings should be implemented in separate XAML controls that can be reused for the LSP server settings. LocalDb-specific settings are yet to be determined.
OwnerProcessId
column to Projects
table (nullable int)Phase I
Phase II
Phase III
The document open notification is sent from the client to the server to signal newly opened text documents. The document’s content is now managed by the client and the server must not try to read the document’s content using the document’s Uri. Open in this sense means it is managed by the client. It doesn’t necessarily mean that its content is presented in an editor. An open notification must not be sent more than once without a corresponding close notification send before. This means open and close notification must be balanced and the max open count for a particular textDocument is one. Note that a server’s ability to fulfill requests is independent of whether a text document is open or closed.
The server receives a TextDocumentItem
with the notification:
interface TextDocumentItem {
/**
* The text document's URI.
*/
uri: DocumentUri;
/**
* The text document's language identifier.
*/
languageId: string;
/**
* The version number of this document (it will increase after each
* change, including undo/redo).
*/
version: integer;
/**
* The content of the opened text document.
*/
text: string;
}
So this is where the server receives the text
of the document at a given version
. The languageId
should be vba
, to avoid clashing with "VB.NET" vb
. The uri
points to a path relative to the workspace root.
The string contains the complete file contents, including headings and attributes that are hidden in the VBIDE, so that's what we want to parse, and we'll want to quickly get a parse tree for it, cache it with the document uri
and version
as a key... and then sit on it for now - eventually the LSP server is going to send various notifications to the client, and we'll want to launch a semantic pass over all the parse trees and declarations, so having a parse tree associated to a specific version of a document URI is a very good starting point.
This supposes something is holding this state in some (thread-safe) dictionary: we'll need to inject a service that's responsible for just that.
TextDocumentItem
to a parse tree, and to retrieve a parse tree for a given document URI and versionTextDocumentItem
.DidOpenHandler
class
OmniSharp.Extensions.LanguageServer.Protocol.Document.DidOpenTextDocumentHandlerBase
; constructor-inject state serviceHandle
override; access the document from the request
parameter (DidOpenTextDocumentParams
).CreateRegistrationOptions
override (specify DocumentSelector
filters)Log successful execution of the handler at INFO
level; exceptions can be caught, but must be rethrown to return an error result at the JSON-RPC level.
Workspace client-to-server RPC endpoints include the following requests/methods:
workspace/configuration
)workspace/didChangeConfiguration
)workspace/executeCommand
)⚠ Note: in LSP "file" refers and applies to both files and folders.
workspace/didChangeWatchedFiles
)workspace/workspaceFolders
)workspace/didChangeWorkspaceFolders
)workspace/willCreateFiles
)workspace/didCreateFiles
)workspace/willRenameFiles
)workspace/didRenameFiles
)workspace/willDeleteFiles
)workspace/didDeleteFiles
)workspace/diagnostic
)workspace/symbol
)workspaceSymbol/resolve
)The will rename files request is sent from the client to the server before files are actually renamed as long as the rename is triggered from within the client either by a user action or by applying a workspace edit. The request can return a WorkspaceEdit which will be applied to workspace before the files are renamed. Please note that clients might drop results if computing the edit took too long or if a server constantly fails on this request. This is done to keep renames fast and reliable.
The handler for this request should evaluate whether workspace edits should be applied before the files are created, and promptly return them if that is the case. The cancellation token should be checked regularly to throw if cancellation was requested.
A first iteration is probably perfectly fine with simply returning null
.
File I/O operations (esp. file watchers) should always run in the client-side process, because a client is allowed to connect to (/own) multiple servers, and multiple processes trying to own the same file/folder is a scenario we'd like to avoid for the same reasons the SQLite database also runs in its own process.
We need to implement a service that the add-in client (commands invoked from the server->client RPC endpoints) will call to create, rename, and delete files and folders as per LSP specifications.
TODO document the relevant specs here
Hello
I have a question regarding the usage of Rubberduck for Apple macOS M1/M2.
It would be great, when this plugin could also be used on these operating systems. The current version supports only x86/x64 and the installation is not possible (also when hosting Windows 11 within a virtual machine).
Are you planning to support this? If yes, do you have already a timeline?
Many thanks for a response!
The
workspace/workspaceFolders
request is sent from the server to the client to fetch the current open list of workspace folders. Returnsnull
in the response if only a single file is open in the tool. Returns an empty array if a workspace is open but no folders are configured.
Where WorkspaceFolder
is defined as follows:
export interface WorkspaceFolder {
/**
* The associated URI for this workspace folder.
*/
uri: DocumentUri;
/**
* The name of the workspace folder. Used to refer to this
* workspace folder in the user interface.
*/
name: string;
}
Scope:
Rubberduck.Core
add-in client must define a service that holds client-side workspace state.Rubberduck.Client
library must define a client-side handler for this request, that returns the folders in the current workspace.The did create files notification is sent from the client to the server when files were created from within the client.
Server should store the provided URI to synchronize workspace state.
The did rename files notification is sent from the client to the server when files were renamed from within the client.
Server should update the file/folder URI as per the given FileRename
info.
col-md-6
)The will create files request is sent from the client to the server before files are actually created as long as the creation is triggered from within the client either by a user action or by applying a workspace edit. The request can return a WorkspaceEdit which will be applied to workspace before the files are created. Hence the WorkspaceEdit can not manipulate the content of the files to be created. Please note that clients might drop results if computing the edit took too long or if a server constantly fails on this request. This is done to keep creates fast and reliable.
The handler for this request should evaluate whether workspace edits should be applied before the files are created, and promptly return them if that is the case. The cancellation token should be checked regularly to throw if cancellation was requested.
A first iteration is probably perfectly fine with simply returning null
.
The data access layer operates with an internal model that essentially mirrors the database storage. This is great for CRUD operations, but the rest of Rubberduck would rather work with a rich internal API and declaration model: there needs to be a service layer between the data access (CRUD) and the LocalDb clients (i.e. LSP server instances, mostly) that the LocalDb server RSP endpoints can invoke using the deserialized endpoint parameters.
The custom dialog (a WPF user control that will probably end up hosted in a WPF/XAML popup) should feature a collapsible "details" area, as well as a "don't show this message again" checkbox. This UI will be used by the command that responds to window/showMessage
notifications and window/showMessageRequest
, notably.
The message text content should scroll vertically when too tall. The dialog can expand a "more information" section, and there should be a checkbox to remember the user's response to a prompt.
Buttons and their caption should be driven by the view model; the right-most button should be the ostensibly default option. Key bindings should attach ENTER to the default command, and ESC should dismiss/cancel the dialog/prompt.
In order to "remember" whether or not to display a prompt, each prompt should have an ID (or unique name?). User settings should then store the prompt result alongside the prompt ID, but this storage logic is beyond the scope of this issue.
Implement the client-side handlers for window/showMessage
notifications and window/showMessageRequest
requests.
The show message notification is sent from a server to a client to ask the client to display a particular message in the user interface.
In these cases the client receives a model that includes "message action items" that correspond to buttons, and the MessageType
instructs us about which icon to use next to the title label.
interface ShowMessageRequestParams {
/**
* The message type. See {@link MessageType}
*/
type: MessageType;
/**
* The actual message
*/
message: string;
/**
* The message action items to present.
*/
actions?: MessageActionItem[];
}
interface MessageActionItem {
/**
* A short title like 'Retry', 'Open Log' etc.
*/
title: string;
}
export namespace MessageType {
/**
* An error message.
*/
export const Error = 1;
/**
* A warning message.
*/
export const Warning = 2;
/**
* An information message.
*/
export const Info = 3;
/**
* A log message.
*/
export const Log = 4;
}
export type MessageType = 1 | 2 | 3 | 4;
The show message request is sent from a server to a client to ask the client to display a particular message in the user interface. In addition to the show message notification the request allows to pass actions and to wait for an answer from the client.
The user interface is completed with #19 and should cover every "msgbox" use-case we can anticipate:
If the UI is already completed, the view model should already make it easy to work with from both handlers. The model should be scoped to this issue otherwise.
The watched files notification is sent from the client to the server when the client detects changes to files and folders watched by the language client (note although the name suggest that only file events are sent it is about file system events which include folders as well). It is recommended that servers register for these file system events using the registration mechanism. In former implementations clients pushed file events without the server actively asking for it.
An event-driven mechanism to handle create
, change
, and delete
events for files and folders as they are detected (client-side) on the file system.
This feature should be configurable and optional. Limit the number of watched folders to the active workspace.
The Rubberduck Editor needs an IntelliSense UI that appears relative to the caret position to display signature help.
We don't need to worry about the signature index because no members are ever overloaded in VBA, so we only need to ever accommodate a single signature: even in the context of a property call, once we're showing the signature info we've already worked out whether we're looking at the Get
, Let
, or Set
member.
The tooltip should display the member's docstring, and support tracking the active parameter to show it in bold, and eventually show docstrings for individual parameters. The model comes straight from the LSP server.
There should be a key binding to dismiss the tooltip on ESC, and both showing and dismissing the tooltip should fire an EventTelemetry event.
When the resolver issues a declaration, we need a service to send a save/something
request to the LocalDb server... but that's the easy part.
The implication is that when the resolver later looks for declarations in the DeclarationFinder
, they're not going to be there: each finder query needs to become a hit on LocalDb through JSON-RPC, so we're probably going to want to be smarter than simply requesting things as we go. Perhaps the request parameters and their corresponding results could be cached locally for the duration of a resolver run, and so we could skip repeated RPC calls that fetch the same declaration; such a cache would presumably be cleared upon completion, if it's needed at all.
Once parse trees are collected for all code files in the workspace, the resolver pass can begin identifying all the declarations.
Instead of storing them in DeclarationFinder
state, the LSP server is going to persist the declarations to the Rubberduck.DatabaseServer
managed SQLite database via lower-level Json-RPC calls (LSP builds on top of this).
The client-sided proof-of-concept code produced a ParseTreeListener
that should be relatively easy to tweak to output LSP-compliant FoldingRange
items (only for the active document) instead of AvalonEdit model items - on the client side the LSP items should be converted into the corresponding AvalonEdit objects, and rendered in the active document.
As with all LSP requests, the server operates with the version of the code that is currently synchronized at the moment of the request.
This client app should build on top of the similarly-purposed LocalDb client app, from which common client abstractions should already have been extracted to a namespace under Rubberduck.Client
.
We need a relatively complex xaml control that can beautifully layout a bunch of nested configuration settings.
We get a [Console] tab for free by reusing the LocalDb client app UI abstractions, and we'll be able to override the SettingsCommand
with one of our own.
Only the LSP-specific parts should remain:
MainWindow
In order to ensure a consistent user experience across the different applications, the shared XAML user control should be the only child control in the <MainWindow>
; styles and icons should be imported from the appropriate shared resources libraries (.resx and .png under Rubberduck.Resourcee, anything .xaml is under Rubberduck.UI.Xaml).
Before a rename operation is executed, its impacts are assessed, and the user gets an opportunity to [p]review and skip individual diffs if needed:
The number of locations and modules affected could theoretically reflect the checked items - the OK button should be disabled if none are selected (operation would be no-op).
This is purely client-side functionality: the preview diff literally consists of document edits to be performed.
🔗 Required for: Client console GUI app
Implement base client-side abstractions in the Rubberduck.Client library so that they can be used by all RPC clients:
Server-to-client RPC endpoints include the following requests/methods:
window/logMessage
)window/showMessage
)window/showMessageRequest
)window/showDocument
)window/workDoneProgress/create
)window/workDoneProgress/cancel
)-$/progress
)textDocument/publishDiagnostics
)workspace/codeLens/refresh
)workspace/semanticTokens/refresh
)workspace/inlayHints/refresh
)workspace/diagnostic/refresh
)workspace/applyEdit
)The document close notification is sent from the client to the server when the document got closed in the client. The document’s master now exists where the document’s Uri points to (e.g. if the document’s Uri is a file Uri the master now exists on disk). As with the open notification the close notification is about managing the document’s content. Receiving a close notification doesn’t mean that the document was open in an editor before. A close notification requires a previous open notification to be sent. Note that a server’s ability to fulfill requests is independent of whether a text document is open or closed.
The server should update its internal document state upon receiving this notification, and write log entries as appropriate.
As I was drawing various mock-ups it occurred to me that we're going to want a coherent user interface, and we're going to be constantly reinventing the wheel if we don't do this.
Let's write a XAML user control that will set the tone for all RD3 dialogs and prompts. Something like this:
ViewModel would include:
OptionLabel
and bind OptionLabelText
CancelButton
and bind CancelButtonText
The bare-bones default configuration might look like this:
MessageBoxControl
and any other existing dialogs as a child component of this new control.The language server cannot access COM libraries directly from the VBIDE process - the client must send a command to the server, passing it the serialized ProjectReference
items. The handler for that command can then load the library on the server side and retrieve the declarations: the RD2 code for this should be reusable as-is.
Once the declarations are retrieved, the server should send a Save
notification to the database server using IJsonRpcServer
.
ProjectReference
items from the client
JsonRpcMethods.Database
method names to notify the database serverRD3 will operate from a folder hierarchy of exported module files as the 'source of truth' for the VBA code base. There have been numerous discussions in the Discord 'rubberducking' channel regarding how the RD3 Filesystem
should work. This Issue is created in an attempt to capture and collate past and future 'Decisions', 'Open Topics', and 'Use Cases' surfaced during the discussions.
Over time, the hope is that this Issue contains sufficient criteria and Use Cases to help facilitate the initial implementation.
Edited 3/13/2023.
Filesystem Setup
: The interactive process of creating a valid RD3 environment for a new or existing host documentFilesystem Initialization
: Evaluates the Filesystem of the active host document.Filesystem Synchronization
: The initialization and design-time processes needed to maintain the host document modules consistent with the "./src" file(s) content.Filesystem Host Folder
: The folder containing the host document of interestFilesystem Code Folder
: The folder containing the code files of interest to the LSP. The Filesystem Code Folder
and the Filesystem Host Folder
can be the same folder.Filesystem Code Folder
name will be "./src" when the Filesystem Code Folder
is a direct child of the Filesystem Host Folder
.Filesystem Setup
View(s) assisting the user to establish a valid RD3 Filesystem for a host documentFilesystem Initialization
: Detection and Handling of duplicate file names encountered in the folder hierarchy.Filesystem Setup
: Introduce project-scope settings (and/or Filesystem Setup
settings?):Filesystem Setup
preferencesFilesystem Code Folder
names other than "./src"Use Case I: Filesystem Setup
: User's initial use of RD3 starting from an RD2 project
1. RD3 provides `Filesystem Setup` View(s) to .
2. @Folder annotations are evaluated to generate a folder structure starting at the `Filesystem Code Folder`
a. Files without an @Folder annotation are saved in the `Filesystem Code Folder`
b. Filesystem is synchronized to match host document module content
1) Unresolved - handling of @Folder annotations after the creation of the folder hierarchy:
i) Ignore @Folder annotations in the future. (Disable @Folder related inspections?)
ii) Auto-update @Folder annotations based on actual file locations in the future.
iii) Make i) and ii) a user choice in `Filesystem Setup` settings
3. Optional(future): Based on choice of implementing #2 above, Prompt user to remove @Folder annotations
4. If Folder options become a `Filesystem Setting` per 2.b.iii above, re-apply/remove Folder annotations when the user toggles the setting ('Maintain Folder Annotations : boolean' ?).
Use Case II: Filesystem Setup
: User's initial use of RD3 starting from multiple RD2 projects stored in the same folder
1. Provide `Filesystem Setup` dialog assisting the user to specify/create a valid RD3 Filesystem
2. Invoke `Filesystem Initialization`
Use Case III: Filesystem Initialization
: User opens a host document that has been moved/copied
1. Valid RD3 Filesystem is found: Create folders and files accordingly.
2. Valid RD3 Filesystem is NOT found: Invoke `Filesystem Setup` dialog/process and `Filesystem Initialization`
Use Case IV: Filesystem Synchronization
Files and/or file structure manipulated external to RD3
1. This Use Case has a better discussion found in Discord.feature-backlog.Workspace Explorer
Edit History
Edited 3/7/2023.
Workspace
with Filesystem
since Workspace
has meaning within the context of a LSPFilesystem Host Folder
and Filesystem Code Folder
Edited 3/5/2023 based on input and comments.
TextDocument client-to-server RPC endpoints include the following requests/methods:
⚠ Note: in LSP "file" refers and applies to both files and folders.
textDocument/didOpen
)textDocument/didClose
)textDocument/didChange
)textDocument/willSave
)textDocument/willSaveUntil
)textDocument/didSave
)textDocument/declaration
)textDocument/definition
)textDocument/typeDefinition
)textDocument/implementation
)textDocument/references
)textDocument/codeLens
)codeLens/resolve
)textDocument/documentLink
)documentLink/resolve
)textDocument/prepareCallHierarchy
)callHierarchy/incomingCalls
)callHierarchy/outgoingCalls
)textDocument/prepareTypeHierarchy
)typeHierarchy/supertypes
)typeHierarchy/subtypes
)textDocument/rename
)textDocument/prepareRename
)textDocument/diagnostic
)textDocument/codeAction
)codeAction/resolve
)textDocument/moniker
)textDocument/documentSymbol
)textDocument/semanticTokens
)textDocument/semanticTokens/full
)textDocument/semanticTokens/full/delta
)textDocument/hover
)textDocument/completion
)completionItem/resolve
)textDocument/signatureHelp
)textDocument/foldingRange
)textDocument/highlights
)textDocument/formatting
)textDocument/rangeFormatting
)textDocument/onTypeFormatting
)textDocument/documentColor
)textDocument/colorPresentation
)textDocument/selectionRange
)textDocument/linkedEditingRange
)textDocument/inlayHint
)inlayHint/resolve
)🔗 Depends on: Implement base client abstractions in Rubberduck.Client
A small standalone executable that will serve as a proof-of-concept for client/server RPC communications and lay the groundwork and produce abstractions usable for all RPC clients.
As a client, this application should either find or spawn the server process if it isn't already running: all Server.LocalDb clients should be connecting to the same server instance.
The application should present a tabbed UI with a "console" tab showing the server's trace log output, with commands to pause/resume tracing, set the server's trace level and other configuration settings. A status bar should display server info including name, version, uptime, number of connected clients, and the number of RPC messages sent and received.
A "database" tab should present metadata about each table, including the number of records, and the user should be able to double-click on a table or view item (or click a button) to bring up a data grid presenting/previewing the data, and commands to export the data to various formats, including CSV text files and Excel workbooks.
Aside from the LocalDb-specific tabs, the UI components will be mostly shared between the different client applications.
LocalDbClientService
class that communicates with the LocalDb RPC serverId
property might be configured to be displayed in a bold font, and the actual Message
can be dark red for error-level items and the VerboseMessage
could be shown in italics at the "info" level, but in monospace bright yellow at the "error" level.TimeSpan
value that represents the estimated server uptime and that can be updated locally between the requests.After successfully building the latest main
branch of RD3, I've been unable to successfully launch RD2 (2.5.2).
To Reproduce:
main
in VS2022Avalon
editorRebuilding RD2 does not overwrite/correct these changes
(Edited: removed content that is no longer relevant/accurate)
Implement a prompt based on the MessageBox component, that receives an identifier name from user input in a textbox - mock-up:
DeclarationType
of the symbolMaximum length - module: 31 characters. Anything else: 255 characters (TODO verify in MSVBAL).
The editor shell needs to include a Dragablz container so we can have tear-tabs and docking areas.
I tried doing this early on but the assembly wouldn't load at run-time so I, well, pushed that problem forward 😭
We need to implement the code pane context menu completely from scratch, including the bare-bones stuff like Copy and Paste (surely we want these commands in the Rubberduck Editor 🤔😂).
TODO list a subtask for each command to wire up here
Note: some of these commands would remain no-op (and hidden) until a corresponding LSP server method is actually implemented, i.e. we want to wire up "find references" even if the RPC request for it comes back in error.
Wire up and adjust all the necessary RD2 components to produce an ANTLR parse tree for any module loaded in the workspace.
At this stage we only care about getting a parse tree to provide the editor with syntax errors and folding ranges: we need this parse to remain sub-second and as reliably fast as possible for all module under 5K lines of code (half the maximum allowed). Preliminary in-process tests gave excellent sub-second results for all module sizes.
Technically we could also wire up the parse tree inspections/diagnostics, but for performance reasons these will have to run separately from this quick-parse syntactical pass.
The did delete files notification is sent from the client to the server when files were deleted from within the client.
Server should accordingly synchronize its workspace state.
Finalize and merge the groundwork PR (see #1).
The handlers themselves should go under Rubberduck.Client
, which should have a namespace to keep the workspace handlers together (there will be more workspace handlers to implement in future sprints). Handlers should be injected with interfaces for the services they need, so these services need to have their interfaces in the same assembly, to be implemented under Rubberduck.Server.LSP
.
The will delete files request is sent from the client to the server before files are actually deleted as long as the deletion is triggered from within the client either by a user action or by applying a workspace edit. The request can return a WorkspaceEdit which will be applied to workspace before the files are deleted. Please note that clients might drop results if computing the edit took too long or if a server constantly fails on this request. This is done to keep deletes fast and reliable.
Just return null
for now.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.