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

make file completion broken in 2.7 #4967

Closed
karlseguin opened this issue May 10, 2018 · 4 comments
Closed

make file completion broken in 2.7 #4967

karlseguin opened this issue May 10, 2018 · 4 comments

Comments

@karlseguin
Copy link

File completion for Makefile arguments became broken in 2.7 (tested on both OSX and Ubuntu)

To reproduce, create a dummy Makefile:

F=

test:
	ls $(F)

in 2.6, typing make test F=<TAB> brings up autocomplete. In 2.7, it doesn't.

Removing complete -x -c make -a "(__fish_complete_make_targets (commandline -c))" --description "Target" from the make completion "solves" this problem, but I don't think that's the correct fix.

I asked in the gitter channel, and the suggesting was that #68527f broke this and I should open this issue.

@faho
Copy link
Member

faho commented May 11, 2018

I'd imagine this is due to #112 - 68527ff only changes "--description".

Removing complete -x -c make -a "(__fish_complete_make_targets (commandline -c))" --description "Target" from the make completion "solves" this problem

That's because, before 112, when __fish_complete_make_targets fell back on file completion. After 112, "--no-files"/"-f" (or in this case -x, which is just shorthand for -r and -f), really means no files.

I'm not too familiar with make - why is a file valid here? In general, when does make accept files?

Would it be sufficient to allow files after a "="?

@mqudsi
Copy link
Contributor

mqudsi commented May 11, 2018

Make itself never accepts files as arguments, it accepts the name of the target which may be a file, but is often a file that doesn't yet exist (so file-based completions are useless). Any foo=bar after make is a variable assignment, and foo can be literally anything, as can bar. For instance, I have makefiles that take a URL (make update URL=https://....) or a version number (make upgrade VERSION=17.2).

Depending on how smart our makefile target listing is, it may be best to just drop -x or -f entirely. In a perfect world where our make completions get all targets, including dynamic targets (i.e. not literally specified), there would be no need for that (except if the user intends to pass a file after =, which we can't know about), but I suspect our makefile listing is insufficient and there are cases it doesn't pick up (such as automatic suffix transformation, which is the most basic dynamic target).

@faho
Copy link
Member

faho commented May 11, 2018

In a perfect world where our make completions get all targets

Our make completions call make. That is pretty likely to get it right.

automatic suffix transformation

That actually seems to be handled! With a *.c rule, make -pn prints it for all available .c files!

@mqudsi
Copy link
Contributor

mqudsi commented May 12, 2018

Oh, I didn't realize we were using make to generate the list of targets - very nice! That should handle most (if not at all) cases, then. That just leaves foo= which can be followed up by literally anything.

@faho faho closed this as completed in 84fe46e May 12, 2018
@faho faho modified the milestones: fish-future, fish-3.0 May 12, 2018
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 17, 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

3 participants