tune-plugins

[locustbaby]

1. To list the plugins, we require an identification method. Therefore, I eliminated the default plugin meta and now we can identify plugins using plugin.meta.name.

2. While building the shell, it seems unnecessary to add the plugin twice. It would be beneficial to detect duplications during the building process, but I am unsure of how to accomplish this.

[MrPicklePinosaur]

Great idea! However, perhaps we could rely on the type system to keep track of installed plugins instead of using strings. Maybe introduce a plugins field in Runtime that uses anymap to keep track of all the registered plugins. This has the added benefit of being able to detect duplicate plugins too.

[locustbaby]

@MrPicklePinosaur Hi, there is a question I don't understand that state is already a Anymap and plugin will be inserted finally, and when I build shrs with below config, there won't be any error, so how to releaize it.

let myshell = ShellBuilder::default()
        .with_hooks(hooks)
        .with_env(env)
        .with_alias(alias)
        .with_readline(readline)
        .with_history(history)
        .with_plugin(OutputCapturePlugin)
        .with_plugin(OutputCapturePlugin)
        .with_plugin(OutputCapturePlugin)
        .with_plugin(OutputCapturePlugin)
        .with_plugin(OutputCapturePlugin)
        .with_plugin(CommandTimerPlugin)
        .with_plugin(RunContextPlugin::new())
        .with_plugin(MuxPlugin::new())
        .with_plugin(CdStackPlugin)
        .build()
        .expect("Could not construct shell");

    myshell.run();

[MrPicklePinosaur]

@locustbaby I recently updated ShellConfig in crates/shrs/src/shell.rs to include a plugins field, which holds a list of plugins that are registered, although the type is Vec<Box<dyn Plugin>>, which makes it a bit difficult to detect duplicate plugins. I am still experimenting on how to store plugins in a nice way, and will get back to this PR after. Sorry for the wait