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