[Lazarus] "trim trailing spaces" and "cursor past eol"

[Martin Friebe]

Mattias Gaertner wrote:
> On Sat, 18 Oct 2008 00:19:00 +0100
> Martin Friebe <lazarus at mfriebe.de> wrote:
>
>   
>> Hi, just trying to poll an opinion on how exactly those features
>> should work.
>>
>> Especially in relation to the automatic indent of a new line to the 
>> indent of the line above. (This is when you press enter at the newly 
>> inserted line will be indented as much as the line under which it was 
>> inserted.)
>> Normally this is done by having the new line pre-filled with spaces. 
>> This conflicts with "Trim trailing spaces", as this spaces are not 
>> always removed. (Since bug 0011745 revision 15875, if "cursor past
>> eol" is enabled those spaces are no longer inserted.)
>>
>> However even without "cursor past eol", the spaces may be removed => 
>> press a single space, on a freshly inserted line. If you "show
>> special chars" you will note that the spaces are no longer present,
>> and the cursor is actually behind the end of line (with side-effects
>> if you press cursor-left).
>>
>> So much  about the current situation.
>>
>> I believe that "trim trailing spaces" and "cursor past eol" should
>> *not* affect each other at all. There should be no reason. (Of course
>> there would be a need to fix "trim trailing spaces")
>>
>> If they do not affect each other then the following should be true 
>> (IMHO, if anyone disagrees or has a better idea => that is why I am 
>> mailing this)
>>
>> - "cursor past eol"  should make no difference
>> - pressing new line should always insert the spaces. (*1)
>>   This is even if "trim trailing spaces" is active => there are way
>> to make sure those spaces are never left over
>>
>> - if "trim trailing spaces" is *not* active, the spaces remain, if
>> you leave the line.
>>   This means, if you later return to this line, and press the
>> "end" (end of line key) you are at the expected position (independent
>> of "cursor past eol")
>>
>> -if "trim trailing spaces" is active, several things need to happen:
>>   - the spaces are removed, when you leave the line
>>     and (tricky) they will be kept in existence, but not be saved if
>> you save the file while the cursor is still in this line
>>   - the spaces are kept,, even if you move the cursor to the left. 
>> Therefore pressing the "end" key (end of line) will behave as expected
>>
>> This means if you leave the line, it will be empty, and pressing the 
>> "end" key, will keep/set the cursor at x=1 (independent of "cursor
>> past eol").
>> Of course if "cursor past eol" is on, and you do *not* press "end"
>> the cursor may be anywhere in the line.
>>  
>>
>> *1)
>> Trimming happens when you leave the line, or save the text.
>>     
>
> What do you mean with 'save'?
>   
"Save to file" but it was just as an example for any access to the text 
buffer.
> The synedit sources are frequently saved to the codetools buffers. 
> When the user 'Save' then the codetools buffers are saved. 
> Saving the snedit buffers to codetools happen often. Some do that on
> idle.
> Some plugins work directly with the synedit lines.
> I think it would be better to not add the spaces and use a flag for
> 'past eol' cursor.
>   

That is what I meant with "virtual spaces". With TrimTrailingSpaces = 
True => Lines (SynTextBuffer) would never see those spaces. Synedit 
would keep a count of how many spaces past eol the user currently has. 
SynEdit would work on this "virtual" line. Any movement to the caret (= 
changing the current line) will reset the count.
The Count will be kept in 2 fileds: "Count", 
"LineNumberForWhichTheCountIsValid" => so it will not by accident use 
the Count for another line.
(Or maybe only, if you start editing the next line? => That would allow 
for a cursor up/down, to return to the indented position; I find it 
quite annoying to loose the indent, just because I needed to scroll a 
few pages... )

If TrimTrailingSpaces=False, then spaces will be inserted as normal.
>
>   
>> However the implementation would probably work  by not inserting the 
>> spaces for real, but by simulating there presence (which may affect
>> if htey would or would  not be shown under "show special chars"). In
>> any case SynEdit must/would behave exactly as if they did exist.
>> The idea is to keep a count of "virtual spaces" on the current line. 
>> This would not only apply to spaces in empty lines, but to all
>> situation where spaces at the end of line will be affected by those
>> options.
>>     
>
>
> Mattias
> _______________________________________________
> Lazarus mailing list
> Lazarus at lazarus.freepascal.org
> http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
>