gh-918: Introduced type segment

[MKadaner]

Summary

Using segment instead of std::pair<int, int> (or similar) because there is no way to remember what the second item represents: length, end, or last.

References

• Keep line numbers in Find All dialog always visible #918

Checklist

• I have followed the contributing guidelines.
• I have discussed this with project maintainers:
  
  If not checked, I accept that this work might be rejected in favor of a different great big ineffable plan.
  

Details

I started working on #918 and soon realized that I am totally confused by the meaning of various std::pairs I introduced in #789. Hence this PR. I am going to use segment even more.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[alabuzhev]

2018 -> 2025.

Why is it in 2d? Isn't it 1-dimentional conceptually?

[MKadaner]

2018 -> 2025.

Ough! Sure, will fix it.

Yes, it is technically 1d. I could not think of a good place for it. Does it make sense to move it up to "common"?

[alabuzhev]

Yes, why not.

[alabuzhev]

I know this is not new but moved from vmenu, but just in case:

• segment_t::operator== is defaulted, so it's a piecewise comparison that takes into account both begin and end.
• here we return {} (i.e. {0, 0}) when there is no intersection.
• is {0, 0} a special sentinel segment to indicate no intersection or is it conceptually equal to, say, {42, 42}?
• I'm not a set theory expert, but it feels like empty segments can intersect differently too? E.g. the intersection of {1, 1} and {1, 1} is probably {1, 1} (since they overlap, even if empty), but the intersection of {1, 1} and {2, 2} is neither of them, e.g. {0, 0}?

[MKadaner]

I am not a mathematician either, but I think the following axioms would not cause any contradictions down the road:

1. All empty segments are equivalent.
2. An empty segment has no ends.

On the practical level, it means that all accessors should have a precondition (assert(!empty()), and operator== should either reject empty segments as well or, according to Axiom 1, compare all of them equal. I think the latter is more correct.

Even more practically, what else can be returned if segments do not intersect? And if two empty segments happen to have the same begin, they are still empty, the intersection is empty, all empties are the same, so why not?

I do not think it worth cramming in std::optional to represent empty segments (though it would be more correct), mostly because of implementation and mental overhead. Also, please think of std::optional<small_segment> menu_layout::TextArea. There is nothing wrong with std::optional<std::optional<small_segment>>, but... Ahem...

If you do not mind, let me add missing accessors and operator== and assert(!empty() as appropriate.

[alabuzhev]

Thanks.
Just to clarify, I'm not trying to be picky - it's all mostly theoretical and probably irrelevant for all the current usages, but we're moving it to common where it might get used by something entirely different (also, do we actually expect it to be used elsewhere?), so it should hold some water.

[MKadaner]

No worries, I share the concern, and I am working on some generalization and clean up, while trying to avoid overengineering. Stay tuned.