-
Notifications
You must be signed in to change notification settings - Fork 138
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)
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)
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)
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)