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

[Mattias Gaertner]

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'?
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.


> 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