Closed rjbs closed 10 years ago
+1
I'm skeptical that a warning is any better than fatal. I suspect that if I put out a version with -a as a warning, soon will come the cry to make it hide the warning and make it a no-op.
A warning is better because it doesn't stop one from getting the answer, and does not break existing pipelines, and so on.
"Someone might want a further change" doesn't seem like a compelling reason not to make the first change, if the first change is a genuine improvement.
+1 - this change in ack2 was a nasty surprise for my fingers.
+1 -- I certainly understand the reason for the change, as it seems most of us got used to typing "ack -a" for our most common use cases. That suggests -a should be the default. However, I believe that error and warning are both the wrong way to handle a user passing the -a flag. Consistency with other flag pairs, such as --follow/--nofollow, -H/-h, suggests that we just allow -a and silently honor it. The fact that it's redundant doesn't pose any problem that I'm aware of, except user education. That's not sufficient reason to break people's ability to use --known-types in ACK_OPTIONS, and .ackrc. For those users, they have no way to interactively negate that one single flag, but rather are forced to use --noenv and blow away all of their other preferences.
I will gladly provide a patch for this if it would be applied. I'm still suffering through this.
Coding is not the issue. I'm just not sure it is a good thing to do.
Okay. What's the open question? Or, another way: what discussion can we have to resolve the issue?
So far, the argument in this ticket (and forgive me if I have missed this argument happening elsewhere already!) is that if the error becomes a warning, there might be another ticket about that. That's true, but I don't think it's an argument against changing -a
now.
Are there other benefits to making -a
fatal? (Like, do you hope to repurpose it for something else in v3?)
I have stated my two primary reasons to want -a
to be non-fatal:
ack -a
; in my case, I suspect it will be enough breakage that I can't detect ahead of time that I would regret doing it afterwardA resolution of this issue either way will make it easier for me to take steps forward.
Does it warn? Or does it become a no-op?
Because if it's a warning, y'all will complain that it's a warning and nobody wants that warning on their screen. And eventually when I want to reuse -a, you'll all complain.
And if it's a no-op, then you have nothing to tell you that it's wrong and when it finally does come time to use -a for something else we go through the same hate over again.
I see no solution that doesn't wind up with more griping in the future, and/or maintaining a useless feature into eternity.
I don't know who "y'all" are, but it doesn't include me. I am not asking for no warning, I'm asking for no fatality. To be clear, I am not going to complain about the warning later.
You didn't say anything about re-using -a later until your last comment, which is why I asked whether that was part of the reasoning.
To be clear, I think the only "useless feature" that would need to be maintained is the warning. -a
would be a no-op, otherwise, wouldn't it? I realize that maintaining two lines of code is still maintenance — do I ever! — but I want to understand whether we're talking about that or about a more complex set of behaviors. I don't propose that -a
should mean anything more than "warn and do nothing."
Also, when you say "it's wrong," I would say "it's pointless." There's a difference between adding a switch that does nothing and adding a switch that gets you results you don't expect. Or is there something actually wrong that would be occurring?
The bottom line is that if I make -a
be a warning, I am forever going to have it have to be a warning.
Yup, that seems likely.
And then why not also have backwards-compatibility with -u and -G and --binary and --skipped and --text and --invert-file-match?
There's a time to jettison the past. It's a major version change.
Well, my reason is that I always used -a
because I almost always wanted to search lots of files that weren't matched by any types. The other options I used very rarely.
If it's not changing, I'll take other steps. Thanks for help getting this to a conclusion!
Guys, I kind of hate to dilute the conversation with my third way but it
seems to me like the resolution is to bring -a
back. No one griping about
warnings, nobody's scripts broken in ack3 when it means something new.
Andy, the bottom line is actually that the moment you put -a into ack 1.x and then a few hundred thousand people started using it, and then multiple emacs modes were written for it, etc., you were stuck with back compat. This is what we I've heard referred to as a "high quality problem".
I still want to hear a response to the .ackrc problem I describe in my previous comment. If your tool is complicated enough that you have an rc file mechanism, you have to offer flags in opposing pairs.
I will happily submit a pull request.
Does it warn? Or does it become a no-op?
Because if it's a warning, y'all will complain that it's a warning and nobody wants that warning on their screen.
And if it's a no-op, then you have nothing to tell you that it's wrong and when it finally does come time to use -a for something else we go through the same hate over again.
I see no solution that does wind up with more griping in the future.
— Reply to this email directly or view it on GitHubhttps://github.com/petdance/ack2/issues/394#issuecomment-28616590 .
-a is not coming back.
-a is not the opposite of --known-types. Yes, --known-types needs a negator, but -a is not it. ack 1.x -a is not the same behavior as ack 2.0's default. It's similar, but not the same.
This is a decided issue. Further, at some point -a may become something else. That's one of the reasons that I removed -a from ack 2.0.
We went from 1.x to 2.0. Things changed. I'm sorry if this isn't ideal for anyone's situation.
Every time I get this, I swear and re-run the command with
ag
. It's good that the default behavior is better and-a
is less-often needed, but this error feels a lot to me like when you type "quit" in the debugger and it says, "I don't know what quit() is, but if you want to quit, type exit()". After years of using ack, always with -a, my fingers just bang it out. It is really frustrating to have to bang the command out twice.