One of the 'features' of the current output is for the text to be able to indicate whether the command is currently available or not. Personally I don't think there's much value to that. If necessary, more information could always be added to the help text.
Definitely +1 for removing code complexity. --Jens On Fri, Nov 4, 2016 at 11:06 AM, Jared Stewart <jstew...@pivotal.io> wrote: > Huge +1 to the idea of simplifying Gfsh parsing. I find the green help > text from Spring Shell too be less readable then the black text from > JoptSimple, but I assume we can configure that to our choosing. > > > On Nov 4, 2016, at 10:05 AM, Jinmei Liao <jil...@pivotal.io> wrote: > > > > This is a good idea. I'll reach out to find it out. Thanks! > > > > On Fri, Nov 4, 2016 at 9:48 AM, Michael Stolz <mst...@pivotal.io> wrote: > > > >> Can we suggest improvements to the Spring help capabilities? The Spring > >> community tends to be very responsive to good suggestions. > >> > >> -- > >> Mike Stolz > >> Principal Engineer - Gemfire Product Manager > >> Mobile: 631-835-4771 > >> On Nov 4, 2016 8:27 AM, "Jinmei Liao" <jil...@pivotal.io> wrote: > >> > >>> We have several jira issues related to gfsh parsing (GEODE-1598, > >>> GEODE-1912). After spending some time understanding how the parsing > >> works, > >>> I found out we have three components intertwined together all trying to > >> do > >>> parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by > >>> getting rid of Gfsh and JoptSimple parsing and only using Spring Shell. > >> The > >>> outcome is I am able to maintain the current parsing and tabbing > >> completion > >>> capabilities (and fix a few bugs) by removing 40+ files. The only > >>> difference I see so far lies in the help and hint messages. It seems > the > >>> main reason we are using these home backed Gfsh parsing is to provide > >> more > >>> readable help messages. Below are the differences: > >>> > >>> Using Spring Shell's provided help: > >>> > >>> Using Gfsh Parsing with JoptSimple: > >>> > >>> > >>> > >>> I do like the outcome of the latter, but added complexity of the code > is > >>> too expensive to bear. So I am asking the community how important it is > >> to > >>> maintain the current style of help? Can we do with the cheaper way by > >> just > >>> using whatever provided by the libraries? > >>> > >>> -- > >>> Cheers > >>> > >>> Jinmei > >>> > >> > > > > > > > > -- > > Cheers > > > > Jinmei > >
