DevelopmentNodeEnvironment_MicrosoftVSCodeDependency_22NodeVersion_Bundle_Clean_Debug_ElectronProfile_EsbuildCompiler_Mountain/Vine/Server/Notification/mod.rs
1//! # Vine Cocoon → Mountain Notification Atoms
2//!
3//! One handler per file, file name = the exported function name
4//! (reverse-hierarchical path: `Vine::Server::Notification::<Atom>::<Atom>`).
5//! Each atom encapsulates exactly one wire-method's side effects so the
6//! main `send_cocoon_notification` dispatcher in
7//! `MountainVinegRPCService.rs` stays a thin match that routes into
8//! these files.
9//!
10//! ## Naming
11//!
12//! - Wire string `outputChannel.create` → atom file `OutputChannelCreate.rs`
13//! with `pub async fn OutputChannelCreate(...)`.
14//! - Wire string `unregister_scm_provider` → atom file
15//! `UnregisterScmProvider.rs`.
16//! - Wire string `progress.update` → atom file `ProgressUpdate.rs`.
17//!
18//! Snake_case / dotted wire strings collapse to PascalCase file names.
19//! The function name mirrors the file name verbatim so a grep for
20//! `fn <Name>` lands in exactly one place.
21//!
22//! ## Signature contract
23//!
24//! Every atom takes the same two parameters:
25//!
26//! ```ignore
27//! pub async fn <Atom>(
28//! Service: &MountainVinegRPCService,
29//! Parameter: &serde_json::Value,
30//! );
31//! ```
32//!
33//! - `Service` gives access to `ApplicationHandle` (for Tauri `emit` / webview
34//! lookup) and `RunTime` (for `Environment`, `ApplicationState`, provider
35//! registry, scheduler).
36//! - `Parameter` is the raw JSON payload Cocoon sent; each atom extracts the
37//! fields it needs and validates locally.
38//! - Return `()` - atoms that need to fail just log via `dev_log!` on the
39//! `notif-drop` / `grpc` tag; the caller always returns `Empty` to Cocoon
40//! because notifications are fire-and-forget.
41
42// --- Shared support utilities ---
43pub mod Support;
44
45// --- Batch 8: provider-unregister cleanup ---
46pub mod UnregisterAuthenticationProvider;
47
48pub mod UnregisterDebugAdapter;
49
50pub mod UnregisterDebugConfigurationProvider;
51
52pub mod UnregisterFileSystemProvider;
53
54pub mod UnregisterScmProvider;
55
56pub mod UnregisterTaskProvider;
57
58pub mod UnregisterExternalUriOpener;
59
60pub mod UnregisterRemoteAuthorityResolver;
61
62pub mod UnregisterUriHandler;
63
64pub mod UpdateScmGroup;
65
66// --- Batch 11: progress lifecycle name alignment ---
67pub mod ProgressComplete;
68
69pub mod ProgressUpdate;
70
71// --- Batch 10: status-bar text + disposal ---
72pub mod DisposeStatusBarItem;
73
74pub mod SetStatusBarText;
75
76// --- Batch 9: output channel lifecycle (`output.*` + `outputChannel.*`) ---
77pub mod OutputAppend;
78
79pub mod OutputAppendLine;
80
81pub mod OutputChannelAppend;
82
83pub mod OutputChannelCoalesce;
84
85pub mod OutputChannelClear;
86
87pub mod OutputChannelCreate;
88
89pub mod OutputChannelDispose;
90
91pub mod OutputChannelHide;
92
93pub mod OutputChannelReplace;
94
95pub mod OutputChannelShow;
96
97pub mod OutputClear;
98
99pub mod OutputCreate;
100
101pub mod OutputDispose;
102
103pub mod OutputReplace;
104
105pub mod OutputShow;
106
107// --- Batch 13: webview reverse messaging ---
108pub mod WebviewDispose;
109
110pub mod WebviewPostMessage;
111
112// --- Batch 14: grammar, security, external ---
113pub mod OpenExternal;
114
115pub mod SecurityIncident;
116
117pub mod SetLanguageConfiguration;
118
119// --- Batch 15: inline arms atomised from `MountainVinegRPCService` dispatcher.
120// These were previously ~300 lines of inline match-arm bodies; now each
121// wire method is a one-fn file that the dispatcher delegates into.
122pub mod ExtensionActivated;
123
124pub mod ExtensionDeactivated;
125
126pub mod ExtensionHostMessage;
127
128pub mod LanguagesSetDocumentLanguage;
129
130pub mod ProgressEnd;
131
132pub mod ProgressReport;
133
134pub mod ProgressStart;
135
136pub mod WebviewReady;
137
138pub mod WindowShowTextDocument;
139
140pub mod WorkspaceApplyEdit;
141
142// --- Batch 16: the remaining inline arms - command register/unregister,
143// status-bar lifecycle / message, window show-message / create-terminal,
144// decoration / debug / webview / terminal fan-outs. A handful are
145// "group" atoms (`TerminalLifecycle` covers 4 wire methods that share a
146// relay + provider-drive pattern) - kept together where the handling
147// is truly identical and splitting would duplicate 5-line files.
148pub mod DebugLifecycle;
149
150pub mod DecorationTypeLifecycle;
151
152pub mod RegisterCommand;
153
154pub mod StatusBarLifecycle;
155
156pub mod StatusBarMessage;
157
158pub mod TerminalEnvCollection;
159
160pub mod TerminalLifecycle;
161
162pub mod TreeRefresh;
163
164pub mod UnregisterCommand;
165
166pub mod WebviewLifecycle;
167
168pub mod WindowCreateTerminal;
169
170pub mod WindowShowMessage;
171
172// --- Batch 17 (post-§14): SCM register pair pulled out of the
173// language-providers OR-block in `MountainVinegRPCService.rs`. The
174// catch-all fallthrough was registering SCM providers in the
175// language-feature provider registry, which the SCM viewlet never
176// reads. These atoms route through `SourceControlManagementProvider`
177// + emit the `sky://scm/*` events the renderer actually subscribes to.
178pub mod RegisterScmProvider;
179
180pub mod RegisterScmResourceGroup;
181
182// --- Batch 18: language-provider OR-block extracted from the inline match
183// in `MountainVinegRPCService::send_cocoon_notification`. All 46+
184// `register_*` / `register_*_provider` variants now delegate here via a
185// single `RegisterLanguageProvider(service, method, params).await` call.
186pub mod RegisterLanguageProvider;
187
188// --- Text editor API ---
189// Atoms for `editor.setDecorations(type, ranges)` and `editor.edit(cb)`.
190// These complete the decoration pipeline and enable in-place text mutations
191// from extensions (formatters, code actions, vim-mode, Error Lens, etc.).
192pub mod SetTextEditorDecorations;
193
194pub mod ApplyTextEdits;