[Lazarus] Auto indentation

[Hans-Peter Diettrich]

Graeme Geldenhuys schrieb:

>> Source code formatting is a matter of taste. Regardless of the internal
>> storage of horizontal formatting, the result does not please everybody.
> 
> Yes I know that, but elastic tabstops is so far the best formatting
> option I could find. And I would definitely us it for my own projects
> - if it existed in Lazarus.
> 
> 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?

> Also elastic tabstops touch on a point that most formatting arguments
> (tabs vs spaces) do not pick up on. Formatting MUST be done by the
> Editor in a visual only way - same as what editors visually do Code
> Folding, or drawing Procedure Divider lines. Code Folding markers or
> Procedure Divider lines are not something in your actual code content.
> This "eye candy" is applied over your code and *not* in the source
> code itself.

That's acceptable, even if I have no use for such eye candy.

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


>> I'd appreciate a version control system that separates formatting from
>> content, and thus would track only changes in the content, regardless of
>> whitespace and line breaks.
> 
> Then switch to Git. It has had this option since the beginning of Git
> (a few years back).

Maybe you didn't understand my point?


>> essential changes. Furthermore the *language* should allow for automatic
>> formatting, and the OPL has certain deficiencies in this area.
> 
> Rubbish, you just said formatting is a personal thing! Plus the
> compiler doesn't give a crap what formatting you use, as long as the
> code syntax is valid. This is exactly how it should work. Formatting
> is definitely NOT a language feature.

Automatic formatting has to know about the language, in order to know 
where to indent and outdent blocks, or how to build columns of other items.


>> If somebody wants to have formatted tables, he'll have to insert formatting
>> *instructions*, so that the layout can be restored later - but where should
>> such instructions be stored?
> 
> This has been done for years in C programming. Have you not noticed
> the first line in many C source code files, it specifies the tab width
> in a commented line.

I never saw that, but what's the use of such indicators?

> But that is also not ideal, because now you are forcing YOUR
> formatting onto other people that open that file. Again, Elastic
> tabstops solves the problem nicely, because you personally define the
> formatting of a Tab character ($09) in your editor - *without* needing
> to modify the source code to get formatting correctly.

This only applies to tabs at the begin of a line, where formatting also 
can be done automatically.

> If you are still confused as to what Elastic Tabstops do, then re-read
> my earlier post that explains it.

Sorry, it doesn't explain much. It shows how the output could look like, 
if everything works.

> Each line in that example only uses
> two Tab characters, but based on your customizations of elastic
> tabstop settings, the formatting will be different between users, but
> still align correctly for everybody.

Where "correct" reflects the opinion of the inventor.

> That applies even if you use a
> variable width font too! So you are no more limited to only coding
> with monospace type fonts.

That's right, from the technical view. Nonetheless the use of 
proportional fonts is limited in programming, in detail with tables and 
numbers. At least all (hex) digits should have the same width. With 
small characters, like 'i', it's hard to position the cursor for 
insertion or deletion. Moving the cursor through consecutive lines can 
become a nightmare :-(

DoDi