Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keep one line warning for suppressed "very long lines" error #49

Closed
Niluge-KiWi opened this issue Dec 7, 2015 · 2 comments
Closed

Keep one line warning for suppressed "very long lines" error #49

Niluge-KiWi opened this issue Dec 7, 2015 · 2 comments

Comments

@Niluge-KiWi
Copy link

Followup to #16 which introduced the --err-skip-line-length option to totally disable the "very long lines" error:

--err-skip-line-length is useful to avoid being spammed when many files ave too large lines to be searched.

However, it's dangerous to use this option: it completely silence the fact that some files were skipped because of their size.

To fix this, I suggest to print a one line error, at the end of the sift execution, when at least one file was skipped because of its size (maybe with a skipped file counter).

This would both avoid the spam (one line is not a spam, and if it is, we could have another option to really disable all of this, as it's currently done), and still inform the user that some files have been skipped: if the user wants full results, it could disable the option, or change the blocksize limit, as explained in the current error log.

@svent
Copy link
Owner

svent commented Dec 7, 2015

Thanks for your thoughts on this, I think this is a great idea!

I am just not sure whether this should get implemented as

  1. a new option (something like --err-sum-line-length)
  2. the new default, with a new option like --err-show-line-length to show all errors, one line per file

I got the impression over the last months that some users are not happy with the current behavior, so I might favor the second variant as that would still adhere to sift's "search everywhere" design principle and inform the user about possible problems and solutions.

I would be happy to hear some thought on this.

@svent
Copy link
Owner

svent commented Jan 4, 2016

I implemented the second variant as of version 0.7.0.

@svent svent closed this as completed Jan 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants