Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken flags after function definition with named args #6186

Closed
amiller27 opened this issue Oct 10, 2019 · 2 comments
Closed

Broken flags after function definition with named args #6186

amiller27 opened this issue Oct 10, 2019 · 2 comments
Milestone

Comments

@amiller27
Copy link
Contributor

@amiller27 amiller27 commented Oct 10, 2019

fish version: fish, version 3.0.2-1620-g055a3321
OS: Ubuntu 18.04
Terminal: terminator

a7913c3 (the fix for #6147) breaks function definitions that look like this:

function _pisces_bind_pair -a mode left right -d "Creates bindings for the given pair: autoclose and skip closing symbol"

Definitions like this are common in packages, that example is taken from laughedelic/pisces, it also breaks oh-my-fish/theme-bobthefish and probably others. It seems like the solution would be to assume the argument names end when another flag is encountered instead of erroring out.

@faho
Copy link
Member

@faho faho commented Oct 10, 2019

breaks function definitions

Not quite. The function definition was already broken, in that the options were never applied (instead variables with those names were defined), only fish never complained.

However I agree that this isn't an acceptable way to fail.

We should just pass all free arguments (those not belonging to any option) to --argument-names if it has been given (excluding the first of course, because that's the function name).

For the time being, let's revert a7913c3.

@faho faho added this to the fish 3.1.0 milestone Oct 10, 2019
@amiller27
Copy link
Contributor Author

@amiller27 amiller27 commented Oct 10, 2019

Even arguments that are passed before --argument-names or after other options? So in the definition

function foo a --argument-names b --no-scope-shadowing c

the argument names would be a b c? That seems much less intuitive than what I was intending to do in my PR (treat non-options between --argument-names and the next option as the argument names) but if that's what you want I can change the PR.

zgracem added a commit to zgracem/dotconfig that referenced this issue Oct 15, 2019
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants