[Lazarus] Gecko on lazarus

[Osvaldo Filho]

Graeme Geldenhuys wrote:
> Martin wrote:
>   
>> If any commit converts tabs to spaces, then elastic tabs do not solve 
>> any problem any more or less than any other tab handling does.
>>     
>
> Correct. The true benefit of elastic tabstops is when you don't have to
> do such conversions. Simply switch your source code to only using tab
> characters for indentation and a Elastic Tabstop enabled editor will do
> the rest for you - no matter what the users tabwidth preference is set at.
>   
True again, but again elastic tabs do not have a benefit over normal 
tabs here.

If I save all my indent with tabs in the old way, then I have 
"procedure", most outer "begin" = 0 Tabs; indent of code on procedure 
level = 1 tab; indent of first nested begin = 2 Tabs ......
- I can save/store this without conversion (keeping tabs) => anyone can 
view it never how width their tabs are. They get their preferred indent, 
but all will align
- Save/Store it as spaces => will work too

Elastic tabs come only as a benefit if you want to use tabs, that are 
not leading whitespaces, but embedded into the middle of your line (e.g. 
indent comments to align them at end of line).
But in this case the benefit is not just about storing (beneficial 
storing is just a side-effect or consequence). In this Case the benefit 
is, that even while being open within the same editor, if I modify the 
length of text before a tab in one of the lines, all other lines will 
follow. (Storing and opening in an other editor, is nothing but 
modifying the length of text in one line...)

Elastic tabs is only one scenario for this. Same as good you could have:
- leading tabs (before any none-white-space) = every 2 or 4 spaces
- embedded tabs at fixed location (first embedded tab at column 80 for 
comments)

It is not as flexible (but that's a matter of taste and requirement) => 
but it does survive storing / other editor too


> The conversion from Tabs to Spaces when using a elastic tabstops enabled
> editor is simply as a stop-gap or for backward compatibility with users
> that don't have elastic tabstops enabled editors.
>   
If all users are too have elastic tabs, then I could also require that 
all users have tabs at a width of 4. Same thing, same requirement for 
all. No benefit in elastic tabs. All users must have the same.

Elastic tabs is nothing else but a specific way to define the width of 
tabs as "according to formula xyz" instead of a number. But the 
definition must be followed by all users

>> Such conversion (to spaces / from spaces) can be applied to any form of 
>> tabs that you have in your source code
>>     
>
> No true. Most editors have a single value for a tab to space conversion.
> eg: 1 Tab character = 4 spaces. Elastic tabstops conversion from tabs
> to spaces doesn't do that. It's a bit more intelligent. I looks at the
> surrounding code to see how things are aligned using tabs, then inserts
> variable amount of spaces so that alignment of the content stays the
> same after the conversion.
>   
See above. elastic tabs have a fixed definition too.
If a user has a fixed tab width of 4, and you load this later with 
elastic tabs => it will look screwed. and vice versa.


I am not to deny that elastic tabs have there use, and are good in 
various situations. But they do not solve interchangeability.
One could even say they make interchangeability worse, because now there 
is one more way.
Previoulsy it was: 1,2,3,4,5,6,7,8 ...
Now it is: elastic, 1,2,3,4,5,6,7,8 ...

If you say, now should be only elastic, I say it can be solved the same 
way, by saying mow should be only 4. Both is picking on definition at 
random, but everyone needs to follow the picked definition

Martin