On Sun, Feb 7, 2016 at 12:06 AM, AllKind <allk...@fastest.cc> wrote: > If I get it to upstream, the downside is, it's up to the packager of the > distro, or the user itself, to take care of it becoming available.
How so? Don't just dump it somewhere in their source tree, make it so that "make install" or the equivalent installs it along with the rest of upstream software. > Also I could still update it to changes made in the future. You mean if it was included with bash-completion? If you "sign up" for maintaining it and responding to bug reports etc, then I suppose inclusion in bash-completion would be an option. But I really think that inclusion in upstream iptables is a superior alternative, and I'm a bit uncomfortable if iptables is already being deprecated and you stopped working on this already in 2014... we don't want to be a dumping ground for unmaintained or legacy completions any more than we currently are. > But if that is a problem, I'm quite sure I can work out a solution with an > environment variable, that by default just shows long options. Not sure about a "problem", it's just my opinion. But if you want to pursue adding this to bash-completion, I do think that it should by default behave like the rest of the completions. IOW, the env var or somesuch if you want to add one should toggle the current behavior on, i.e. showing long options should be the default. Other things to consider if you want to suggest adding this to bash-completion: see the docs in the doc/ subdir, especially style guide and testing docs. We'll definitely want a test suite for this. In addition to the docs, the test/ dir contains a lot of examples. _______________________________________________ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
