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
|
= Cmd Todo list
Send suggestions for this list to marcel@vernix.org.
== Todo list
* Writing a complete_(command name) is enough to have the completion results be
displayed, but not enough to actually complete. In order to complete as well
there must be additional logic such as what complete_grep does. So right now
to do a completion method for a command you really have to do something like:
def complete_find(line)
completion_grep(@numbers.keys.sort, line)
end
Where the first argument is the collection to complete against and line is
what is passed in. This API should be simplified and it should have a better
name than completion_grep. Also the subclass has to remember that the
complete method has to take an argument. It would be better to not have them
have to do that. Perhaps introduce (another macro) class method that just
takes a collection, or a method reference that returns a collection that then
is operated on internally.
complete :find, :with => :phonebook_names
# ...
def phonebook_names
@nubers.keys.sort
end
or
complete :some_command, :some_other_command, :with => { # Some Proc }
* Add a Documentation class (or some such) which collects list of subcommands
and shortcuts so that the default help command can be more helpful and
complete.
* Make it so that doc allows one to document arguments for commands that take
arguments so that rather than just:
add -- Add a number into the phonebook.
You'd get something more like
add name number [phone type] -- Add a number into the phonebook.
* Have doc work like the 'desc' method for rake where it preceeds the task to
which it describes rather than specifying the task excplicitly as args.
* Get rid of do_ method naming convention and define a 'command' method to
replace the naming convention.
def do_subtract
# ...
end
would become
command subtract do
# ...
end
How to deal with method arguments? Perhaps doing:
command subtract do |arg|
# ...
end
Sam suggests command being the death of the doc macro:
command :add, 'Add an entry' do |name, number|
@numbers[name.strip] = number
end
I think that's pretty nice.
* Take another shot at having more objects (e.g. Command, Subcommand,
Documentation, etc)
* Provide a means of documenting subcommands
* When passing arguments to do_ methods do a better job of just checking if the
method takes arguments and then passing them all in with *args. Do all the
arity checks and then pass it as many args as the do_ method takes. Raise
some client catchable exception if nothing can be done with the passed args
to satisfy the method signature of the do_ method. Basically make the do_
command methods as much like ruby methods as possible so that the arguments
are handed to the command so that it can access them directly rather than
having to fish them out.
So get rid of tokenize_args...it's a busted idea. Instead have
e.g.
def do_add(name, number)
# ...
end
If the method that takes care of passing a command the appropriate number of
arguments can't do its job based on the input given then the default could be
something like announcing that there was an argument error (perhaps
formalized using handle) and then the help for that command should be
displayed.
* Implement rudimentary interaction with the underlying shell using the
standard | pipe notation and > redirection notation so that someone could do:
prompt> command | sort
or
prompt> command > commands-output.txt
and maybe
prompt> command | sort > sorted-command-output.txt
Though I don't really want to write anything too fancy or complicated. I
think the most basic functionality of pipes and redirects would be useful
though.
* Perhaps allow subclasses to override the tab as the completion key.
|