Question about the reason for @std{in,out,err} complexity

[KlfJoat]

I'm preparing a PR for a feature I want to add (removing the space requirement between the # and the annotations).

In my local copy I've made the shdoc changes and I'm creating test cases for my "nospace" feature based on the current test cases.

The @std{in,out,err} tests are failing. When I went to look at the shdoc code to figure out why, I see a confusing situation for those annotations. Unlike the other multiline annotations (@description, @example), the @std{in,out,err} annotations have a large and complex set of code for the purpose of tracking indentation. But I can't figure out why--what is the use case for tracking indentation on a multiline @stderr block and not a multiline @example block, for example? Why can't a @stdout block be treated the same as a @description block?

[landure]

Hi, to answer you question, I've created a common code for handling indented multi-line annotations. I was waiting for my previous pull request acceptation before creating a new request.

See pull request #72.

[KlfJoat]

Hi, @landure

That doesn't seem to answer my question, that I can tell.

But for your PR #72, I have a request...

Line 729: match($0, /^([[:blank:]]*#)([[:blank:]]+)@(description|example|stdin|stdout|stderr|set|exitcode|see)[[:blank:]]*(.*[^[:blank:]])?[[:blank:]]*$/, contents)

Could you please change the plus sign at #)([[:blank:]]+) to an askterisk, like #)([[:blank:]]*)?

My convention is to identify comments solely for a human with # , but commands like shdoc or shellcheck uses with no space, like #@brief or #shellcheck blah.

As I mentioned, I was creating a PR for this, including testing. But if you're refactoring to create common code, that blows my changes away. :-)

[landure]

I'm not opposed to the change, but I would prefer for you to rebase your work on my pull request, or to wait for my pull request acceptation (if it's accepted).