Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow inspection of Builtins commands #480

Closed
remkop opened this issue Dec 2, 2019 · 4 comments
Closed

Allow inspection of Builtins commands #480

remkop opened this issue Dec 2, 2019 · 4 comments
Milestone

Comments

@remkop
Copy link

remkop commented Dec 2, 2019

Thanks to @mattirn's remkop/picocli#888 PR, picocli-shell-jline3 now uses JLine 3.13.2 and can integrate nicely with the new TailTipWidgets.

To allow even better integration, it would be nice if an application can query the Builtins class to get a (read-only) set of command names and a (read-only) map of command name aliases.

At the moment, the Builtins commands and the picocli-based commands do not know about each other, so for example, if I run the picocli.shell.jline3.example.Example class in picocli-shell-jline3, and hit <TAB> at the prompt, I see a list of both built-in and picocli-based commands:

prompt>
cls        top        help       nano       keymap     setvar     bindkey    unsetopt
cmd        zle        less       clear      setopt     widget     history

Then, when I type help (a picocli command), that command can only list up the picocli-based commands. I would like to improve on this, but for that I need to be able to query Builtins.

@remkop
Copy link
Author

remkop commented Dec 2, 2019

Additionally, perhaps it would be nice to encapsulate the shared methods of Builtins and PicocliCommands in an interface. Perhaps something like this?

import org.jline.builtins.Completers;
import org.jline.builtins.Widgets;

import java.util.Map;
import java.util.Set;

public interface ICommandRegistry {

    /**
     * Returns the command names known by this registry.
     * @return the set of known command names, excluding aliases
     */
    Set<String> commandNames();

    /**
     * Returns a map of alias-to-command names known by this registry.
     * @return a map with alias keys and command name values
     */
    Map<String, String> commandAliases();
    
    /**
     * Returns whether a command with the specified name is known to this registry.
     * @param command the command name to test
     * @return true if the specified command is registered
     */
    boolean hasCommand(String command);

    /**
     * Returns a {@code SystemCompleter} that can provide detailed completion
     * information for all registered commands.
     * 
     * @return a SystemCompleter that can provide command completion for all registered commands
     */
    Completers.SystemCompleter compileCompleters();

    /**
     * Returns a command description for use in the JLine Widgets framework.
     * @param command name of the command whose description to return 
     * @return command description for JLine TailTipWidgets to be displayed
     *         in the terminal status bar.
     */
    Widgets.CmdDesc commandDescription(String command);
}

Thoughts?

@mattirn
Copy link
Collaborator

mattirn commented Dec 2, 2019

Builtins methods: commandNames() and commandAliases() OK
I can add also method

`List<String> commandInfo(String command)`

with no additional cost as the command help is already need to be parsed for completers. Method commandInfo() would return the first lines of the command help (until Usage:)

Example:
commandInfo("nano") => "edit files"
commandInfo("setvar") => "set lineReader variable value"
etc

@remkop
Copy link
Author

remkop commented Dec 3, 2019

That sounds good.

What do you think of the ICommandRegistry interface idea?
The idea is that this interface would make helper classes like DescriptionGenerator (that applications now need to code themselves) unnecessary. One idea would be to have a method on a JLine class or interface that takes a varargs array of ICommandRegistry objects and returns the appropriate CmdDesc for a CmdLine, similar to what the DescriptionGenerator.commandDescription method does now in the picocli-shell-jline3 Example.

@mattirn
Copy link
Collaborator

mattirn commented Dec 3, 2019

Sure I like the idea of ICommandRegistry interface. It makes possible to create pluggable command modules that you can add easily to your command line application.
In addition to the methods of your interface I think it should have also the methods:

List<String> commandInfo(String command)
String help(String command)

So in JLine can be implemented a class that have methods;

  1. compileCompleter() - aggregates command modules' completers
  2. commandDescription() - returns CmdDesc for TailTipWidgets
  3. help() - displays command help

Having a help() method in JLine class make it possible to create uniform and customizable color highlightning.

@mattirn mattirn closed this as completed in 94b6fcf Dec 5, 2019
@mattirn mattirn added this to the 3.13.3 milestone Dec 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants