How the CLI works

6 views
Skip to first unread message

Joe Walker

unread,
Dec 6, 2010, 11:58:38 AM12/6/10
to skywriter-core

The current CLI implementation doesn't have a UI, but it's worth describing:

Terminology terminology:
class or object literal
method

Terminology:
A command has a number of params, each of which has a type. Parameters are different to arguments; arguments  are what we pass to the parameters. An argument retains knowledge of where it appeared on the input.
When you type something at a command line, it is tokenized into argments, we then split out the command-to-be-executed from the arguments to the command. and assign the arguments to parameters.
A requisition is a command to be executed, and a set of assignments of arguments to parameters.
Each assignment has 2 views: the textual input, and the converted value which is of the type specified by the parameter.
Types are all able to convert values to and from strings, the stringify process is simple, but the reverse parse operation results in a conversion which includes the value and status information, and can include a message, and hints to complete the process.
The canon is the set of available commands. A cliui 'interface' allows the cli to communicate with whatever UI is giving it input.

Net result - we have up-to-the-character information about exactly where any problems lie, and we can generate some cool UIs to go on top which will make using a command line as discoverable as a traditional GUI.

I'm actually really happy having written that - the system not only works, but also is simple enough to explain in a paragraph.

As an extreme example, given the following input:
> set tabstop x
We can deduce that there is an error between characters 12 and 13, that the argument 'x' is of the wrong type for the given setting.
Or:
> set t
We can deduce that the input does not contain an error, but never-the-less, we shouldn't allow the user to press return because it is incomplete, and that tabstop, time and table* are the valid completions at this point (* I made these up)

Joe.

Fabian Jakobs

unread,
Dec 7, 2010, 3:41:24 AM12/7/10
to skywrit...@googlegroups.com
This sounds exciting. Can't wait to dive into it.

> --
> You received this message because you are subscribed to the Google Groups
> "Mozilla Skywriter Core" group.
> To post to this group, send email to skywrit...@googlegroups.com.
> To unsubscribe from this group, send email to
> skywriter-cor...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/skywriter-core?hl=en.
>

Irakli Gozalishvili

unread,
Dec 7, 2010, 4:07:30 PM12/7/10
to skywrit...@googlegroups.com
Joe,

I was curios if that's something that can be easily adjusted to be used for command line programs, I mean something like an [argparse](http://docs.python.org/library/argparse.html) in python. Also if the later true I think it won't be to hard to add bash_completion.

Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France


Joe Walker

unread,
Dec 8, 2010, 5:52:08 AM12/8/10
to skywrit...@googlegroups.com

I'm of the opinion that using a curses based UI for the command line is like using punch tape as a storage system on an ipad. We're stuck in this bad relationship and can't admit we should move on.
I took a look at the completion in zsh to see how easy it would be to convert their data model for command definition. I think it could work - probably by patching zsh to export it's parsed command understanding into a JSON dump that we could read, and there are a ton of reasons why an html-cli would kick a curses UI all around the field.
Joe.

chiggsy

unread,
Dec 8, 2010, 6:34:54 AM12/8/10
to Mozilla Skywriter Core

We're stuck in
> this bad relationship and can't admit we should move on.
> I took a look at the completion in zsh to see how easy it would be to
> convert their data model for command definition. I think it could work -
> probably by patching zsh to export it's parsed command understanding
> into a JSON dump that we could read, and there are a ton of reasons why
> an html-cli would kick a curses UI all around the field.
>

Hi, I saw this post and I joined this group, just to say Joe is
right. I saw vim-bindings ( I won't lie I google that all the time,
just to see what's up ) and found Irakli's post.

Joe is right. ;)

Fabian Jakobs

unread,
Dec 9, 2010, 11:55:10 AM12/9/10
to skywrit...@googlegroups.com
On Wed, Dec 8, 2010 at 11:52 AM, Joe Walker <jwa...@mozilla.com> wrote:
>
> I'm of the opinion that using a curses based UI for the command line is like
> using punch tape as a storage system on an ipad. We're stuck in this bad
> relationship and can't admit we should move on.
> I took a look at the completion in zsh to see how easy it would be to
> convert their data model for command definition. I think it could work -
> probably by patching zsh to export it's parsed command understanding into a
> JSON dump that we could read, and there are a ton of reasons why an html-cli
> would kick a curses UI all around the field.

This would be really cool. I want this for our git command line :-)

Reply all
Reply to author
Forward
0 new messages