beyondgrep / ack2

**ack 2 is no longer being maintained. ack 3 is the latest version.**
https://github.com/beyondgrep/ack3/
Other
1.48k stars 138 forks source link

make "-a" a warning, not fatal #394

Closed rjbs closed 10 years ago

rjbs commented 10 years ago
Option '-a' is not valid in ack 2
This is because we now have -k/--known-types which makes it only select files
of known types, rather than any text file (which is the behavior of ack 1.x).
You may have options in a .ackrc, or in the ACKRC_OPTIONS environment variable.

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.

maddingue commented 10 years ago

+1

petdance commented 10 years ago

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.

rjbs commented 10 years ago

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.

lbalker commented 10 years ago

+1 - this change in ack2 was a nasty surprise for my fingers.

leoger commented 10 years ago

+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.

rjbs commented 10 years ago

I will gladly provide a patch for this if it would be applied. I'm still suffering through this.

petdance commented 10 years ago

Coding is not the issue. I'm just not sure it is a good thing to do.

rjbs commented 10 years ago

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:

  1. I still keep typing it, even though I know in my brain it will fail, after years of using it. Others echoed this.
  2. upgrading to ack2 will break scripts that use 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 afterward

A resolution of this issue either way will make it easier for me to take steps forward.

petdance commented 10 years ago

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.

rjbs commented 10 years ago

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?

petdance commented 10 years ago

The bottom line is that if I make -a be a warning, I am forever going to have it have to be a warning.

rjbs commented 10 years ago

Yup, that seems likely.

petdance commented 10 years ago

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.

rjbs commented 10 years ago

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!

leoger commented 10 years ago

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 .

petdance commented 10 years ago

-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.