LineBreak and FileFormat properties of TSynEditStringList

[pyscripter]

There are currently two properties of TSynEditStringList that relate to the line endings of saved files:

• FileFormat: TSynEditFileFormat = (sffDos, sffUnix, sffMac, sffUnicode)
• LineBreak inherited from TStrings (introduced in Delphi Berlin 10.1)

The base class TStrings uses LineBreak only in:

• saving files (through GetTextStr)
• reading files (SetTextStr)
• Text property getter, setter GetTextStr, SetTextStr.

Currently TSynEditStringList uses instead FileFormat without setting LineBreak:

• SetTextStr is overwritten and detects line endings in the provided text, setting FIleFormat appropriately
• GetTextStr is inherited and uses LineBreak except when saving, in which case the FileFormat is taken into account
• In all other cases SynEdit uses SLineBreak (SelText, SelLength). In a few places it is assumed that SLineBreak = #13#10 (e.g. CharIndexToRowCol, RowColToCharIndex).

It is confusing to have two properties that relate to Line Endings. Also, I think it is more consistent for TSynEditStringList to inherit behavior from TStrings.

Since LineBreak has been availalbe since Delphi Berlin, and this repo is not compatible with versions before that, I propose that we drop FileFormat and use instead LineBreak:

• LineBreak is set when reading files or setting the Text property (SetTextStr). TStrings does not do that.
• LineBreak is used when reading the Text property. This is inherited behavior. However, and since LineBreak is currently not changed, this is a breaking change. Currently Text always contains SLineBreaks.
• In all other cases SynEdit should use SLineBreak.

An advantage is that users can programmatically set LineBreak without casting to TSynEditStringList.

I want to add that an analogous change was made earlier, so that TSynEditStringList now uses the Encoding inherited property instead of a custom property in SynUnicode.pas. Since Encoding is a read-only property of TStrings (no idea why!), a SetEncoding method was added to TSynEditStringList.

The properties that affect how a file is saved are: Encoding, WriteBOM, LineBreak and TrailingLineBreak. Encoding, WriteBOM and LineBreak are detected when reading a file. This is so that reading and later saving a file, preserves the original format. With TrailingLineBreak set to False, reading and then writing to any file will keep the file identical to its original.

@MShark67,@vincentparrett,@JaFi-cz What do you think?

[JaFi-cz]

You don't need to drop it. Enough is that FileFormat will read and set SLineBreak. It will keep compatibility and you will use current implementation Jan Fiala Dne pá 9. 12. 2022 1:04 uživatel pyscripter ***@***.***> napsal:

…

There are currently two properties of TSynEditStringList that relate to the line endings of saved files: - FileFormat: TSynEditFileFormat = (sffDos, sffUnix, sffMac, sffUnicode) - LineBreak inherited from TStrings (introduced in Delphi Berlin 10.1) The base class TStrings uses LineBreak only when: - saving files (GetTextStr) - reading files (SetTextStr) - Text property getter Currently TSynEditStringList uses instead FileFormat without setting LineBreak: - SetTextStr is overwritten and detects line endings in the provided text, setting FIleFormat appropriately - GetTextStr is inherited and uses LineBreak except when saving in which case the FileFormat is taken into account - In all other cases SynEdit uses SLineBreak (SelText, SelLength). In a few places it is assumed that SLineBreak = #13 <#13>#10 (e.g. CharIndexToRowCol, RowColToCharIndex). It is confusing to have two properties that relate to Line Endings. Also, I think it is more consistent for TSynEditStringList to inherit behavior from TStrings. Since LineBreak has been availalbe since Delphi Berlin, ant this repo is not compatible with version before that, I propose that we drop FileFormat and use instead LineBreak: - LineBreak is set when reading files or setting the Text property (SetTextStr). TStrings does not do that. - LineBreak is used reading the Text property. This is inherited behavior. However and since LineBreak is currently not changed, this is a breaking change. Currently Text always contains SLineBreaks. - In all cases SynEdit uses SLineBreak. @MShark67 ***@***.*** ***@***.*** <https://github.com/JaFi-cz> What do you think? — Reply to this email directly, view it on GitHub <#48>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AT5VHKUJG3JOJRJS6UDO2GDWMJZQRANCNFSM6AAAAAASYXFOPI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[pyscripter]

And what if someone, familiar with TStrings, sets LineBreak expecting that to affect how a file is saved?
You need to add two-way synchronization, which is unnecessary overhead and code complexity.
Keeping two separate properties that have the same purpose just creates complexity and confusion going forward.

Also, FileFormat was not a property of SynEdit. You had to typecast SynEdit.Lines to TSynEditStringList to get access to it, so my guess is this would not affect casual users of SynEdit.

[JaFi-cz]

My idea was FileFormat GET will read LineBreak property and return type according to FileFormat property. FileFormat SET will set LineBreak. You won't keep FFileFormat internally.
If somebody will set LineBreak, it will work too.

[pyscripter]

And we could mark FileFormat as deprecated...

[JaFi-cz]

Yes. All will work with new LineBreak and older projects work too.

[pyscripter]

Fixed as @JaFi-cz suggested.
Unfortunately you cannot mark a property as deprecated. So I just inserted a deprecation comment.