Hi Ludo, Sorry, I am not compliant and reorder your quotes to ease the discussion -- from my point of view. :-)
On Tue, 12 May 2020 at 10:51, Ludovic Courtès <[email protected]> wrote: > However (srfi srfi-37) does it as we see it now. Fixing it would mean > implementing a different option parser. Yes or add a lot of complexity. Both appears to me wrong. Such corner cases do not deserve one or the other. > I think there are option parsers that “correctly” deal with the > ambiguity that arises for instance with “-I -p foo” (is ‘-p’ the > argument to ‘-I’ or something else?). Perhaps libc’s argp does it > right. I have never deeply dove into srfi-37 and 'option' but from my understanding, it is not possible. Somehow, the issue comes from srfi-37 and srfi-37 should consider that if an argument starts with dash, then it is not an argument and turn it into an option. > Nothing new here, and everything is properly documented. I am not sure. The manual says, for example: --8<---------------cut here---------------start------------->8--- ‘--list-installed[=REGEXP]’ ‘-I [REGEXP]’ List the currently installed packages in the specified profile, with the most recently installed packages shown last. When REGEXP is specified, list only installed packages whose name matches REGEXP. --8<---------------cut here---------------end--------------->8--- which is somehow inaccurate. The REGEXP is not optional for the short option '-I'. And that's true for all the short options with optional argument, if I understand correctly. For example, "guix package -d -p /path/to/profile" fails. Moreover, the distinction between 'action' and 'query' is already stated so why not underline that composing actions make sense (transaction) but composing query not? > > However, main of us are used to read from left to right so it seems > > more natural to write: > > > > guix package --action1 --action2 # (a) > > than > > guix package --action2 --action1 # (b) > > > > in other words, the fix should be to simply 'reverse opts' and the CLI > > will read (a) instead of the current (b). My only concern is about > > backward compatibility. > > We’ll need to check exactly what will behave differently. If the tests > don’t catch anything, I think we’re fine. Most likely, we’re talking > about corner cases like ‘-S x -d y’, which probably very few people > tried. Ok, on this light, let first point the corner cases. All the best, simon
