I don’t want to sound too negative about this, but creating completions piecemeal is going to be a bit of a challenge for most (if not all) shells. It’s made more complex by the fact that one should have *separate* completions based on the project you’re in far more than the version of Elixir you’re using.
My mix completions (only top-level) for fish look like this: https://github.com/halostatue/fish-elixir Oh My ZSH has a rake completion that could be adapted for mix: https://github.com/eddorre/oh-my-zsh/blob/master/rake_completion.zsh (this one is interesting because caching the results is generally acceptable; I chose not to carry this over for my Mix script in Fish, because I found that the performance was adequate). I have no clue how to write useful bash completions. Yes, it’s *possible* to have decent completion scripts written by command-line toolkits (https://github.com/spf13/cobra is a good example), but those are primarily generated for standalone executables, not subcommands. Fish needs its entire completion definition in a single file (although functions can be loaded), and functions are generally loaded from a single location. -a On Wed, Nov 16, 2022 at 12:53 PM Max Nordlund <max.nordl...@gmail.com> wrote: > Hello, > > I wanted to improve the shell (as in bash/zsh/fish/...) completions for > mix and its subcommands. But before I do I figured I should ask here. > First off, is this something people are interested in? > > --- > > If so, here's a sketch for the implementation. TL;DR, let mix generate > completions for each shell in a known place and let those be loaded by a > small script/completion that's shipped by OS package managers and/or the > shell itself. > > > The entry point needs to live in some sort of distribution, typically > the OS package manager or the shell itself. This script should be kept > as simple as possible, and hopefully stable over time. Its primary > function is to figure out where the generated completions (more on that > below) are. We want to do this dynamically to support multiple versions > of Elixir, for example if you use something like https://asdf-vm.com/. > This means that the entry point script must support both older and newer > versions of Elixir, so it needs some sort of decent fallback as well. > That could probably be just `mix --names`. > > Once these generated completions are found, we can literally just source > them. The hard part is generating them in the first place. Which I think > should be done on installation, so `mix archive.*` and/or `mix deps.*`. > I imagine the easiest/cleanest solution would be to extend OptionParser > to do the actual completion generation, and as part of that, extend the > swatches definition to include descriptions for each flag. > > This could also be used to generate the markdown list of options I've > seen in @shortdesc. I also would like to add support for a @swatches > attribute (like the one used in Phoenix). > > Thoughts? > > Sincerely Max Sörliden Nordlund > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to elixir-lang-core+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/2a43b76c-0080-0567-b9c0-2f4a781eb4a6%40gmail.com > . > -- Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca http://www.halostatue.ca/ • http://twitter.com/halostatue -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAJ4ekQu2VRNt9p4DxTuz%3DfEhOw-RXFMSsVtuVPhCTfUG%3DVT7xA%40mail.gmail.com.
