[Lazarus] Elastic Tabstops: benefits or not

Martin lazarus at mfriebe.de
Fri Nov 6 15:16:26 CET 2009


Before answering this.

I do not say anywhere, that I don't think elastic tabs are a nice 
feature. They are a very nice feature.

but I do not see how the increase portability between editors


Graeme Geldenhuys wrote:
> I started a new message thread, because the renamed one you started
> ended up in the same message thread tree as the "Auto indentation" thread.
>
>
> Martin wrote:
>   
>> True again, but again elastic tabs do not have a benefit over normal
>>  tabs here.
>>     
> They do, see below...
>   
Elastic tabs (or source containing tabs, that should be displayed as 
elastic tabs) only display correct if the editor is set to elastic
Tabs with width 4 only display if the editor is set to width 4

Both of them break, if the editor is set to anything else.
And imagine, I formatted source using normal tabs (adding maybe between 
1 to 5 tabs before the comments) => then open it in elastic mode => the 
result would be all but good

Elastic tabs, as any other tab, force all user to have the same editor 
setting.

But yes, I grant one thing:
If all users have the elastic setting, they can change subsettings. They 
can change the tab-widths for leading tabs, without affecting the tabs 
that are in the middle of the line
So you can choose if the indent after a "begin" is 2,3 or 4 => and you 
do not loose alignment of comment.

So true: with elastic tabs you gain easier alignment of tabs. However 
That is not equivalent with better portability.
Why? Because it is a feature old fashion tabs (which stop at every nth 
char / as oppose dto which stop at selected columns such as column 80 
only, see below)..
Those old fashioned tabs do not have this feature. And because they do 
not have it, it can not be portable for them. Introducing a new feature 
(which happens to be portable) doesn't increase portability

Why did old fashioned tabs not have this feature => because your comment 
indent would already break, if you edited a single line within the same 
editor used to initially  create the text. You always have to adapt all 
lines by hand. So do you have, if you port it to an editor with changed 
tab settings


And also: this (alignment of tabs) does not require elastic tabs, this 
requires tabs with 2 kind of settings:
- indent for leading tabs
- fixed pos for tabs in the middle of the line
 (e.g all tabs in the middle of the line align to column 80)
The 2nd solution is only problematic, if you increase the initial tab 
big enough, to make you line (without the comment) to violate the 80 
chars boundary.


Anyway: What I meant is "elastic tabs" do not make your code portable to 
just any editor.
There are far more editors that can have there tab-widths adjusted 
(almost every editor) versus editors with elastic tabs (very few)
So the above elastic tab benefit, is outweighed by forcing everyone to 
an editor that is not their natural choice.


>> 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)
>>     
>
> I disagree, tabs can be used between text as well - depending on your
> coding style obviously.
>   
"tabs can be used between text as well "
that is exactly what I described.... see above, for the 80 column example
> I tried to create some examples for you using plain text, but it was too
> difficult to get the point across. So instead I used gEdit (with ET
> enabled) and tooks some screenshots. I also included the original .pas
> files for you to view.
>
> ex1.png & ex1_normal_tabs.png
> -----------------------------
> In ex1.png you can see how the text looks like in gEdit with Elastic
> Tabstops enabled. The Tab ($09) char is indicated with the pink dots.
> Every dot is a single Tab character.
>   
ex1.png (aligning params in a multiline procedure declaration), raises 
another serious question (but nothing to  do with portability)

I thought elastic would apply to tabs that are "not leading" that is 
tabs that are in the middle of text.

If it applies to tabs that are at the very start of line: How do you 
indent after a  "begin"? Because the indent should not  depend on the 
previous line?

- ex1 does )param1 and param 2 aligned)
 procedure Foo( => Param1 ......
 =>    Param2

- begin should do
 if a then begin => // some comment
 => writeln('a is true');

Writeln should be indented by 2,3 or 4 / but not aligned with the 
comment of the previous line



> First I created a procedure declaration which has each parameter
> commented. I then duplicated that declaration and then inserted a new
> 3rd parameter. As you can see from the second declaration, without me
> having to go to any of the other parameter lines, all the comments
> automatically aligned in the new location.
>   
Yes, as I said a nice feature. A feature that normal tabs do not even have.
Since normal tabs don't have it, it can not be portable

so this is the introduction of a new portable feature. But it does not 
enhance an old feature to become portable





More information about the Lazarus mailing list