[Lazarus] Auto indentation

[Martin]

Hans-Peter Diettrich wrote:
> Graeme Geldenhuys schrieb:
>> Also, as I mentioned, the gEdit plugin that enables elastic tabstops
>> has a option to automatically do conversions. So you can work with
>> elastic tabstops enabled, but when saved, the file gets converted back
>> to using spaces.
> What will happen when you commit your changes?
> Will everybody have to work with your formatting, casted into spaces?
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.

In this case the stored text has only spaces. If you check it out again, 
and wish to edit it, you need an editor, that detects where those spaces 
should be tabs (magical guessing according to your taste)
Such conversion (to spaces / from spaces) can be applied to any form of 
tabs that you have in your source code

NOTE: The conversion of tabs to spaces can be defined in 2 ways:
1) tabs a converted to an as many spaces as needed, so the look on the 
pc of the converter does not change
2) tabs and consecutive tabs (as well as consecutive spaces) are 
converted to a single space nly (except in strings or other white space 
sensitive areas)

The first solution does not solve anything, as the checked in text still 
expresses the format of the one writer who converted it. => Format is 
still part of the content, not applied to a content

The 2nd form will work (exceptions see further down) but requires are 
really good formater for any one wanting to work with this text

>> Same thing should apply to code formatting, which is what Elastic
>> Tabstops does. You press the Tab key, which inserts the char $09 -
>> nothing more! Now the editor does the formatting for you, but doesn't
>> modify the source code contents to do it.
>
> I'd agree with different tabstop codes, so that the formatting can be 
> undone or suppressed at any time.
Tab stops in the source (white space insensitive area / outside strings 
etc) are formating.
They are formatting, because they cause different layout, unless they 
can be ignored / handled same as spaces

After all Graeme would only need a single (or 2) tab char in the source, 
in order to align comments at the end of several lines
I need maybe between 1 and 10 tab stops per line so my editor shows the 
comments aligned (using normal tabs)

If all editors are to handle them elastic, then they carry format into 
the content

>>> content, and thus would track only changes in the content, 
>>> regardless of
>>> whitespace and line breaks.
Line breaks are interesting.

Since some people write:
if a then begin

or:
if a then
begin

the line break itself embeds formatting into the content.

If you want to archive, what you describe (format free content) then all 
whitespaces (including tabs, newline) must be stored as simple space 
(except some basic interpreters, which have linebreak as part of the 
language)

Applying tabs and linebreaks is eye candy, that your editor should apply 
on top of the content.....

Linebreaks could be used  for paragraph like grouping of statements, 
that represent a logical entity in your code, yet are not presented as a 
procedure of their own.

---------------------------
I may have shlightly disconnected from reality while writing the above....



Martin