-
Notifications
You must be signed in to change notification settings - Fork 137
Feature requests
These are all features that we are not implementing now.
This is not to say that we might not add them in the future, just that they're not being done now.
ack 1.96 had this through File::Glob/bsd_glob. (GH #377)
Tell ack not to bother with really huge files.
ack -x takes a list of files that ack will search, kind of like xargs. It also doesn't pay any attention to --type. A request has come in to have -x respect --type. (GH #614)
For when you don't want to descend the whole tree, but -n is too restrictive.
Currently, the default directory to search, if no file/directory is passed in, is cwd().
Our project is very wide and sometimes very deep. I would need to pass in "../../../../../../../.." or ".." to search the whole project.
I envision default_directory=current|project|/full/path|relative_path
- current = current working directory, currect ack behavior
- full_path = user specifies a fully qualified path to the directory
- relative_path = user specifies a path relative to where the .ackrc is ("." being "project top" if the .ackrc is in the project root or project source root)
- project_top = the top of the current project based on the semantics of the VCS found (for git would be the first parent dir with .git, for SVN would be the last parent dir with .svn, similar for other VCS's)
A user like me who always wants project top, and all his projects use supported VCSs would put --default-directory=project_top in ~/.ackrc.
A user with an unsupported VCS (or no VCS, like an admin in /etc) would put a .ackrc file in the project top with --default-directory='.'
A user who wants to operate on part of the project dir (src or lib) would put a .ackrc file in the project top with --default-directory=src (GH #310)
--sort-by-date
--sort-by-date-desc
(GH #58)
I would suggest the following:
- Let {.abc,.xyz} be the set of valid file extensions supported by a given ack type-set 'myset'.
- In the presence of a type-add=myset:includecompressed:gz user option, transparently add {.abc.gz,.xyz.gz} to that set of valid file extensions.
- Search all valid files (.abc,.abc.gz,.xyz,.xyz.gz) within the specified directory tree, transparently expanding compressed ones.
- In the absence of gzip from the PATH, write something informative to stderr but don't abort. No change to ack exit statuses should result from implementing this RFE.
- Consider whether to support compressed formats other than gzip or whether YAGNI.
So I would add to my .ackrc:
--type-add=elisp:includecompressed:gz
...and ack would then transparently search all my elisp code as I want it to. (GH #406)
--stop-after-n-lines=100 would cause ack to stop searching a file after x lines. This is handy for searching a long list of large HTML files when all you want to see is the meta data for each file.
It would be nice to be able to specify the input record separator, so that files which have long lines can still be acked effectively (e.g. minified javascript, XML, JSON, etc.) (GH #366)
Let the user search for cats in all the files that also contain dogs.
ack cats --also-in-file=dogs
See the "Compound Expressions" section on http://www.incava.org/projects/glark. I was asked at work if ack supported this today, and since it would also provide an alternative solution to the "search for two things within the same line" FAQ, I think this would make a welcome addition to ack.
If ack knows --perl from --php from --sql, maybe ack could color code the search results in some way? So I can say "Oh, there's an orange file, it's PHP, I wasn't expecting that". (GH #605)
If ack finds a match in e.g. minified js file, or other files with just one or few very long lines, it will flood the output with the contents of the file and likely push all useful matches off-screen.
I would like an option to either ignore such matches altogether (maybe list the file name), or possibly to only show some number of characters worth of context around the match. (GH #596, GH #357)
I tried to set the color of the context line separator characters in ack, but found ack lacks the options to do so. Ack only has support for uncolored separator characters.
The characters I'm talking about are the :, -, and -- characters that decorate the output when you're searching with context lines turned on:
$ ack -H -C 1 z ~/.garbage
/home/me/.garbage
2-bar
3:baz
4-qux
--
25-bar
26:baz
27-qux
I've already implemented this feature in my own repo: https://github.com/h3xx/ack2/tree/feature-color-separator
Consider --[no-?]line-number and --initial-tab for tabular neatness.
I note that Gnu Grep has -T --initial-tab to insert tab after Line Number to make alignments work
but does not support the obvious --no-line-number override (possibly as --no-filename will do that in the only case that matters for them? ).
(Right aligning line numbers could also tabularize, but too many edge cases.) (GH #517)
Searching for a term in source files displays matching lines as expected, however it's common for matched lines to start with a large amount of whitespace.
Is it possible to print matching lines with leading whitespace removed? I suppose it would need to be unless the leading whitespace is part of the matching text in the line. (GH #386)
Various programs produce text files all on a single line. These files can be quite big. If you search them with ack and it finds a match, then it prints the whole file contents.
If a file has just a single line and that line is more than, say, 1000 characters long, then ack should suppress its normal printout of matching lines and just say 'Single-line text file X matches'. (GH #345)
-H forces the printing of the filename (which implies printing of the line number), and grep has -n to print the line numbers only. Do we need an equivalent to grep's -n? (GH #196)
http://thomashunter.name/blog/linux-cli-apps-should-have-a-json-flag/ (GH #69)
Scenario: I got the code for a project that I’m not familiar with yet. I attempt to start looking around with ack, but it's not working, giving the "Option '-a' is not valid in ack 2" error. After spending a bunch of time seeing how ack could be screwed up, figured out that there was a .ackrc file in the codebase itself which was specifying the option.
Request: if there’s an invalid option and it didn’t come from the command-line, include the source of the option in the error. (GH #277)