Add optional line wrapping

[Puxap-3opre]

It's a very basic feature, the most lacking if you ask me. Why it's mysteriously missing from all those IMGUI text editors?

It seems to be in high enough demand,

BalazsJako#13

and I don't understand why Balazs said "too much hassle. It would complicate vertical scroll calculations too much."

I can imagine several ways to do it. For example, keep two parallel representations of the same text: wrapped lines and not. Keeping these in sync seems pretty trivial. Then for scroll calculations, the wrapped view lines could be counted just as easily as if there was no wrapping.

It won't even take much extra memory or time (usually), because texts we edit mostly aren't large (and we don't resize editing windows often).

Yet another option: keep an index for every line, corresponding with their offset from the start in the wrapped view. (Or, a number of lines that the line makes when wrapped). Etc.

BTW, thank you, @goossens !

It seems like you keep pretty neat and thorough work with this editor. I'm thinking to use it for my personal notes' app I'm making.

[goossens]

Thanks for raising the issue and the compliments.

Implementing line wrapping is not as simple as you think and I understand why Balázs was apprehensive about it.

In the original design (and in my rewrite), visual line numbers are identical to document line numbers and are used hundreds of times throughout the editor and its subsystems. Changing that would be major surgery and would lead to very ugly code without a redesign.

When I rewrote the editor, I thought about having the concept of a visual coordinate and a document coordinate (and a way to translate between them). In the end, I did not do that as one of my goals was to preserve as much of the old logic and API. There have been times when I regretted not doing it as I already have some ugly cases where proper abstraction is not working.

So although I would never use line wrapping myself, I think it is a good trigger to let me look at my internal architecture one more time and see if I would like to implement the separation of the coordinate systems and also implement more of a Model, View, Controller (MVC) design pattern.

This will not happen overnight but given that the original issues you referenced has been open for over 8 years, a couple of weeks/months aren't going to hurt. 😊

Another side effect might be breaking changes to the API so I need to look at that as well.

[Puxap-3opre]

I think when I tried to write some primitive editor (in pygame) several years ago (it had lines and glyphs, a bit like yours does), I used a list of lines as they looked in the wrapped state, i.e. a "parent" line was implemented as several "child" lines. Then all the operations were implemented as usual: going down to next line, adding/deleting symbols etc.

And when one "child" line changed, it was not hard to adjust its "parent" big line, with all its components. There was a check for line numbers, to be shown only for "real" line beginning...

Not sure if it's the best approach, especially if you build on some existing code, but it seems that in principle it's not too hard, especially compared to all the other work you did. And the API might not even change too much, as it would mostly still refer to the whole "parent" line (e.g. when you want to delete a line, it'd be not just about a wrapped part)

Yeah, I'm glad that you are considering that improvement. Thank you!

[goossens]

I've finished the first round of refactoring and the new version now supports Word Wrap, Line Folding, full MiniMaps,
Autocomplete and Language Server connectivity (see #43) for details. A preview is available in the future branch.