Speaking of autocomplete, how would you design a data structure and declaration syntax to feed to the autocomplete/parsing system of a constrained CLI?<p>By "constrained CLI", I mean the kind that controls a router or other piece of equipment which has a well-defined (um, somewhat) syntax, as opposed to the somewhat more free-form aspect of the shell.<p>I ask, because one of my jobs had me occasionally working in the CLI declarations for a type of router. The cli commands could be in the form "interface foo enable", where "interface" could be shortened its shortest non-ambiguous form ("int" IIRC), and "foo" was a string corresponding to one of the interfaces on the system. Pressing TAB after "int" would automatically suggest the list of interfaces that exist on the system. This command had an opposite in the form "no interface foo enable" (yeah, prefixing "no" instead of postfixing "disable", though to be fair that may have been possible as well). A declaration of such a syntax was done with something along the line of:<p><pre><code> node(id=interface, type=keyword, keyword=interface, no_prefix=yes, next=int_name);
node(id=int_name, type=string, next=enable);
node(id=enable, type=keyword, keyword=enable);
</code></pre>
(with several extra bells and whistles to account for the int_name string referencing the existing interfaces on the system and to indicate that the command was only complete with "enable" at the end).<p>There were hundreds of declaration files containing lines like that, it was parsed by a humongous Perl script that output a 7MB source file containing the data structures fed to libinput. It was easily the slowest part of our compilation process, and Emacs would choke on that 7MB sourcefile.<p>It was terrible, but I never found examples of how to do it better. Anyone have any experience?