mendelt / cmdr Goto Github PK

Check code style and formatting on travis ci

Allow library users to set hooks to run code before/after a command has been run and before/after a command loop has finished.

This might be useful if a user wants to do audit logging for example.

e.g.

struct MoveScope<T>;

#[cmdr]
impl<T> MoveScope<T> {
...
}

I guess we have to start digging now :)

Create doc-commends so the public API is documented on docs.rs

As a client I should be able to create aliasses for commands.
One way to implement this is by adding an alias annotation to a command method where you can specify a list of alternative command names.

Just like the help property on the cmd attribute to let a user specify help text for commands there should be a help property on the cmdr attribute too that lets a user specify help text on a whole scope.

When each of the features is implement there should be examples showing how they work.

• Running commands (already implemented)
• Setting prompts
• Override default function
• Override empty function
• Help text using help_ methods and annotations
• Autocompletion
• Pre/post command and pre/post commandloop hooks
• Command implementation without the cmdr macro (already implemented)

When a user types help or ? all the available commands in the scope should be displayed.

Show warnings or errors when the cmdr macro encounters unexpected input:

• Warn when no do_methods are found. (can we generate warnings from a macro?)
• Improve error message when macro is not on an impl block
• Check method signatures for overridden and do_methods and show errors when they don't fit

The help or ? function should show custom help text for a command when called with a command name.

I see three ways this can be implemented;

1. Like in Python Cmd where a do_command can have an associated help_command method that prints out the help tekst
2. Another way might be to have the cmdr macro parse the doc-comments for functions and use these as help tekst. Although this seems a bit 'magic' and might interfere how a user of the cmdr library wants to write documentation.
3. A third way is to annotate do_command with a help 'macro' that is picked up by the cmdr macro.

At the moment I lean towards implementing both option 1 and 3. Normally help_ methods will be used. Later an extra option can be implemented to easilly implement help_ methods with static text by using an annotiation.

Allow users of the library to implement auto completion of parameters for each command by implementing complete_ methods. These will receive a string of what the user typed so far and return a list of the possible ways to complete these

Commands are passed as a vector of strings, We could parse parameters in the command method signature in the macro and map arguments to the command method.

Integrate tools to track and publish test coverage in the CI process

This way the cmdr macro can be simplified to not handle empty commands. This allows the Line enum to be interal to the cmdr crate.

Commands can be auto-completed with the tab key.

See example 01-simple

I'm doing some unit testing to check if my software produces the correct results. Right now, cmdr uses println!() but it would be cool I could configure the output stream. Would that mean that scopes should store a reference to a "Write" interface and use write!() instead of print!()?
In addition to testing, I think it could also be needed if someone uses cmdr using some TCP stream or if they want to both stdout and log the commands and results produced.

Allow overriding prompt, empty and default when using the cmdr command.

It would be very useful to be able to read a series of instructions from a file. That would allow scripting as well as easy testing.
Should there be a way to configure to either 1) do all the instructions even if some returns errors 2) exit at the first instruction returning an error?
Also I'm not familiar with rust yet but there might be some additional design/testing involved in an async environment?

This could be done using a derive macro on a struct with annotated fields to store the entered answers.
Maybe this should be a separate crate from cmdr?

Update the README.md to explain how the libary works, show a simple example and include links to all urls (crates.io, github, doc.rs) and badges (doc.rs??? and travis.ci)

Create a separate readme for crates.io

The before command hook should take ownership of the Line and return a Line so library-users can access and change parsed lines.
To do this in a way that does not burden the lib-user with the lifetime of the Line we need to get rid of these lifetimes. Probably by copying the parsed string in the Line instead of referencing slices.

Do this;
https://www.reddit.com/r/rust/comments/2vrkf2/automatically_publish_to_cratesio_from_travis/

Allow dynamic help instead of using doc strings or a help parameter on the cmd attribute as help text. This can be done by letting the library user specify a method to call that provides the help text and then calling it the moment help is retrieved.

Hi there, was just playing around with this crate and realized the version on crates.io is quite a bit older than what you have on master, seems the API has changed a bit as well.

If it's in a good state, mind publishing a new release?

Commands that have been typed earlier can be re-executed by using arrow keys to move up and down. Commands in the command history can then be edited and re-executed by pressing enter.

There is a limited number of error- and other messages that are output to users that are hard-coded in cmdr. These need to be overridable so library users can use cmdr in other languages than english.

i.e. create a ~/.<progname>_history that is used to bootstrap the history on startup. And commands are automatically logged to this history file