From b5e14df41a2b77d71e3367fe44bf466f5c8ad1b5 Mon Sep 17 00:00:00 2001
From: 魏曹先生 <1992414357@qq.com>
Date: Tue, 4 Aug 2026 14:33:49 +0800
Subject: chore(core): merge custom completions with defaults

When a concrete entry's custom completion handler produces a `Suggest`
value, combine it with the default subcommand suggestions instead of
replacing them entirely. `FileCompletion` still falls back to the
default completion since it cannot be meaningfully merged.
---
 CHANGELOG.md              |  8 ++++++++
 mingling_core/src/comp.rs | 16 +++++++++++++++-
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 8d4528f..084c491 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -87,6 +87,14 @@ None
 
     Behavioral result: the static trie dispatcher now follows the same "longest registered prefix wins" rule as the dynamic dispatcher — a child (longer) path is preferred over an exact endpoint at the same depth, and only when every descendant fails to match is the exact endpoint at the current depth dispatched.
 
+6. **[`core:comp`]** Changed the `CompletionHelper::complete` method so that when a concrete entry is dispatched (i.e., a custom completion handler produces a `Suggest` value), the custom completion is now **merged with the default completion suggestions** rather than replacing them entirely.
+
+    Previously, when an explicit completion handler produced a `Suggest`, that value was returned as-is and the default subcommand suggestions (leaf nodes under the current path) were never consulted. Now:
+
+    - The default completion (`default_completion::<P>(ctx)`) is always computed and merged via `Suggest::combine()` when the custom suggestion is not `Suggest::FileCompletion`.
+    - If the custom completion is `Suggest::FileCompletion`, the default completion is used instead (since `FileCompletion` cannot be meaningfully merged with subcommand suggestions).
+    - Concrete entry completions and default subcommand suggestions coexist — e.g., `thanks <tab>` now suggests both the leaf nodes (`bob`, `alice`) and the `thanks` entry's own completion.
+
 #### Optimizations:
 
 1. **[`pathf`]** Added `is_module` field to `AnalyzeItem` and a new constructor `AnalyzeItem::local_module(module, item_name)` which sets `is_module: true`. The `type_mapping_builder` now tracks whether an item is a module: when generating `type_using.rs`, module items produce `use path::to::module::*;` (glob import) instead of the standard `use path::to::TypeName;` direct import. Non-module items continue to use direct imports as before. The internal data structure changed from `Vec<(String, String)>` to `Vec<(String, String, bool)>` to carry the `is_module` flag through the pipeline.
diff --git a/mingling_core/src/comp.rs b/mingling_core/src/comp.rs
index 5f851ca..edf25a6 100644
--- a/mingling_core/src/comp.rs
+++ b/mingling_core/src/comp.rs
@@ -168,8 +168,22 @@ impl CompletionHelper {
 
         match suggest {
             Some(suggest) => {
+                // A concrete entry was dispatched. Merge the entry's own
+                // completion with the default subcommand suggestions so that,
+                // e.g. `thanks <tab>`, suggests both the leaf nodes (`bob`,
+                // `alice`) and the `thanks` entry's own completion.
                 trace!("using custom completion: {:?}", suggest);
-                suggest
+                let default = default_completion::<P>(ctx);
+                if suggest == Suggest::FileCompletion {
+                    trace!(
+                        "custom completion is FileCompletion, using default: {:?}",
+                        default
+                    );
+                    default
+                } else {
+                    trace!("combining custom completion with default");
+                    suggest.combine(default)
+                }
             }
             None => {
                 if first_cmd_match.is_some() {
-- 
cgit