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

Further parameters to hook #12

Open
stuartpb opened this issue Apr 12, 2015 · 0 comments
Open

Further parameters to hook #12

stuartpb opened this issue Apr 12, 2015 · 0 comments

Comments

@stuartpb
Copy link
Member

As (sort of) touched upon in #3, #4, #5, #7. Would apply for #11 if that is implemented (which would also reduce the pressure on choosing these correctly the first time).

My current thinking is to do number of lines (which may be blank, negative, or maybe a non-number value to stand for "all"), followed by grep filter expression (for entire lines, so as to cover #7's use cases, as well as being preceded by '^\S+\s+' for source-specific filter expressions ie. #3 and #4).

Hooks would then, for relief, parse these to determine what actions to take, saving some up-front load (eg. not cating 10000 lines when we know the end result won't use more than 100, or not reading files that wouldn't produce a source).

another possible parameter, as touched upon as an issue in #11, could be a "don't output if you implement one of these formats" parameter, for forward/backward compatibility (instead of having that reasoning come from outside the plugin). This might be just something to reserve and only break glass in case of emergency as a post-facto addition in the event that this convention needs to be superseded, as an extension parameter "reserved for future use" that you can otherwise ignore.

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

1 participant