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#![allow(non_snake_case)]
43
44// --- Shared support utilities ---
45pub mod Support;
46
47// --- Batch 8: provider-unregister cleanup ---
48pub mod UnregisterAuthenticationProvider;
49
50pub mod UnregisterDebugAdapter;
51
52pub mod UnregisterDebugConfigurationProvider;
53
54pub mod UnregisterFileSystemProvider;
55
56pub mod UnregisterScmProvider;
57
58pub mod UnregisterTaskProvider;
59
60pub mod UnregisterUriHandler;
61
62pub mod UpdateScmGroup;
63
64// --- Batch 11: progress lifecycle name alignment ---
65pub mod ProgressComplete;
66
67pub mod ProgressUpdate;
68
69// --- Batch 10: status-bar text + disposal ---
70pub mod DisposeStatusBarItem;
71
72pub mod SetStatusBarText;
73
74// --- Batch 9: output channel lifecycle (`output.*` + `outputChannel.*`) ---
75pub mod OutputAppend;
76
77pub mod OutputAppendLine;
78
79pub mod OutputChannelAppend;
80
81pub mod OutputChannelCoalesce;
82
83pub mod OutputChannelClear;
84
85pub mod OutputChannelCreate;
86
87pub mod OutputChannelDispose;
88
89pub mod OutputChannelHide;
90
91pub mod OutputChannelShow;
92
93pub mod OutputClear;
94
95pub mod OutputCreate;
96
97pub mod OutputDispose;
98
99pub mod OutputReplace;
100
101pub mod OutputShow;
102
103// --- Batch 13: webview reverse messaging ---
104pub mod WebviewDispose;
105
106pub mod WebviewPostMessage;
107
108// --- Batch 14: grammar, security, external ---
109pub mod OpenExternal;
110
111pub mod SecurityIncident;
112
113pub mod SetLanguageConfiguration;
114
115// --- Batch 15: inline arms atomised from `MountainVinegRPCService` dispatcher.
116// These were previously ~300 lines of inline match-arm bodies; now each
117// wire method is a one-fn file that the dispatcher delegates into.
118pub mod ExtensionActivated;
119
120pub mod ExtensionDeactivated;
121
122pub mod ExtensionHostMessage;
123
124pub mod LanguagesSetDocumentLanguage;
125
126pub mod ProgressEnd;
127
128pub mod ProgressReport;
129
130pub mod ProgressStart;
131
132pub mod WebviewReady;
133
134pub mod WindowShowTextDocument;
135
136pub mod WorkspaceApplyEdit;
137
138// --- Batch 16: the remaining inline arms - command register/unregister,
139// status-bar lifecycle / message, window show-message / create-terminal,
140// decoration / debug / webview / terminal fan-outs. A handful are
141// "group" atoms (`TerminalLifecycle` covers 4 wire methods that share a
142// relay + provider-drive pattern) - kept together where the handling
143// is truly identical and splitting would duplicate 5-line files.
144pub mod DebugLifecycle;
145
146pub mod DecorationTypeLifecycle;
147
148pub mod RegisterCommand;
149
150pub mod StatusBarLifecycle;
151
152pub mod StatusBarMessage;
153
154pub mod TerminalLifecycle;
155
156pub mod UnregisterCommand;
157
158pub mod WebviewLifecycle;
159
160pub mod WindowCreateTerminal;
161
162pub mod WindowShowMessage;
163
164// --- Batch 17 (post-§14): SCM register pair pulled out of the
165// language-providers OR-block in `MountainVinegRPCService.rs`. The
166// catch-all fallthrough was registering SCM providers in the
167// language-feature provider registry, which the SCM viewlet never
168// reads. These atoms route through `SourceControlManagementProvider`
169// + emit the `sky://scm/*` events the renderer actually subscribes to.
170pub mod RegisterScmProvider;
171pub mod RegisterScmResourceGroup;
172
173// --- Batch 18: language-provider OR-block extracted from the inline match
174// in `MountainVinegRPCService::send_cocoon_notification`. All 46+
175// `register_*` / `register_*_provider` variants now delegate here via a
176// single `RegisterLanguageProvider(service, method, params).await` call.
177pub mod RegisterLanguageProvider;
178
179// --- Text editor API ---
180// Atoms for `editor.setDecorations(type, ranges)` and `editor.edit(cb)`.
181// These complete the decoration pipeline and enable in-place text mutations
182// from extensions (formatters, code actions, vim-mode, Error Lens, etc.).
183pub mod SetTextEditorDecorations;
184
185pub mod ApplyTextEdits;