Note the suggestion is to prefix them with : so the text is what the user would have to actually type. So they would be naturally segregated in the list. There are a number of low-level commands that are going to be routinely used, :read-attribute, :read-resource etc. So people are going to be conscious of low-level commands and IMO hiding them doesn't make much sense. Unless there is a high level command that does the same thing as all the regularly used low level ones. On 10/25/11 12:23 PM, Alexey Loubyansky wrote: > WRT https://issues.jboss.org/browse/AS7-2243 > Tab completion for operations should show low-level operations > > Brian suggests to include operations in the list of commands shown by > the tab completion when the line is empty. > > The original idea was to make an accent on the commands with the hope > that operations will be used only in special/advanced cases. Which is > still the direction to follow. > So, by default the cli is in the command completion mode. > Operation request completion is triggered by '/', './' or ':'. > > This is actually consistent with the bash shell too, where by default > you get a list of commands, scripts are not included, you'd have to > start with './'. Although, './' is listed there before all the commands > as an option, which is not the case in the cli. > > IMO, the current impl is cleaner. > > Votes, suggestions? > > Thanks, > Alexey > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev -- Brian Stansberry Principal Software Engineer JBoss by Red Hat _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

W.r.t. bash I don't see how ./ plays a role. In essence bash can auto-complete almost anything (given configuration in bash_completion.d): $ git cl clean clone $ ls ls lscgroup lskat lspci lss3 lsusb.py lsattr lscpu lsmod lspcmcia lssubsys lsblk lsinitrd lsof lspgpot lsusb $ l Display all 126 possibilities? (y or n) Maybe adopt that last bit as well? Or even go further and allow some sort of plugins. I would very much like auto-completion to work when I set the default rar name or default thread pool name for EJB. Carlo On 10/26/2011 09:11 AM, Max Rydahl Andersen wrote: > if the number of low level operations will be forever small then this sounds like a reasonable request - > if not then exposing commonly used low-level operations as high-level commands or aliases sounds like > another way to solve this and keep it all consistent. > > /max > > On Oct 25, 2011, at 19:04, Brian Stansberry wrote: > >> Note the suggestion is to prefix them with : so the text is what the >> user would have to actually type. So they would be naturally segregated >> in the list. >> >> There are a number of low-level commands that are going to be routinely >> used, :read-attribute, :read-resource etc. So people are going to be >> conscious of low-level commands and IMO hiding them doesn't make much >> sense. Unless there is a high level command that does the same thing as >> all the regularly used low level ones. >> >> On 10/25/11 12:23 PM, Alexey Loubyansky wrote: >>> WRT https://issues.jboss.org/browse/AS7-2243 >>> Tab completion for operations should show low-level operations >>> >>> Brian suggests to include operations in the list of commands shown by >>> the tab completion when the line is empty. >>> >>> The original idea was to make an accent on the commands with the hope >>> that operations will be used only in special/advanced cases. Which is >>> still the direction to follow. >>> So, by default the cli is in the command completion mode. >>> Operation request completion is triggered by '/', './' or ':'. >>> >>> This is actually consistent with the bash shell too, where by default >>> you get a list of commands, scripts are not included, you'd have to >>> start with './'. Although, './' is listed there before all the commands >>> as an option, which is not the case in the cli. >>> >>> IMO, the current impl is cleaner. >>> >>> Votes, suggestions? >>> >>> Thanks, >>> Alexey >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> -- >> Brian Stansberry >> Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > /max > http://about.me/maxandersen > > > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev