1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
<h1 align="center">Some Situations Where You'd Be Like "Shit!"</h1>
<p align="center">
This document collects the discomforts currently experienced while using Mingling.
</p>
This document collects the discomforts currently experienced while using Mingling.
Of course, you can also contribute to this document.
---
## Why is there no fallback completion logic? (Solved)
(completion) (fallback)
Currently, Mingling's Completion only supports providing completion logic for specific subcommands, with no way to provide global completion.
For example:
```
mycmd <tab>
completion:
--help -h --- Display helps
--version -V --- Display versions
```
Currently, there is no workaround.
Ideal solution:
```rust
#[completion(EntryGlobal)]
fn complete(ctx: &ShellContext) -> Suggest {
// ...
}
```
Final implementation:
By adding support for `EntryFallback` (formerly `ErrorDispatcherNotFound`) to the Completion system, `EntryFallback` can now be used as a completion entry point when no subcommand is matched:
```rust
#[completion(EntryFallback)]
fn complete_fallback(_ctx: &ShellContext) -> Suggest {
suggest! { "fallback" }
}
```
---
## Why can't I register descriptions for commands? (Solved)
(completion) (dispatcher)
Currently, Mingling's Completion cannot register a description for each subcommand.
For example:
```
mycmd <tab>
completion:
add rm list <--- You cannot register descriptions for commands
```
Expected behavior:
```
mycmd <tab>
completion:
add --- Add something
rm --- Remove something
list --- List something
```
Ideal solution:
```rust
// It should be able to freely integrate with crates that provide i18n functionality,
// so the following approach cannot be used as a data source for descriptions.
dispatcher! {
/// Add Something <--- How to i18n?
"add", CMDAdd => EntryAdd
}
// Ideally, it should satisfy the following two conditions:
// 1. No need to use `with_dispatcher`, because `with_dispatcher` is disabled in `dispatch_tree` mode
// 2. Must be able to accept String or &str at runtime
// Current idea
#[inline(always)]
#[dispatcher_desc(EntryAdd)]
fn desc_add() -> String {
// If using rust_i18n
t!("cmd.add.desc")
}
// Or
#[completion(CMDAdd)]
fn desc_add(_ctx: &ShellContext) -> Suggest {
// If using rust_i18n
suggest{
t!("cmd.add.desc")
}
}
// Collected and generated by `gen_program!()`
// Generate something like get_dispatcher_desc(id: &ThisProgram) -> String
// Match the corresponding function using enum values inside ThisProgram
gen_program!()
```
Final implementation:
`#[metadata]` registers a `Description` for each entry, and `gen_program!()` collects them. During completion, when a subcommand suggestion is generated, its owning entry's `Description` is resolved via the node path and attached as the suggestion's description text.
```rust
use mingling::{
ShellContext, Suggest,
macros::{command, completion, gen_program, metadata, suggest},
metadata::Description,
setup::picker::BasicProgramSetup,
};
fn main() {
let mut program = ThisProgram::new();
program.with_setup(BasicProgramSetup);
program.with_dispatcher(CMDCompletion);
program.with_dispatcher(CMDThanks);
program.exec_and_exit();
}
#[command]
pub fn thanks() {
println!("thanks!");
}
#[completion(EntryThanks)]
pub fn complete_thanks(_ctx: &ShellContext) -> Suggest {
suggest! { "alice", "bob" }
}
#[metadata(EntryThanks)]
pub fn desc_thanks() -> Description {
Description::new("Thanks someone")
}
gen_program!();
```
|
