[Lazarus] Auto indentation

Hans-Peter Diettrich DrDiettrich1 at aol.com
Thu Nov 5 14:13:09 CET 2009


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

This is a problem with almost any version control system. When changed 
whitespace is not considered as a change, then a changed formatting is 
not transferred into the repository. This makes the formatting 
non-persistent and doesn't help anybody.
Else every change in formatting is transferred, so that the repository 
is updated after a user has reformatted the text, and committed some 
change. This would result in excessive bloat of the repository history, 
whenever a user commits an change with reformatted text.

That's why I consider any kind of artificial formatting as quite 
useless, as soon as a VCS comes into the play :-(

If ever, we should have a tool that creates a canonical form of all 
files, before changes are committed. This tool should be part of the 
editor, so that the user specified formatting can be applied to every 
loaded file, and is removed when a file is saved.


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

And that's kind of formatting that I don't like. My formatter would 
append dangling begins to the end of the preceding part of the 
statement. This is where the language syntax comes into play:

Pascal:
if a then BEGIN
   ...
END else BEGIN
   ...
END
(the requirement for BEGIN-END pairs depends on single/multiple 
statements in every branch, or on the opinion of the coder)

Modula:
if a then
   ...
else
   ...
end;
(no need for optional or required begin-end pairs, the syntax is 
unambiguous)



> Applying tabs and linebreaks is eye candy, that your editor should apply 
> on top of the content.....
and remove it again when a file is saved!


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

That's what I do frequently :-)
I prefer to use outdented comments as section headings, so that these 
sections can/could be folded automatically. This convention stands in 
contrast to Elastic Tabs or any other reformatting, that would change 
the indentation level of such headings. Eventually section headings 
could be flagged by /// or any acceptable special characters appended to 
the begin of the comment.

DoDi





More information about the Lazarus mailing list