From 1cd4a824b3bffbbdf391837288921d538438a751 Mon Sep 17 00:00:00 2001
From: 魏曹先生 <1992414357@qq.com>
Date: Mon, 17 Aug 2026 00:26:00 +0800
Subject: docs: split 0.5.0 roadmap into individual issue pages
---
docs/dev/pages/issues/0.5.0-roadmap.md | 142 ---------------------------------
1 file changed, 142 deletions(-)
delete mode 100644 docs/dev/pages/issues/0.5.0-roadmap.md
(limited to 'docs/dev/pages/issues/0.5.0-roadmap.md')
diff --git a/docs/dev/pages/issues/0.5.0-roadmap.md b/docs/dev/pages/issues/0.5.0-roadmap.md
deleted file mode 100644
index 83d872f..0000000
--- a/docs/dev/pages/issues/0.5.0-roadmap.md
+++ /dev/null
@@ -1,142 +0,0 @@
-
The Mingling 0.5.0 Roadmap
-
-Mingling 0.5.0 is going to be a significant release, planned as follows:
-
-1. **Breaking:** Remove the `pack!` macro:
-
-Since the very first version of Mingling, the `pack!` macro has been around.
-Its purpose has gradually narrowed from "creating a type and registering it
-to Mingling" to "creating a newtype that derives Grouped". In other words,
-the functionality of `pack!` is gradually being replaced by the `Grouped derive`.
-Furthermore, in 0.2.0, in order to accommodate `StructuralData derive`, Mingling
-introduced `pack_structural!` and `pack_err_structural!` variants all at once,
-which greatly increases the maintenance cost of the project.
-
-So I plan to introduce a Breaking Change in 0.5.0: remove the entire `pack!` family of macros.
-
-All future type creation will be done as follows:
-
-```rust
-// Before
-pack!(ResultNames = Vec);
-
-// After
-#[derive(Grouped)]
-pub struct ResultNames {
- names: Vec
-}
-```
-
-2. **Breaking:** Generalize the REPL system
-
-The current REPL is merely _usable_, but far from _user-friendly_. Mingling plans
-to remove the `repl` feature in 0.5 and by default expose more execution-related
-interfaces for the Program, so that users can extend functionality beyond the REPL
-by leveraging Mingling's execution model.
-
-3. **Breaking:** Remove the `parser` feature
-
-In 0.3.0, Mingling introduced the `picker` feature, which provides more powerful
-parameter parsing capabilities. At that point, the original `parser` feature became
-inadequate. Mingling plans to completely remove it, which will directly affect
-downstream users of the `parser` feature.
-
-4. **Breaking:** Remove `with_dispatcher` and `with_dispatchers`
-
-Mingling's commands must be registered through `with_dispatcher` in order to be usable
-when `dispatcher_tree` is disabled. This has always been a strange semantic: `chain`,
-`renderer`, `help`, `completion`, and `metadata` are all collected at compile time,
-so why is `Dispatcher` the exception?
-
-In fact, during my usage of `dispatcher` from 0.1.0 to 0.4.0, I have never encountered
-a scenario where **dynamic registration** was necessary. I consider it unnecessary.
-
-Therefore, I plan to make `Dispatcher` registration also compile-time collected in
-non-`dispatcher_tree` states starting from 0.5.0.
-
-5. **Breaking:** Modify the `dispatcher!` syntax
-
-After completing item #4, `dispatcher!` will be simplified, because the `CMD*` struct will no longer need to be created
-
-```rust
-// Before
-dispatcher!("command", CMDCommand => EntryCommand);
-
-// After
-dispatcher!("command", EntryCommand);
-
-// NOTE: The implicit mode is not affected
-```
-
-6. **Feature:** Higher-level abstractions for the completion system
-
-Mingling's completion system filled a number of behavioral gaps in 0.4 and fixed many
-edge cases. It's now time to introduce more powerful higher-level abstractions.
-
-First, this feature will add a set of utility functions to `ShellContext`, enabling a
-smarter description of user state, rather than simply relying on manually identifying
-user behavior through fields like `previous_word`.
-
-Additionally, when the `picker` feature introduced in 0.3.0 is enabled together with
-the `comp` feature, a module named `picker_comp` will be activated to enable more
-completion behaviors.
-
-7. **Feature:** Automated `dispatcher_tree` optimization decisions (under consideration)
-
-After completing item #4, this Feature becomes implementable: Mingling can automatically
-decide whether to use `dispatcher_tree` to optimize dispatch efficiency based on the current
-number and depth of registered commands, so users no longer need to manually enable the
-`dispatch_tree` feature.
-
-Conditions: `dispatch_tree` has an advantage in cases where command depth is too high and
-the number of commands is too large. However, if the number of commands is too small, the
-increased CPU prediction failure rate will inevitably make it less efficient than linear
-lookup; specifics need to be tuned during implementation.
-
-Additionally, the issue where `pathf` + `dispatch_tree` must be explicitly specified in
-`[build-dependencies]` will be resolved:
-
-```toml
-# Before
-[build-dependencies.mingling]
-version = "0.4.0"
-features = [ "build", "pathf", "dispatch_tree" ] # `dispatch_tree` must be explicitly specified for `pathf` to recognize it
-
-# After
-[build-dependencies.mingling]
-version = "0.4.0"
-features = [ "build", "pathf" ] # No `dispatch_tree` feature; `pathf` no longer needs to consider its branches
-```
-
-8. **Feature:** A new macro designed for `pathf`: `#[pathf_export(type::TypePath)]`
-
-`pathf` has been around since 0.2.0 and has worked well for a long time, with many edge cases resolved. However, it still lacks an escape hatch — "when certain indirect expansions cannot be recognized by `pathf`, how can we assist its inference?"
-
-I plan to introduce a new attribute macro to supplement `pathf`'s path inference.
-
-```rust
-#[macro_export]
-macro_rules! repack {
- ($name:ident) => {
- // Ignored! This section cannot be parsed by pathf.
- #[mingling::macros::pathf_ignore]
- #[derive(mingling::Grouped)]
- pub struct $name;
- };
-}
-
-// The expansion contains macros that need to be parsed by pathf
-#[pathf_export(MyType)] // Explicitly specified to assist pathf's inference
-repack!(MyType);
-```
-
-9. **Breaking:** Move `structural_renderer` from `mingling_core` to `mingling`
-
-Mingling's Hook system is now complete, so there's no longer a need to hardcode `StructuralRenderer` into the core loop. The plan is to remove it from `exec.rs` and instead inject the Hook implementation via `StructuralRendererSetup`.
-
-> [!Note]
-> Haha, hopefully we'll never have to use it.
-
-
- Written by @Weicao-CatilGrass
-
--
cgit