[Lazarus] SynEdit and gutter behaviour

[Martin]

On 15/09/2011 14:54, Bart wrote:
> On 9/15/11, Martin<lazarus at mfriebe.de>  wrote:
>>> 2: Signal to the gutter that the given line has changed
>>>
>> For 2:
>> You need your own subclass of synedit, to get the internal line object.
>>     procedure TSynEditStringList.MarkModified(AFirst, ALast: Integer);
>>
>> But there is (and never will be) direct access to TSynEditStringList
> This sounds like, although it is possible, it is designed in such a
> way that you are not really supposed/encouraged to do it that way...
> For now, I'll skip that option.
exactly, extremely discouraged.


>> It is possible though that the modified state of lines can in future be
>> published. Either via the visble lines (would need a typecast, as they
>> are tstrings. Or directly on synedit =>  as for directly on synedit, I
>> don't like it, too many properties, it needs a bit of structure.
>>
>> Feel free to come up with ideas. as for how it could be solved, then we
>> can discuss, what would be accepted as patch
>>
> I severely got lost in all the SynEdit (and related) source code.
> I would have expected that the GutterPart that does the (visual)
> marking would have a property to determine (or even set?) if a line
> was modified.
The data is in textbuffer.

Important if you have shared-editors => where 2 synedit work on the same 
text.

Sure one could add properties to the gutter, to modify it in the textbuffer.

But the gutter is only to show the info. The info exists without the gutter.

then better to have
   SynEdit.LineProperties
or similiar

> As for SynEdit itself. Every time I found a method that looked like it
> might trigger a change in "Line.Modified" status, I ended up (using
> Ctlr-Click) at a virtual abstract method declaration...
>

oh, yes the textbuffers has a virtual baseclass, as there are layers of 
wrappers

go to SynEditTextBuffer