[Lazarus] region [elastic tabs [Re: Auto indentation]]

[Hans-Peter Diettrich]

Martin schrieb:

>>> For section heading {%region} {%endregion} is usefull => since it 
>>> allows folding
>>
>> Such verbose formatting is unusable, for several reasons:
>> - it is bound to an special editor
>> - it is imposed on every user
>> - it must be maintained manually
>> - it is pure overhead
>>
> So what did you mean, what are your ideas of folding?

First level folding is based on the language, that suggests syntactical 
constructs that can be folded.

Second level are logically sequential parts of the text, maybe sequences 
of statements, methods, declarations etc. Only these areas deserve 
special marks in the text, and the marks can be bound to very short or 
otherwise intuitive indicators. Like
  //--- begin of lengthy section ---
or
  //- purpose of the following lines of code

Such comments can also be used for documentation or navigation purposes.


> There are many possibilities, but most of them will be supported by very 
> few editors, if any at all.

I do not mean that every section really should be foldable by an editor. 
It often is easier to ignore passages of currently uninteresting code, 
than to really collapse or expand blocks in the display. With the above 
indicators an editor could fill an treeview, and allow navigation to the 
section marks from that tree (as an extension or in addition to an code 
or structure explorer).


> A few ideas I had, but not all worth doing:

I have no special ideas about folding, I found it too much work to 
collapse or expand blocks, and to hide again automatically expanded 
blocks after navigating e.g. to a declaration.



> - folding by special comments (as you indicated "///") but that again is 
> very editor specific. it is just a shorter notion of region.
>  It could be configurable by specifing the pattern / and it has the 
> advance of an automatic end at the next section / and they could be 
> leveled ("///", "////", "/////", ...)

Something like this seems a natural way to give source code a logical 
and hierarchical structure. As mentioned above, an file index could be 
created from such markers, allowing for navigation. Inside that tree 
folding would make sense even to me, because that folding must not be 
reflected in the displayed source code.


> The "///" are what you mentioned in your post. But (with the exception 
> maybe of overhead) it has the same properties as region:
> - it is bound to an special editor
>  (or a set of a few special editors)
> - it is imposed on every user
> (if it is not treated as editor specific directive it is a comment; so 
> is {%region ...} )
> - it must be maintained manually
> (except for the end of each block is found automatically, sometimes an 
> advantage, sometimes a disadvantage)

Maybe I have written too much structured documentation, so that working 
with similarly structured source code seems natural to me. I also start 
the implementation of a procedure by inserting comments, indicating the 
required steps. Then I fill in the code in between these comments. And 
in the implementation part, I mark sections for logically related 
procedures, and move auto-created method bodies into these sections, 
regardless of their naming.

I also do not ask for folding or mapping support in an general purpose 
editor but - as every better word processor, HTML or other dedicated 
editor does - my preferred source code editor should support kind of 
such "structured" handling of the text.

DoDi