[Lazarus] Auto indentation

[Hans-Peter Diettrich]

Graeme Geldenhuys schrieb:

> Personally, I would switch immediately to using tabs instead of spaces.
> In standard editors like Lazarus IDE, I prefer a default tab width of 3
> characters, but I don't use tabs in my code simply because I work on
> various projects with other developers. A sad compromise - I know.
> 
> Maybe later when Jedi Code Formatter works correctly in Lazarus, all
> source code will look consistent. eg: You write your add-on / patch for
> Lazarus in your favourite coding style. The just before you generate a
> patch you press Ctrl+D and the code is formatting as per the Lazarus
> project standards, then generate the patch. But that wouldn't work in
> all cases either. :-(

It could work when the Lazarus editor applies the user-defined 
formatting after a file is loaded (imported), and applies the exchange 
formatting before a file is stored (exported). All we need is a strong 
definition of the exchange format, and the ability to install predefined 
or user-supplied pairs of import/export reformatters.



> I'm not 100% sure how the conversion from Spaces to Tabs word.

That's my one and only objection against the use of Elastic Tabstops, so 
far. The *exact* behaviour should be known, not only the *intended* 
results. IMO the exact behaviour *must* take the language syntax into 
account, so that string literals and comments can be handled properly. 
Remember that the C and Pascal syntax is different for these items!

> But if I
> had to use Elastic Tabstops, I would switch my projects to using tabs
> only - so no conversions or guesswork is required.
> 
> Plus, have you seen how much smaller source code files become if you
> user tabs instead of spaces. Also elastic tabstop enabled editors use
> even less tab characters than normal editors. The size difference is
> actually quite big (I was even surprised).

Runtime formatting can require much time and space. And it may fail just 
when editing such formatted text, garbling whole passages of the text :-(

We may need both raw and vanilla edit modes, so that changes to the 
formatting can be done in raw mode, with no automatism getting into the 
way. We also could use different editor panes for both views (on 
demand), with formatting aids being available for easy adjustments (see 
the fpdoc editor, HTML editors...).

DoDi