Refactor so isWrapped isn't public writeable

[PerBothner]

Having a publicly-writable isWrapped property in BufferLine restricts our implementation options for how wrapped lines are represented in a Buffer. For example, it conflicts with the proposal in #5673.

To hide this implementation choice, this PR makes isWrapped read-only, and adds a Buffer.setWrapped method (taking an absolute row number) for modifying the isWrapped state. There is also an internal-only BufferLine.setWrapped method used to implement Buffer.setWrapped and in one other place.

This gives greater flexibility in how BufferLine and line-wrapping are implemented.

This is likely to trivially conflict with PR #5785. If one of these is merged, I'll update the other one to fix any conflicts.

[PerBothner]

It would be great if someone could merge this. It allows (but does not require) alternative implementation stategies for BufferLine, such as PR #5797. I believe this should be trivially reviewable and hopefully non-controversial.

[jerch]

This gives greater flexibility in how BufferLine and line-wrapping are implemented.

Can you expand on why this would be needed? Is this an attempt to hide the row logic behind Buffer.* access (which is prolly needed for your logical line implementation)? (Btw our isWrapped logic is flawed currently, we hold this flag on the wrong line leading to all sorts of forward/backward lookups to correct the behavior.)

If we go that route with hiding abstraction behind Buffer.* access, then this also would apply for getters and prolly data getters/setters. The latter smells like a performance grave to me, getter/setter interfaces are always slower than direct access (with property getter/setter being even worse). I suggest to discuss this route first and to back it up with some perf measures.

[PerBothner]

The motivation of this PR was to split off part of PR #5797 that can be reviewed separately. Like ad hoc "stacked PRs".

For #5797 (and probably other alternative Buffer implementation strategies) changing a line from wrapped to non-wrapped or vice versa isn't a matter of just flipping a bit - there are more extensive changes that need to be done. For PR #5797 you would need to split or merge the related LogicalLine objects. So changing the isWrapped state becomes a more expensive operation. (Though note that setting isWrapped is usually when a new line is scrolled in, when a new BufferLine is created. Clearing isWrapped is usually when a line or buffer is erased, so those operations can be combined.)

Is this an attempt to hide the row logic behind Buffer.* access (which is prolly needed for your logical line implementation)?

Most of the other changes involving LogicalLine are hidden inside BufferLine.js (except for buffer reflow in Buffer.ts, which becomes vastly simpler and more efficient), but changing isWrapped to read-only is the main API change.

It would probably be straightforward to make isWrapped is a readonly property (rather than a getter), but I haven't looked into that. Either way, I would be astounded if the difference from direct access is measureable, as isWrapped/setWrapped are not called on a per-character basis.

Btw our isWrapped logic is flawed currently, we hold this flag on the wrong line leading to all sorts of forward/backward lookups to correct the behavior.)

PR #5797 makes it trivial to see if the current line wraps to the next one: Just check line.nextBufferLine.

Perhaps it would be more useful to come back this PR after looking at PR #5797. If you prefer, I can merge this into the latter, making the latter slightly larger, but perhaps better justified.

I am also interested in exploring this Marker proposal, which I think will have significant performance and extensibility advantages, but I think PR #5797 needs to be merged first.