Refactor getLine to return TextLines/Rope

[jhrcek]

As @michaelpj pointed out, for many use-cases it might be preferable if getLine stays within the world of Ropes, to allow for further processing (an example of this is in lsp and similar, currently incorrect usage of getLine-like functionality mentioned in this comment in hls: haskell/haskell-language-server#4303 (comment)

The initial impl. ini this PR might not be ideal, because its complexity is linear in the length of line being wrapped. But let me open a PR to get initial feedback.

[Bodigrim]

It feels a bit strange when lines gives [Text], but getLine returns TextLines / Rope. Does it save much on HLS side? One can apply fromText there, probably to the same effect.

[michaelpj]

That would be fine I guess. Bascially we need the mixed-encoding indexing that we get from Text.Rope.Mixed! It feels a little strange to be converting back to Text and then back to Rope, but maybe that's fine?

[Bodigrim]

If we want to return Rope, can we avoid firstLineRope and stick to firstLineRope? Otherwise we are doing a double conversion.

[michaelpj]

I guess the neatest alternative would be to provide some utilities for mixed-encoding indexing of Text itself, on the reasoning that it should be okay on the Texts we get from getLine, since they are likely to be short. WDYT @Bodigrim ?

[Bodigrim]

After thinking about it, I'm largely fine with both options:

• We keep functions as they were before this PR, TextLines -> Text, Rope -> Text, and HLS wraps results in fromText to get access to encoding-based indexing. The only downside I see is slight inefficiency: e. g., a hypothetical getLine :: Int -> TextLines -> TextLines knows that the result contains no newlines, while with fromText . (getLine :: Int -> TextLines -> Text) we would have scan Text once again. Not a big deal for the sort of strings HLS usually operates on.
• We change function signatures as in this PR. I'm fine to merge it, if HLS finds it useful. The only requirement is to be efficient and avoid double conversion. E. g., getLine :: Int -> Rope -> Rope should not convert intermediate Rope to Text only to execute fromText later.

[jhrcek]

I'll get to it over weekend. Will probably go with option 2 (keep Rope/TextLines).
Regarding avoiding double conversion I'll just have to figure out how to drop the last \n from the Rope without converting it to Text (or alternatively throw away/change the nice looking property that Rope.getLine i r == Text.lines (Rope.toText r) !! i. Suggestions are welcome 😄

[Bodigrim]

@jhrcek @michaelpj I'm uncomfortable that HEAD is in unreleasable state at the moment. Let's either finish up this PR soon or agree to stick to the design merged in #6.

[michaelpj]

Coming back to this, I don't feel so bad about just getting Text. It's true that we would benefit from the mixed-indexing capabilities of Text.Rope.Mixed, but in this instance we don't want a rope per se because we only have one line. It's quite reasonable for text-rope to say: you've just got a line now, you're out of my domain. It would be handy to have some kind of Text.Mixed module that let us do efficient indexing into a single Text, but that's really a separate request.

[jhrcek]

Ok, unless there are strong objections, I would close this PR and keep the current Text-returning implementation.
I was struggling with avoiding the double conversion for a bit, but it was not easy to implement while keeping the current invariants (making sure there are no newlines at the end of lines returned by getLine).

[Bodigrim]

I gave it a stab in 3a46aaf. Thanks for trailblazing!