Skip to content

Conversation

@whyvn
Copy link

@whyvn whyvn commented Sep 26, 2025

  • hinting & tab completion for commands
  • hinting & tab completion for history
  • smart hinting & tab completion based on argument type
  • let State be accessed in Argument callbacks for some extra specifc hinting
  • recurse for default subcommand hinting
  • fix old commands to use new api (with proper hinting and everything)
    • load
    • run
    • step
    • reset
    • watchpoint
    • breakpoint
    • disassemble
    • context
    • label
    • labels
    • examine
    • print
    • dot
    • help
    • exit

plus some other stuff

  • a variety of bug fixes
  • Command now uses the builder pattern
  • Argument has more stuff onw:
pub(crate) struct Argument {
    name: String,                                                                // argument name e.g. File, Step count, Whatever
    sanitiser: fn(arg: &str, helper: &MyHelper) -> CommandResult<ArgumentKind>,  // given some context, is this argument valid
    hints: fn(harg: &HintArgs, helper: &MyHelper) -> Vec<String>,                // what hints are available for this argument? (used for prompt hints and completion)
}

hinting and completion for history and default commands :)
silly commit silly changes. also history duplicates are removed. i think the performance is uhh not great probs
@whyvn whyvn marked this pull request as draft September 27, 2025 02:26
@whyvn whyvn changed the title interactive tab completion smart interactive tab completion Sep 27, 2025
@whyvn
Copy link
Author

whyvn commented Sep 27, 2025

hmm okay the next commit is going to restructure the arguments a bit. i think it should actually be a separate pr but im just doing it all at once here. i can revert and re pr later if i need to :)

and `Command` construction now uses the builder pattern :)
aswell as sanitising for each argument, you know also need to provide a list of hints
also fixed some minor subcmd hinting bugs
pub(crate) struct MyHelper<'a> {
completer: FilenameCompleter,
hinter: HistoryHinter,
pub(crate) state: &'a State,
Copy link
Author

@whyvn whyvn Sep 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this feels very hacky. need to keep state here so we can give the Argument callbacks some program context to better hint and sanitise with.

maybe State and MyHelper should be combined? it didnt feel right to do that either though, so now theres just a reference but you have to pass a MyHelper ASWELL as a &mut State to every function that calls a command which feels veryveryvery clunky. im like 80% confident this should be changed

i was experimenting with a refcell or cow solution maybe it would be better

Copy link
Author

@whyvn whyvn Oct 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

im going to let MyHelper own State now. it could be a really bad idea but otherwise you have to clone the entire state every single tiime you run a command. untangling them should be easy if required though.

also having them together requires we pass a &mut MyHelper to exec callback which is a bit misleading since really we only want to be able to mutate the owned State

whyvn added 4 commits October 5, 2025 17:14
so no clone cost for executing a command. downside is that callbacks are given a `&mut MyHelper` when really we only want them to have a `&mut State` and a shared reference to the other parts of the helper. might be changed later on

also multiple arguments got broken somehow. will fix soon
werid `skip` stuff, which was working without the explicit subcommand argument but now its not so :/ also hinting for out of order optional arguments is brokey now
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant