Line numbers for soft-wrapped styled text?

[Alex Tweedly]

On 26/03/2017 02:25, Mark Wieder via use-livecode wrote:
> On 03/25/2017 04:00 PM, Alex Tweedly via use-livecode wrote:
>> Never done it, but I had a quick play ....
>
> Hmmm... nice approach. And clever use of spacebelow.
>
>> If you have a way of determining which line(s) are being changed, then
>> you could run this only from that line onward  to save some time ....
>
> No, I don't think that would work. First of all, you'd need to keep 
> track of how many lines before the changed line were already wrapped, 
> so that you could know what line number to start with. So you'd have 
> to have already predetermined the relationships of the line starts to 
> the line numbers and either stored that somewhere and keep updating 
> the list; or work out the line starts each time.
No, not necessary. This all works *entirely* with the "original" (i.e. 
unwrapped) lines. It has no knowledge of which lines are wrapped - only 
of the height taken by each *original* line in  the rendered field (as 
given by formattedheight).

So if you make a change wholly within one line, then *all* you need to 
do is
  - calculate the revised height of the render of this line (say, line N)
  - update sHeights[N]
  - update spacebelow of line N of field "linenumbersfield"

However, if you add or delete lines (including things like merging two 
lines, inserting a CR, etc.) then you need to
  - for delete: 'compact' the sHeights array to move all subsequent 
entries down
  - for insert: move the sHeights array entries 'up', and then calculate 
the rendered height for the new line
  - and then update the spacebelow for all lines (N..infinity) of the 
linenumbers field (i.e. you don't need to recalculate their heights, 
just set them)

(And of course the sHeights array should really be a custom prop of the 
field so we can generalize it :-)
>
> Secondly, you'll need to trap some events in a frontscript and handle 
> things like inserting and deleting text, resizing the field/card, etc.
>
Yeah, well, I did say "If you have a way of determining ...." :-)

But yes, resizing and other events need to be handled - but since we 
already have two fields that need to be kept parallel, then any app 
using this must be handling resize itself so adding a call to this 
function is trivial (and only needs to be done if the width changes, not 
the height). It also needs to handle changes to things like margins, 
borders (?maybe?), etc. which might be a new requirement.

Not sure why you'd need to do anything in a frontscript - doesn't the 
'textchanged' message would cover all cases ?

But in any case - anyone doing a styled text editor, is going to need to 
handle all inputs, changes, etc., so they'll have the right 
opportunities to do this as needed.


However - it's almost certain that the engine is doing this line-by-line 
(i.e. 'paragraph' by 'paragraph') rendering calculation, so it would (at 
a guess) not be hard to store that off in the styledText array 
structure. Might be a worthwhile enhancement request, if this would be 
generally useful.


-- Alex.