fix line number handling for errors and warnings

[PhilipPartsch]

With this PR I try to fix #1077

[codecov]

Codecov Report

Attention: Patch coverage is 96.00000% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 85.97%. Comparing base (90bae4a) to head (9279233).

❗ Current head 9279233 differs from pull request most recent head 4b65a07. Consider uploading reports for the commit 4b65a07 to get more accurate results

Files	Patch %	Lines
sphinx_needs/api/need.py	95.65%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1150      +/-   ##
==========================================
+ Coverage   85.92%   85.97%   +0.04%     
==========================================
  Files          56       56              
  Lines        6536     6558      +22     
==========================================
+ Hits         5616     5638      +22     
  Misses        920      920              

Flag	Coverage Δ
pytests	85.97% <96.00%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[danwos]

Thanks for the PR and the great fix.
It looks good to me, but I haven't tested it locally.
And I'm also not an expert with docutils.
So @chrisjsewell, do you have any concerns?

Also thanks a lot for updating the tests and adding a new one 👍

[chrisjsewell]

The general concept looks good thanks 👍, but see review comments for implmentation details

[PhilipPartsch]

@chrisjsewell why did you have removed the content_offset from the needs.json?
In #1082 @danwos wrote:

Customized handling (fast prototyping)
This use case is for me the main reason, why needs.json got chosen.
shall be complete
shall be easy to understand and use
Shall work without any changes or configuration

So I would want to bring in the content_offset, and even work on to bring back the _back links #1157 and add the lineno #1156.

@chrisjsewell and @danwos: How do we want to proceed?

[chrisjsewell]

why did you have removed the content_offset from the needs.json

Heya, because as I have already mentioned, including full source-mapping in the needs.json is a separate concern to this particular PR, and it would not currently make sense to include it anyway since the line number is not included so you have nothing to offset against

[PhilipPartsch]

why did you have removed the content_offset from the needs.json

Heya, because as I have already mentioned, including full source-mapping in the needs.json is a separate concern to this PR, and it would not currently make sense to include it anyway since the line number is not included so you have nothing to offset against

I fought we agreed to add this information to the needs.json. Even I try to add the lineno. Anyway, the content_offset is usefull without the lineno, as it is the offset of the directive content from the beginning of the file.

[chrisjsewell]

I fought we agreed to add this information to the needs.json

No that is not the case: #1156 (comment), again I'm not against doing this perse, but it needs to be considered/implemented outside of this PR which is specifically for fixing warnings

as it is the offset of the directive content from the beginning of the file

no that is not the case; it is the offset from the top of the directive