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

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

Now compare that output to a editor that doesn't use elastic tabstops like Lazarus IDE. The ex1_normal_tabs.png show how Lazarus displays that same text using TabWidth = 4. Alignment is totally garbled, and no setting of specific tabstops is going to fix that, without adding extra Tab characters.

ex2.png & ex2_normal_tabs.png
-----------------------------
ex2.png shows an array of records declaration. Again in gEdit it was very easy to align the text. Each blue dot represents a Tab ($09) character. Now compare how that text looks like, when opened in Lazarus IDE which has TabWidth = 4 defined. Again, alignment is completely garbled and would require quite a few more Tab characters to fix.

I have also include the two example .pas files, but converted Tabs to Spaces. gEdit with ET enabled automatically inserted the correct amount of spaces so that alignment stays correct.

As you can see from the above. Editors with standard tab support specific tab width simply cannot align content as easily and neatly as can be done with an editor that has Elastic Tabstops support. ET also uses much less tab characters because the tab widths differ from line to line, and tab to tab.

Regards,
- Graeme -

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

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.

"tabs can be used between text as well "
that is exactly what I described.... see above, for the 80 column example

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

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

What restrictions must be observed in order to make the desired output format occur? What about lengthy (multi line) descriptions?

Such EOL-block comments as in ex1 are ugly and a waste of space. More useful were a comment block describing the interface, that can be inserted into auto-generated documentation.

ex2 seems to be more useful, but have a severe limiation: when a record has more fields, either the lines will become overly long, disappearing to the right of the screen, or they must be wrapped, breaking any table formatting.

Can you provide examples with the above modifications (longer comments and records, and a block description of the procedure interface)?

Also, what will happen while editing, when one of the rows must be enlarged while typing? Will all the rows be reformatted with every keystroke?

DoDi

Again in the attached image, Tab characters are shown as pink dots.

Martin wrote

but I do not see how the increase portability between editors

Lazarus is my editor for development work - personal and company projects. Hopefully Lazarus is the editor other developers & companies too, otherwise what are they doing in this mailing list. ;-)

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

"elastic tabs" should read "elastic tabstops". A Tab character ($09) is just that, a charter. And that is not very "elastic" at all. :-) This information comes directly from the "Elastic Tabstops" website.

Both of them break, if the editor is set to anything else.

No, if the editor uses elastic tabstops feature, code is a lot more "visually portable" between other editors using elastic tabstops feature. By this I mean, each developer can customize there tabwidths and padding, and all alignment will still be correct.

This is not the case with standard tabs where that have preset tab widths and specific column positions.

NOTE: All this only applies if you use Tab characters in your source code. This does not apply if you convert those tabs to spaces etc...

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

Nope, see above.

That is not equivalent with better portability.

Portability is achieved if your company decides that all source code files contain tabs and uses elastic tabstops feature. Is like example the same as if your company decides on a specific code formatting style.

Portability is also achieved if for instance I use elastic tabstops feature in Lazarus source code, but when I save the IDE source code changes I made, I do a conversion from Tabs to Spaces. Because the Lazarus project uses spaces in there source code.

That cannot work, as I have show in my first message. What if parameter values must be aligned, or a record structure. I don't want those to start at column 80! And the usage of tabs there, are not just for adding comments, but for code alignment.

ex1.png (aligning params in a multiline procedure declaration), raises another serious question (but nothing to do with portability)

It's a matter of code formatting rules, and if you have complex parameters that you want to comment inline and not via a external help tool like fpdoc.

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

No, leading tabs act like normal tabs. Jump a set number of pixels (or characters), depending on the ET implementation. One difference being that if alignment was used (non-leading tabs) in previous line of code, then alignment occurs and the tabwidth is different to a standard tab.

Line 2 in ex3.png shows that.

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?

It depends in which "tab block/cell" it falls into. The ET website explains tab blocks/cells with a image.

See lines 15 vs lines 18 in image ex3.png. Elastic tabstops wants to align content with tabs. On line 15 there is no point in adding the second tab before the comments. Because what do you want to align the comments with? Nothing, so use a space to separate the comment from the code, as is done on line 18.

As I said, tabs help with alignment. Do don't want to align the comment with anything, so use a space character instead. This is exactly the same rules as what you have done with the space between "then" and "begin".

Regards,
- Graeme -

The same portability is archived if the company decides to use tabs of a specific width (e.g 4)

Again:
- Normal tabs do not have the features you show in your pics (aligning params in a table like way)
- I am not denying that elastic tabstops add new (useful) features. and those new useful features are portable.

Looking at the features old tabs actually have: Their portability is not increased by using elastic tabs.

Using a new feature that is only present in a certain set of editors actually reduces portability, because you *limit* yourself to this set of editors.

what about my example?
if a then begin <TAB> // some comment
<TAB> writeln()

versus
procedure( <TAB> param1
<TAB> param2

How do elastic tabs know, if they should indent the tab in line2 by the fixed offset for leading tabs, OR the elastic alignment ?

ok, so in this case the indented statement is aligned in a none ideal way?

Question solved

2009/11/6 Martin :

The same portability is archived if the company decides to use tabs of a specific width (e.g 4)

With one extra benefit, that each developer can still decide what tabwidth (ET property, not standard tabs) they would like indentation to be. So developers still get there desired indentation with neatly aligned text, and the company is still happy that everybody is conforming to the code formatting standards or using tabs. :)

lines 16 & 17 vs 18 & 19 in my ex3.png shows exactly that. The thing is that in your first case the Tab char should not be used before the comment, because you are not aligning it with anything - no other code or any other comments. So simply use a space to separate "begin" and "// some comment".

ok, so in this case the indented statement is aligned in a none ideal way?

Correct, but in that first example of yours, the code is also not written in a ideal way. ;-)

Either way, if I even get the time to implement ET in Lazarus IDE, it will obviously be a optional settings and include support to convert from Tabs to Spaces and vice-versa.

2009/11/6 Hans-Peter Diettrich :

What restrictions must be observed in order to make the desired output format occur? What about lengthy (multi line) descriptions?

I cannot see any restrictions at all, but I'll try and put together an example showing all the variations you mention. Or maybe even a small animated gif will help.

Such EOL-block comments as in ex1 are ugly and a waste of space. More useful were a comment block describing the interface, that can be inserted into

I agree, and I don't code in that style myself. :-) I was simply trying to demonstrate that Tab characters can be using inside the context of code. Below is another possible use, but without the comments. Maybe you have a produce with a huge amount of parameters, and wrapping them at 80 chars and condensed in two or three lines might make it hard to easily see the parameters and types, though with syntax highlighting this is not anymore such a problem.

----------------------------
Procedure TRichTextLayout.PerformStyleTag( Const Tag: TTag;
                                           Var Style: TTextDrawStyle;
                                           const X: longint );
begin
  ApplyStyleTag( Tag,
                 Style,
                 FFontManager,
                 FRichTextSettings,
                 X );
end;
----------------------------

ex2 seems to be more useful, but have a severe limiation: when a record has more fields, either the lines will become overly long, disappearing to the right of the screen, or they must be wrapped, breaking any table formatting.

Well that is not really an issue regarding Elastic Tabstops, that is a general problem defining a large record and populating it with values in one go.

Can you provide examples with the above modifications (longer comments and records, and a block description of the procedure interface)?

Sure, but I think you will get a better feel for elastic tabstops if you have access to Linux. Simply install and enable the gEdit ET plugin, set you preferred widths, then open a .pas file and experiment away.

http://nickgravgaard.com/elastictabstops/

Alternatively you can try the Java "ETDemo.jar" application and run it locally. Also available for download from the above URL. It's a mock-up mini editor where you can try ET. Only thing is, I don't think you can adjust the default indentation widths which I think is a bit large (but typical of C programmers), and it's a bit slow compared to the gEdit plugin.

Also, what will happen while editing, when one of the rows must be enlarged while typing? Will all the rows be reformatted with every keystroke?

Yes, that's the awesome thing about ET. Whatever surrounding lines falls in the same "text block/cell" will adjust automatically as you enter the new line. No need to go back to previous lines and adjust there indentation.

Such indentation soon becomes unusable with method calls, and with further calls inside the argument list.

DoDi