You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
cat
ing 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.
The text was updated successfully, but these errors were encountered: