A lot of builds can be influenced by environment variables. Compilation mode already has support for this by way of compilation-environment. This adds support for passing that down from counsel-compile. We will later add a counsel helper for manipulating the state of counsel-compile-env.
This helper allows us to tweak counsel-compile-env. We don't use separate actions. We either add the environment variable if it doesn't already exist or remove it if it does. There is scope for better validation and dealing with setting ARCH=foo when we have ARCH=bar in the environment already.
This adds a simple predicate test to filter out bad entries from the history as well as verify new entries being added to the environment.
We may not have defined a blddir, especially if the user has manually entered the make invocation. If blddir is nil then just keep default-directory as is.
You don't need my approval, and I don't have time or interest for more thorough reviews/designs any more because they're not appreciated around here, but you've addressed all my minor source-level comments, so LGTM.
I really appreciate your help with issues and reviews. It's just that I didn't have enough time to fix everything, especially in the last year. But if you notice that something important wasn't given priority, please ping again, I respect your opinion and will try to address it.
Thanks for the vote of confidence, I appreciate it.
That is perfectly understandable. I think I speak for all Ivy users when I say I don't expect you to fix everything. (Besides, where's the fun in that? ;) I am grateful for the effort you continue to put into this project, and I don't think I could do a better job in your position.
Thanks. Following your kind response, I feel like I should explain my previous offhand comment a bit. First as a user, and later as someone interested in following its development, I have by now become quite dependent on and invested in Ivy, so I care greatly about doing whatever I can (which isn't much) to help maintain the same high level of quality, consistency, and integration with the rest of Emacs as is expected in Emacs development itself.
My problem is that Ivy follows the "if you care enough about it, just submit a PR" review and development process, and the concerns I express in issues and reviews are either rarely shared by someone willing to do something about it, or even occasionally taken in a negative way by the reviewee. This is normal; it would be very strange and bad indeed if my word were taken as gospel, especially since I'm merely a user and occasional contributor.
But the more lax the review process, the better time reviewing things is spent elsewhere, and the more PRs are needed after the fact. I don't have the time to keep chasing Ivy development after the fact, commenting on or creating PRs for things I think should be done differently (besides, I'm sure it can seem annoying), so my only option at the moment is to step back a bit, and try not to step on anyone's toes.
Thanks again for your kind words and reassurance.
A larger and less personal but related problem I see with Ivy as a project is that, despite its size and popularity, it has only one maintainer and hasn't retained any collaborators to share the maintenance burden and lend more eyes and thoughts to designs and reviews. I've seen about a handful of interested contributors go through periods of activity, but in the end it's a one-man show, and few seem to stick around. I don't mean to sound negative or critical; rather, I'm hopeful for and eager to see how the project evolves in the future, and how this issue is addressed.
@basil-conto, I feel your pain and share exactly same thoughts 100%. The review process is definitely non-existent here. PRs are just getting merged on a random basis with bugs and it's difficult to track what's going on. Bugs are later on fixed directly on master via little scattered commits. Same goes about new big features. Instead of developing it up to the end where it's tested, reviewed and nearly bug free, and merging it as a single squashed change, the PRs are again being merged randomly and further developments done either on master or other PRs. What's worse some review comments are addressed right before the merge silently without a proper commit on PR, so changes in PR are not the ones that were actually merged. All this really creates mess and discourages contribution.
I think a good way of moving forward is to add more integration tests, maybe generate some documentation from them, annotate them with the design decisions that were taken at the time.
What we have right now is already quite good, there hasn't been a case where the default config was hopelessly broken.
One early design decision that added quite a bit of issues in the long run was the support of multiple regex builders. I still think it was a good decision, since many people do like the two alternative regex builders. But supporting three regex builders instead of one is quite a bit more effort, hence I ask for help, while making sure that at least the default re-builder is supported as best I can.
I'm always happy to accept contributions, and I wouldn't mind adding more maintainers in the future, if it's needed and there are volunteers.
Thanks for your concern. But I would appreciate a less emotional language. We are all here voluntarily and we all try to improve the state of things.
This is not the case. I review everything before merging and try to add tests if they are appropriate and I have the time.
Having no test coverage for a situation is a pre-existing bug. If a PR passes the existing tests, the code and documentation style, and fits with the design, I'll merge it. Even if it uncovers the mentioned pre-existing bug. It's a good way of moving forward, I think. Especially since we have MELPA-stable, and integration tests for MELPA.
Not an issue for me.
This is what I try to do most of the time.
Not really a productive comment.
I don't think that's the case. Yes, sometimes I'll merge a contributor's well-intentioned but semi-broken commit, and amend it with some minor changes that fix it. I don't like the idea of broken commits getting into
[BTW, this PR is probably the wrong place to be having this discussion.]
Although such additions are always a Good Thing, IMO documentation and tests aren't that lacking, and there are higher priorities elsewhere:
No-one said otherwise, and I doubt Ivy would be so popular if that were the case, but there's always room for improvement.
The number of regexp builders shouldn't matter, so long as their machinery is implemented in a sufficiently generic and modular way. This is covered by the aforementioned point (1).
Thanks for your efforts.
That's good to hear, but only you can make that call.
I think every important project needs (and usually has) at least one other person to whom responsibility can be delegated, and who can help with bug triaging, etc.
You can always count me in, FWIW.
I have a couple of suggestions for this process. I've noticed you usually amend the last commit in a PR to add a "Fixes #issuenumber" comment to the commit message. This results in a new commit, so Git considers the branch to have "unmerged commits", and Github labels the PR as Closed, rather than Merged. There are two alternative approaches which I think are more beneficial:
I prefer (2), as it gives a more informative Git history and keeps everyone happy, but Magit, for example, employs both (1) and (2) as needed.
Fewer hoops means more contributions, that's for sure. But there's a balance to strike between ease of contribution and thoroughness of review. Once something gets merged into
If Magit has taught me anything, it's that contributors more often than not appreciate high standards and thorough reviews, and are more proud of the final version as a result of that. If nothing else, it's a learning experience.
But like I said, there's a balance to strike, and all of this is easier said than done.
I don't think we can have one without the other. Refactoring code to be more modular will inevitably break things if we're not clear on what the existing code is supposed to do.
I've sent you a collaborator invite.
I don't fully understand this workflow. Can you give an example?
I've been avoiding merge commits for 5 years now. Let's keep it that way.
Is it really a big deal? The PR is closed, the code is in
We may not have defined a blddir, especially if the user has manually entered the make invocation. If blddir is nil then just keep default-directory as is. Fixes abo-abo#2030