sashahart
commented
2 years ago Sorry - I'm refusing this PR "without prejudice" - feel free to submit other PRs based on some of the same changes. If you want to know more, see below for details...
This PR seems to be lumping together a number of different issues that I would rather address separately. The most important issue is compatibility, but you also have written a number of bug fixes, features or other customizations included here without mention outside of commit messages.
As far as compatibility, you already have the best solution: use the code you have prepared as your own fish config. You have written a fish config which uses the version of find you prefer and includes all the features you like. I applaud this, it's exactly what all these extensible tools are for. But the solution is personal and not necessarily something that needs to be in vex, which I had hoped would offer "good enough" support for shells with very basic, easy-to-understand code. Basically, to provide the functionality quickly, to demonstrate it can be done to the same standard as virtualenvwrapper, and provide a base for people to learn from if they wanted to do their own fancier stuff. vex was never meant to offer really fancy and expansive and perfect completion configs for any shell: not bash or zsh and certainly not for fish. But, I am not above changing this rationale to consider fancier configs, as long as they can be really solidly vetted and are written clearly.
For other users, specifically the subset of users who are insistent about using Mac OS and fish and also vex, I think it is a reasonable stopgap to install GNU find, which is not hard to do even on Mac OS. It is Apple's decision to pointedly avoid GPL software, but that doesn't mean it has to be the user's. If you installed fish and vex and you are stressing about the completion then you are the kind of person who can manage this and benefit from controlling your own environment.
As far as offering better integration with Mac OS or BSD: Mac OS compatibility isn't the same thing as BSD compatibility, and you can't just run them together like that. Users on say FreeBSD are not automatically served by changing things to suit the corporate strategy of Apple. I'm not going to merge patches about BSD compatibility or claim BSD compatibility without actually testing on real BSD, anything less is a disservice to BSD users.
Anyway, the crucial practical point here is that I can't legally test on Mac OS without buying Apple hardware (it is literally against the license for Mac OS, even if I wanted to purchase Mac OS just to do patches for vex, which I don't). So it's not practically possible for me to verify anything works or not on Mac OS. It's not that I don't care, but I legally can't do it without spending thousands of dollars of my own money, which would require me to break the law.
By contrast, it is possible to do legally on some *BSD or other and I could be lured into setting up a VM to verify that prior to a merge. I have done this with Windows (which does legally allow me to do so without paying them a cent). But still, that's a few hours of my time, so I'm only going to do it if someone else puts in a comparable share of sweat equity.
About the other features that aren't actually about compatibility:
I'm not going to replace the whole completion in one multi-subject lump. I'm willing to merge PRs for individual changes one at a time. I'm not personally going to do the work of taking a lump of code and picking it apart and defining the test conditions for each feature. If you can isolate individual bug fixes or features, make them very clear to understand, and show that each fix/feature is working correctly on some BSD that I can legally use - then I would be happy to merge them one at a time. I'm sure that would make the fish support extra nice. All the better if someone or other would offer similar help with enhancements to support on more popular shells like bash, zsh and so on (I fear there's very little to be done with csh and friends, but the challenge is there if anyone wants to take it.)
However, I'm not motivated to do the majority of the grunt work on this myself, because I don't use fish and I'm afraid of making what support vex already offers worse in the process of trying to make it fancy (including on platforms like Mac OS where I'm legally not allowed to test).
Hope you understand.
findon macOS/BSD doesn't support-printf. See also conda/conda#7575.I also added some other fixes and enhancements to the fish shell completions, commit by commit.