Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2008-10

"trim trailing spaces" and "cursor past eol"

4 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Martin Friebe

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

Reply by email

JoshyFun
to Martin Friebe

Hello Martin,

Saturday, October 18, 2008, 1:19:00 AM, you wrote:

MF> Hi, just trying to poll an opinion on how exactly those features should MF> work.

I'm completly according with your behavior presentation. The technical inners about how to get the effect is not important from my user point of view, but usually the easier solution is the better one.

Best regards, JoshyFun

Reply by email

Mattias Gaertner
to Martin Friebe: Hi, just trying to poll an opinion on how exactly those features should work. Especially…
Show quoted text 55 lines
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 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.

Show quoted text 8 lines
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

Reply by email

Martin Friebe
to Mattias Gaertner
Mattias Gaertner wrote 63 lines
On Sat, 18 Oct 2008 00:19:00 +0100 Martin Friebe 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 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.

Show quoted text 8 lines
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.

Show quoted text 19 lines
> 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 http://www.lazarus.freepascal.org/mailman/listinfo/lazarus

Reply by email